Previous 1 2 3 4 5 Next

Initial Tests

A few days later, we were ready to execute the first tests of the site. Initial tests were not promising. Under a simulated load of 100 simultaneous users, the system returned pages, on average, in less than 3 seconds – but that was only after the first group of users had passed the homepage and login steps.

During the ramp-up, the average page durations (APDs) peaked over 12 seconds. After the second group of users was added (for a total of 200), average page durations exceeded 20 seconds, as shown in this chart:

Initial testing shows poor performance
figure 1: Initial testing shows poor performance - 20-30 second page durations at 200 users

The metrics gathered during the test (via Load Tester's Server Monitoring Agents) indicated that hardware was not the bottleneck - neither CPU, memory or disk were taxed during the tests. A series of tests and subsequent investigations indicated that the network and load balancer were not the limiting factor either.

Next, we isolated each SharePoint™ web server in the cluster and tested them individually. The tests revealed a number of differences between the servers. For instance, one server was not compressing the page content. More importantly, we found that running with only a single SharePoint™ web server resulted in better performance (average page durations under 6 seconds) up to 300 users – three times the capacity of the system with 3 web servers (note that this test ran for a shorter period – thus the change in scale on the Users axis and the time axis).

A single server performed better
figure 2: A single server performed better, but performance is still not acceptable

We also noted that CPU utilization was not scaling linearly with the applied user load. At ~400 users, the CPU utilization peaked on the web and database servers at ~60% and ~30% respectively:

CPU utilization levels off after 400 users
figure 3: CPU utilization levels off after 400 users

Additional user load did not raise these levels – in fact, CPU usage declined as more load was added. After the peak, additional load did not raise the key throughput metrics, such as hits/sec, pages/sec and bytes/sec. The server metrics did not indicate a bottleneck in any other hardware category (network, memory or disk). This left software or software configuration as the most likely limiting factor. The most common culprits in this situation are connection pools, thread pools, resource contention and database locking.

Previous 1 2 3 4 5 Next


Copyright © 2015 Web Performance, Inc.

A Durham web design company


For Prices Call (1) 919-845-7601 9AM-5PM EST

After hours? Prefer email? Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
Product Needs

Request a Quote

Our experienced performance engineers have tuned hundreds of systems for companies large and small, and know just where to look, saving you time to market and money. We'll run your website through a complete performance evaluation, then tell you exactly how many users your site can support, including such important details as the effects of "the last mile." We'll also pinpoint potential problem areas and give you a full report detailing what needs to be fixed and where.

About You
Product Needs