Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Determining the Effective Performance and Peak Capacity

 

The key to determining the capacity of an existing or a planned SBRC system is not measured by average operational performance, but rather by expected or observed periods of peak activity. SBRC performance should generally be nominal during regular day-to-day system operations with significant unused capacity. The following exercise will help you determine how close the SBRC system is to possible peak performance for the hardware platform under evaluation.

For an existing SBRC system running continuously for a period of time and experiencing peak traffic, failures, and spike conditions, do the following:

  1. Determine the “Peak” throughput in authentications, account starts, and stops using the Statistics page in Web GUI. Record these values and add them up.
  2. Measure the system by simultaneously monitoring the following over a defined period (at least 5 to 10 minutes during “peak” user-level activity timeframes):

    1. Average auths and accts/s for the period from the Web GUI (which you can clear before starting the test), and note the total interims done over the period.
    2. Monitor the system using prstat –L to view the highest utilized thread for the period and its percentage utilization. This value is the strongest indicator of the overall scalability of SBRC, which in almost all cases performs well on multiple processors. The hard limit is often the utilization of one key thread that does slightly more work than other threads. This is more important on machines with more and slower virtual processors, as compared to machines with fewer and faster processors such as the M3000.
    3. Use prstat to check and note the overall CPU utilization. This helps you determine the available CPU power to do the work of all the threads.
    4. Run sar with an interval of 5 minutes (sar 300 1). The result should be similar to prstat, but with information categorized based on usr and sys. A large amount of sys utilization means the system is processing more I/O and network work.
    5. Run iostat with an interval of 5 minutes (iostat 300 1) and note any devices that are heavily used. This gives you information about logging performance.

      For example, executing our own load test tools for accounting on the M3000 may see a utilization of 3 Mbps, which is an average amount. You can also use (iostat –E 300 1) to obtain a utilization percentage number that you can use as a reference to maximum theoretical capacity calculated by the OS.

  3. Calculate the expected utilization during peak performance by dividing each result obtained in Step 2a through Step 2e by the average TPS for the test period, and multiplying the value with the peak TPS. This gives you an estimate of the CPU resources and I/O resources that will be utilized during peak performance.
  4. Record the following information of the results of calculations based on Step 3:

    1. The projected highest single-thread utilization from prstat –L. If this is more than 90 percent of the single-CPU performance (determined by dividing 100 by the number of virtual processors), you will run out of CPU resources to handle the workload at peak.
    2. The expected overall CPU utilization at peak. If this is more than 90 percent, you will run out of CPU resources.
    3. The expected I/O utilization at peak. If this is more than 60 percent of the rated throughput on the drive, which varies by model, you will soon run out of resources. I/O utilization at 60 percent assumes activities such as “seek before writing” as a disk becomes full, which induces latency.

This is a good approach for calculating the existing nominal system usage and determining the performance characteristics at seen peak usages. With these calculations in hand, you can help ensure enough throughput to sustain peak usage for an extended period.