Web Performance Technology Reports


How many users should I load test my system with?

August 20th, 2008

When customers are preparing to buy our load testing software, they frequently ask “How many users should I load test my system with?”. Naturally, we can’t answer that question without a lot more information about the performance requirements and the expected usage of the web application.

If the application will service a known number of total users (common with internally-deployed systems), then it is a simple matter of estimating how many users are likely to be using the system at the same time. For example, if no more than 10% of the employees are expected to access an HR web application at the same time, you would test up to 1000 virtual users in a company with 10,000 employees.

However, the customer frequently has only rough estimates of expected traffic. For instance, they may know how many page views/hour that they want to handle or there may be web server logs from an existing system that can be analyzed. While that information is not ideal, it is usually enough to get a ballpark figure for initial testing.

In either case, the first step is to determine which usage scenarios will be tested. Each usage scenario defines a series of pages on the site that is visited in order to accomplish a task. For instance, a typical scenario in an e-commerce application might consist of these steps:

  1. Navigate to the homepage
  2. Search for a product
  3. Choose an item from the search results
  4. Add the item to the shopping cart
  5. Complete the checkout process

If server logs are available, these may help to identify the most commonly visited pages - and from that it may be possible to identify the most common scenarios. In most applications, there will be a number of scenarios to be tested, but for the purposes of this discussion we will assume there is only one.

The next step is to determine how much time each user spends at the site. If server logs from an existing system are available for analysis, a log analysis program may reveal how long, on average, a user spends on the site. That would be a good place to start. Another common technique is to recruit 5 people who are not familiar with the system and have them perform the usage scenario. An observer would measured the amount of time spend on each page during the process. If that is not possible, then some guesswork will be required. For our example, we will use a visit duration of 2 minutes.

Armed with a number of pages per testcase and a testcase duration, we can now use the desired number of page views/hour to compute the number of virtual users. In our case, we will use 100,000 page views/hour as the target load level.

For our calculation we will use these variables:
PR = page rate (pages/hour)
TD = testcase duration (minutes)
NP = number of pages in the testcase
VUs = the number of virtual users required to generate the desired load

VUs = (PR * TD) / (60 * NP)

In our example:
PR = 100,000 pages/hour
TD = 2 minutes
NP = 5 pages in the testcase

VUs = (100,000 * 2) / (60 * 5) = 667

667 Virtual Users would be required to generate 100,000 page views/hour in the above scenario.

Note that this assumes the system performance does not degrade from the baseline performance. As the performance degrades, each user will naturally generate a lower page rate, since each page will take longer to complete - thus raising the testcase duration. Depending on what the expected or acceptable level of degradation is, the number of VUs may need to be raised to achieve the desired page rate.

If each of the 5 pages was expected to degrade by 3 seconds, that would raise the testcase duration to 2:15 (or 2.25 minutes). Plugging the new testcase duration into the above formula would raise the VU requirement to 750 simultaneous users for the load test.

Good luck!
Chris

Load Testing a cluster of web servers

August 1st, 2008

Ok - so you’ve spent months putting together a shiny new mission-critical web application, complete with multiple web servers, a few application and/or database servers. There is a load balancer in the mix or maybe you are using Microsoft NLB (Network Load Balancing). The system is nearly ready to deploy and it is time to run a load test. The first inclination is to fire up the load testing tool and throw the maximum expected load at the entire cluster. After all, there is no sense in wasting time with the smaller pieces, right? Wrong.
There are 2 very simple reasons:

  1. How will you interpret the results?
  2. If the system falls on its face, the political ramifications can be significant.

I’ll start with #2 - Since we became a provider of load testing services, we have seen many systems that fell on their face in a highly publicized first test of a system. After spending a lot of money on a new system, the project sponsors are now very worried. The opponents are lobbing tomatoes from the cheap seats. The project manager is taking a lot of heat. This doesn’t always happen, but when it does, the project can be derailed, along with the careers of those responsible for it.

#1 might require more explanation. If the system doesn’t perform perfectly on the first try (and in my experience they seldom do), you will have no idea where the problem lies. Is the web application optimized for good performance? Is there a problem with the load balancer? Is the web application not tuned properly for operating in a cluster? Are the web servers configured properly? etc.

In our experience, a cluster should never be tested until a scaled-down version has been tested - preferrably the smallest version that can be constructed without changing the architecture (for example: 1 web server, 1 application server and 1 database server). Ideally, this happens early in the development process.

The simple reasoning is this - until single server system has been tuned for best performance, there is little point in testing the cluster. The odds are very good that you will backtrack and test an individual server anyway. But more importantly, the odds of success for that first big test are much higher if you have already load-tested and tuned the single-server version for maximum performance.

Load Test Configuration - using a stepped ramp

July 15th, 2008

One of the most common load testing mistakes made by beginners is their configuration of the user ramp rate. This is best illustrated with an example configuration that we see frequently. Read the rest of this entry »

Open Source PHP Accelerator Increases Performance 2.8 Times

April 24th, 2008

The latest installment in our PHP performance series takes a look at the open source APC module, which is described this way: “APC is a free, open, and robust framework for caching and optimizing PHP intermediate code.” The results were dramatic, as the module increased the user capacity of the reference PHP application by 2.8 times.

Read The Article

The Impact of Zend Platform on PHP Performance

March 14th, 2008

Load Testing SugarCRM and the Zend Platform

The performance of our reference PHP application under load (a default SugarCRM installation) showed a 140% increase, measured by total system capacity, after installation of the Zend Platform.

Read the article

Load Testing SugarCRM in a Virtual Machine

January 15th, 2008

Determining the CPU cost of virtualization with VMware ESX

The
performance of our
reference application under
load (a default SugarCRM
installation) on a virtualized server showed a 14% decrease, measured
by total system
capacity, compared to the same system running natively on equivalent
hardware.

Read the report

Impact of Zend Optimizer on PHP Performance

November 5th, 2007

Load Testing SugarCRM and the Zend Optimizer

This article measures the performance impact of the Zend Optimizer on a real-world processor-bound PHP application (SugarCRM) under load. Our measure of performance is user capacity. We define that as the number of simultaneous users that the system can support while meeting the specified performance criteria. The performance critera for this test require that all pages load within 6 seconds and no errors are encountered in the application.

Read the report

Safari 3 Windows Performance Analysis

October 12th, 2007

Evaluating Apple’s Browser Performance Claims in The Real World

On June 11th, Apple released a Windows beta version of its OSX web browser, Safari 3.0, claiming its the “fastest browser on Windows”. The claims were based on the results Apple found while running the iBench benchmark from Ziff Davis, with separate measurements for HTML, JavaScript performance, and application start time. While benchmarks are invaluable for performance evaluation, we set out to see if those claims would make a difference in actual browser usage.

Read the report

Load Testing a Virtual Web Application

April 2nd, 2007

Measuring the Performance Impact of Virtualizing a Web Application Server

Virtualization is hot. Over the past few months, it would be difficult to pick an IT magazine out of my stack that does not have an article on Virtualization. Even in our small company, we have two VMware servers. This allowed us to reduce 9 underutilized servers down to two physical machines. Because the original severs were severely underutilized, the virtualized servers actually perform better (running on newer hardware). They are easier to manage - especially for backups. We have reduced the risk of configuration changes, software installs and upgrades by taking snapshots before these procedures. What’s not to like?

Read the report

Comparing Apache Tomcat Performance Across Platforms

March 12th, 2006

Part 2: Performance and Distinct Error Handling under Computational Load

In this report the same tests as part one are re-run, this time with no memory limitation showing a marked increase in Tomcat performance on Linux over Windows.

Read the report


Satisfied Customers





Copyright © 2008 Web Performance, Inc.

Website design and development by DesignHammer Media Group, LLC (Durham, NC)