| Understanding load factors |  |
| Understanding load factors | |
When you set up your ArcIMS site, you need to have some idea of the type of load your site will encounter. Load is a factor of number of requests and CPU usage. Based on your expected or current load, you can make decisions on whether you need to add more machines or CPU's to your site. You need to understand the usage on your site in order to maximize performance and provide the fastest possible response to your users. You can do some basic calculations that can give you a rough idea how your site handles load based on the response time of your services. You should understand the following concepts:
Throughput refers to the rate at which requests are performed. In ArcIMS, you should estimate the maximum number of transactions that your configuration can handle. The more machines and CPU's you are using, the more simultaneous requests can be handled. Throughput is often measured in transactions per hour (TPH) or transactions per second (TPS). You can estimate throughput using the following formula:
| Throughput (TPH) = ((#CPU*3600) / Average Service Time)*.80 |
The following example illustrates using this formula. If you have two CPU's and an average total service time of .5 seconds, the maximum configuration capacity for your site is ((2 * 3600) / .5) or 14400 requests per hour processed. This value assumes 100 percent CPU usage. If you use the multiplier of .80, the maximum number of requests you can expect your site to process is 11520 requests per hour. Remember that this is a rough estimate, and the actual value will vary depending on network traffic, the number of faster or slower requests than expected, and other variables.
Peak hour usage is the number of requests your site receives during the busiest hour of the day. The best way to calculate the peak hour usage is to monitor your production site for one or more 24 hour periods. One way to monitor this usage is to turn on the Spatial Server log files to at least level 3. You can then review how many requests were made each hour.
If your expected Spatial Server load is greater than the maximum throughput, you may need to add more CPU's. If the two values are close, you may be able to increase the maximum configuration capacity by decreasing the average service time. For more information about optimizing map configuration files, see Optimizing ArcIMS services checklist.
The ultimate goal for any Web site is to return a response to a requesting client as quickly as possible. The Spatial Server may be processing requests efficiently, but other factors may prevent a user from receiving the response in a timely matter. Some variables are:
If only one user at time is sending requests to your site, this user will receive a response almost as fast as the Spatial Server can generate it. There is always some delay due to network traffic, but for this one user, the delay will be negligible. If 20 users are sending requests to your ArcIMS site at the same time, some users will have to wait longer for a response depending on where their request is in the queue. Although the Spatial Server may be responding efficiently, only a set number of requests can be processed simultaneously. The number of simultaneous requests is equal to the number of Spatial Server instances for each Virtual Server group. All other requests remain in a queue for processing. If too many requests are in the queue, some may start timing out. By default, the request timeout is 60 seconds.
In the following table, some response times are given assuming 20 users make requests for maps (GET_IMAGE requests) simultaneously. In reality, except on the highest volume sites, requests are not received simultaneously. Also, most requests will take either more or less time than the average, and there is some additional overhead due to network traffic. What this table demonstrates, however, is the impact on users as the load increases. In this example, the Image Server Virtual Server has four instances. Therefore, four requests can be processed simultaneously.
| Average Spatial Server Processing time |
.5 seconds | 2.0 seconds |
| Response time for first 4 users |
.5 seconds | 2.0 seconds |
| Response time for users 5-8 |
1.0 seconds | 4.0 seconds |
| Response time for users 9-12 |
1.5 seconds | 6.0 seconds |
As you can see from the table, while the first four users receive a response in .5 seconds, the next four users must wait twice as long, or one second, to receive their response. Users 9 through 12 must wait three times as long, or 1.5 seconds. The wait time is even more dramatic if the average processing time is 2 seconds.
In most situations, 12 users would not be requesting a map at exactly the same time. However, you should remember the following points:
A good rule of thumb for the number of Spatial Server instances is two instances per CPU or core. If you have a two dual core CPU machine, you should start with eight instances. You can have one Spatial Server with eight instances or multiple Spatial Servers with eight instances combined.
You can monitor the Spatial Server log files for Total Request Times. After you have a baseline average request time with two instances per CPU, you can start adding additional instances. By monitoring how much the Total Request Times increase, you can determine the optimal number of Spatial Server instances for your ArcIMS site.
Every ArcIMS site has different resources, infrastructure, data, services, and users. What works well for one site may not work as well for another. The above calculations help you to understand your site better, but the numbers are very rough. For information on acquiring more details about your site, good resources are available from the Systems Integration Services Web site. Some recommended papers are:
