Rackspace understands that customers need to determine the performance of their applications and acquire performance benchmarks for their Rackspace-hosted assets as part of offering a professional experience to their own customers. To help Rackspace customers acquire useful data without compromising their own or other Rackspace customers' server performance, we've provided some helpful load-testing risk indicators below.

Summary

This article sets out Rackspace's position on application, load, and performance/benchmarking tests. States Rackspace customers' obligations when performing these tests and provides helpful technical guidance for customers to use when performing these tests.

Note: Customers performing any kind of testing on or against Rackspace Cloud Servers should also bearn in mind that they are operating under the terms of our AUP as described at: http://www.rackspace.co.uk/legal/aup/

Policing and Enforcement

Rackspace monitors all of our Cloud host servers for activities that reduce performance of customers' virtual servers. If we find a customer's virtual server being used in a way that affects other customers' virtual servers, we reserve the right to hard reboot, suspend, or switch off the impacting server. We further reserve the right to suspend or terminate the impacting customer's Rackspace Cloud account.

To avoid uncomfortable conversations with us, customers that do want to perform application tests, load tests and performance-benchmarking tests should observe the following guidelines before and during each test and stop the test immediately if the below thresholds are breached.

Load-Testing Guidelines

Good testing practice requires that you continually monitor the effect of your test as you apply load. Before running such tests, ensure you know how to view actual RAM, disk IO and network usage in real-time. These are where the early-warning signs will appear that a test risks interfering with other customers' servers on the same host.

On Linux Virtual Servers

Install and use the 'screen' package to be able to run and view the three commands below at the same time.

RAM: - Use the following command:

watch free -m 

Becareful not to let the 'Free' column in the +/- buffers/cache line go lower than 1,000

Disk IO - Use the following command:

top

Watch the '%wa' number in the second line. It may occasionally rise above '1.0' but it should not be above '1.0' for more than a couple of seconds.

Network usage - Use the following command:

sudo watch -n 10 -d /sbin/ifconfig eth0

Watch the 'RX bytes' number. The '-d' argument will highlight every ten seconds any changes in RX Bytes numbers. The ten-second pause gives you time to note the 'RX Bytes' number before it changes. Obviously, you can reduce the amount of maths required to calculate exact changes if you remember that at least eight digits need to have changed – per watch's handing highlighting – between each ten-second update before you need to apply any arithmetic. For virtual machines with 2Gb RAM or more, at least nine digits need to have changed before you need calculate the exact change. 

Windows virtual servers

To view and log the performance of a server you will need to use a utility called perfmon.exe, here are some simple counters to use to ensure that you do not exceed the thresholds and affect other customers on the server. You will have to change the scale of the graphs and also the counters, especially when it comes down to memory utilization. If you find these hard to read and track then we strongly advise using the utility resmon.exe to keep an eye on them.

Processor utilization

Counter: Processor information > % Processor Time > _Total

Purpose: Monitors CPU load in %

Threshold: Don't let this counter exceed 90%

Memory utilization

There are several memory-related counters you should keep an eye on during load-testing.

Method 1:

Counter: Process > Working Set > _Total (or per specific process) – 

Purpose: Shows the current allocated or used RAM by the machine or specific application/process.

Theshold: Don't let this counter exceed 90% of the VM's total physical RAM.

Method 2:

Counter: Paging file > % Usage > _Total

Purpose: Review this value in conjunction with Available Bytes to understand paging activity on your system.

Threshold: Don't let this counter rise above 50% of total paging size.

Method 3:

Counter: Memory > Available Mbytes

Purpose: Free RAM available to be used by new processes in Mbytes.

Threshold: Don't  let this counter fall below 10% of total physical RAM.

Note: If you are unsure of the amount of RAM installed, run the msinfo32 command from the run box.

Disk Utilization

Counter: PhysicalDisk > Disk Time > _Total

Purpose: Amount of time disk is active.

Threshold: 90%.

Counter: PhysicalDisk > Avg. Disk Queue Length > _Total

Purpose: Validates the communication medium.

Threshold: Don't let this counter rise above 4.

Network Utilization

Counter: Network Interface > Bytes Total/Sec > Network Interface

Purpose: Measures the number of bytes sent or received.

Threshold:  Don't let PerfMon's link speed rise above the “Maximum PerfMon Link Speed (%)” value for your virtual machine's size per the table below:

Network Latency Tests

To remove the network latency-induced components of any remote testing you perform, you can test network latency to our various datacenters by pinging them and reviewing the ping returns' response times. Each Rackspace DC has its own sandbox server you can use for ping and other network tests. Since most of our Cloud infrastructure is hosted in the same DC's, this will work for the Cloud too.

Ping is publicly accessible for all of these servers:

• sandbox.dfw1.rackspace.net

• sandbox.sat2.rackspace.net

• sandbox.iad1.rackspace.net

• sandbox.lon3.rackspace.net

• sandbox.hkg1.rackspace.net

• sandbox.ord1.rackspace.net

Note: You may want to determine each test server's IP address and ping the IP address directly to remove DNS lookup effects.