View source for DSS - We have your Size

''By [[Dave Bachmann]]''

Static sizing asks the question ''How much resource do I need on my servers to support X users and Y client machines?'' Although this information is important to consider when determining the size of your Directory and Security Services (DSS) cell, it only solves one part of the puzzle; you also must size your cell dynamically. Dynamic sizing asks ''How much resource do I need if Z users are running applications generating N requests per second?''

Let s say you are planning a cell with 100,000 users, and 20,000 of these users will be concurrently logged on at any time, making 1 transaction every 10 seconds (0.1 transactions per second) with your application. You want to know:
*''How do I determine the number of machines to use in this cell?''
*''What benchmarks should I use for the machines sizing to support the 20,000 concurrent users? Is the Transaction Processing Council s TPC-A benchmark (which expresses server speeds according to transactions per second) a good indicator?''
In this example, 100,000 registered users is a static number. But whether the 20,000 concurrent users will really make 0.1 transactions per second is a dynamic question that depends on what their applications are doing. If all the users in this example log on once in the morning and use one long-running application all day, and that application makes only one Cell Directory Services (CDS) lookup to find its server, and then uses the same server all day, the security and CDS servers only see one request per day from each of those 20,000 users. If, however, the users start a new client for each transaction, then the CDS server will see 20,000 requests per second. That is a big difference.

Also consider the application servers themselves. The sizing of these servers depends on how heavy the transaction loads are. For example, compare the TPC-A benchmark, where server speeds are typically expressed in transactions per second, to the more severe TPC-C benchmark, where speeds are typically expressed in transactions per minute A server can support several orders of magnitude more clients doing TPC-A benchmarks (or similar transactions) than clients running TPC-C.

Dynamic sizing requires the following steps:
# Determine what load your application will be putting on the security and CDS servers and, from that estimate, the server resources required.<br /><br />For a very rough estimate, assume that a CDS server can handle about 500 requests per second if it is running on a PS/2 Model 95 with OS/2, or on a POWERstation Type 7013 Model 520 with AIX. You can scale this estimate upward to the size machine you want to use. Because CDS keeps its directory in memory, it should be CPU-bound and scale about the same as standard benchmarks. The security server tends to have less interaction with applications.
# Measure your application server, to find out what throughput it can sustain. This is going to depend heavily on the application itself.<br /><br />If you can compare your application to the TPC benchmarks, you might be able to come up with a scaling factor to use. For example, if your application is comparable to the TCP-A benchmark, you could estimate the capacity of different machines by comparing their published TPC-A numbers. Keep in mind that a machine's speed on a TPC benchmark can be much higher than on a typical application, because vendors put a lot of effort into making their systems perform well on the TCP benchmarks.

;Note: After determining the performance requirements for your DSS cell, read the Tips & Techniques section to improve your DSS application's performance.

{{IBM-Reprint}}
[[Category:Developer Connection News Volume 11]]