Application and load testing guidelines
Last updated on: 2021-07-05
Authored by: Lee Kimber
Part of offering a professional experience to your customers is knowing how your applications perform and getting performance benchmarks for your Rackspace-hosted assets. This article provides some helpful application, load, and performance-benchmarking tests to help you get useful data. It also explains your obligations when performing the tests and provides technical guidance for performing the tests.
Note: When you perform any testing on or against Rackspace cloud servers, you are operating under the terms of our Global Acceptable Use Policy (AUP).
Policing and enforcement
Rackspace monitors all cloud host servers for activities that reduce virtual server performance. If we find a virtual server affects another, we reserve the right to hard reboot, suspend, or switch off the impacting server. We further reserve the right to suspend or cancel the impacting account.
Important: When performing the recommended application tests, load tests, and performance-benchmarking tests in this article, observe the following guidelines before and during each test and stop the test immediately if it breaches the indicated thresholds.
Be sure to continually monitor the effects of your tests as you apply load. Before running load tests, ensure that you know how to view actual RAM, disk IO, and network usage in real time. These metrics show whether a test risks interfering with other customers' servers on the same host. For specific thresholds, see the following Linux® and Windows® virtual server sections.
Alternatively, there are load-testing services managed with external servers located globally. For example, load testing with LoadView allows you to use their external servers and offers testing of API load or application load testing.
Linux virtual servers
Install and use the
screen package for your Linux distribution to run and view
the following commands at the same time. To compile the screen from the source, go
to the GNU homepage.
Use the following command to view RAM usage as you perform tests:
watch free -m
Don’t let the value in the Free column in the +/- buffers/cache line go
Use the following command to view disk IO usage as you perform tests:
Watch the %wa number in the second line. It might occasionally rise above
but it should not be above
1.0 for more than a couple of seconds.
Use the following command to view network usage as you perform tests:
sudo watch -n 10 -d /sbin/ip addr show eth0
Watch the RX bytes number. Every 10 seconds, the
-d argument highlights any
changes in this number. The 10-second pause gives you time to note the RX bytes
number before it changes. You can reduce the amount of math required to
calculate exact changes if you remember that at least eight digits must
watch -d highlighting—between each 10-second update
before you need to apply any arithmetic. For virtual machines with 2 GB RAM or
more, at least nine digits must change before you need to calculate the exact
The following table shows the maximum change in RX bytes per second by server size before exact change should be calculated:
|Cloud server size||Maximum change in RX bytes per second|
|2 GB||198,000,000||4 GB||330,000,000|
Windows virtual servers
To view and log the performance of a Windows server as you perform load tests, you need to use the Performance Monitor.
Run the following command to start the monitor:
This section describes some counters that you can use to ensure that you do not
exceed the thresholds and affect other customers on the server. You have to
change the scale of the graphs and also the counters in Performance Monitor,
especially regarding memory use. If you find these graphs hard to read and
track, we recommend using the
resmon.exe utility to track them.
Counter: Processor Information > % Processor Time > _Total
Purpose: Monitors CPU load as a percentage
Threshold: Don’t let this counter exceed 90 percent.
Watch the following memory-related counters during load testing:
Counter: Process > Working Set > _Total (or per specific process)
Purpose: Shows the current allocated or used RAM by the machine or specific application or process
Threshold: Don’t let this counter exceed 90 percent of the VM’s total physical RAM.
Counter: Paging File > % Usage > Total
Purpose: Review this value in conjunction with Available MBytes to understand paging activity on your system.
Threshold: Don’t let this counter rise above 50 percent of the total paging size.
Counter: Memory > Available MBytes
Purpose: Shows free RAM available to be used by new processes in megabytes
Threshold: Don’t let this counter fall below 10 percent of total physical RAM.
Note: If you are unsure of the amount of RAM installed, run the
command from the Run box.
Watch the following disk-usage counters during load testing:
Counter: PhysicalDisk > Disk Time > _Total
Purpose: Shows the amount of time that the disk is active
Threshold: 90 percent
Counter: PhysicalDisk > Avg. Disk Queue Length > _Total
Purpose: Validates the communication medium
Threshold: Don’t let this counter rise above
Watch the following disk-usage counters during load testing:
Counter: Network Interface > Bytes Total/sec > Network Interface
Purpose: Measures the number of bytes sent or received
Threshold: Don’t let link speed rise above the Maximum PerfMon Link Speed (%) value for your server size, as shown in the following table:
|Cloud server size||Maximum PerfMon Link Speed (%)|
|1 GB||1.50%||2 GB||3.00%|
Network latency testing
Remote testing can cause network latency. To test the network latency to our data centers, ping them and then review the response times or the ping returns. Each Rackspace data center has its own sandbox server that you can use for ping and other network tests. Because we host most of our cloud infrastructure in the same data centers, this test also works for cloud servers.
Ping is publicly accessible for the following servers:
Note: To remove DNS lookup effects, you might want to determine each test server IP address and ping the IP address directly.