One of the key capabilities of Web Performance Load Tester is the page grouper. This is one of those systems for which, the fewer people notice it, the better it is performing. Essentially the page grouper takes a long list of HTTP transactions in a test case and organizes them, using timing, and/or content and referrer analysis, into a series of logical pages.
If we do this well, we assume that the list of pages we see in a test script after a recording are the same as the logical pages an end user would witness in a browser — each … Continue reading »
Load Tester is designed to recognize common use patterns and transform them into working test cases with a minimum of user intervention. Our clients appreciate that Load Tester does a tremendous amount of work automatically. But, any load testing tool must be prepared to exercise the complexity of its target, and for some web applications even a simple test case can involve hundreds of variables.
This post will try to elucidate the stages of the recording process, which are, roughly:
Recording
Initial Inspection
Automatic Configuration
Manual Configuration
Replay
Validation
During the recording stage, we manually perform a use case in a web browser. Load Tester monitors our work … Continue reading »
Functional test suites do NOT make good load tests! Functional test suites have an inherently different purpose than performance test suites. It is always tempting to take your suite of functional tests and use that as the basis for your load test. This is especially true if your testing tool supports both functional and load testing.
The purpose of functional testing is to determine if the site works correctly. As every good tester knows, this means testing the edge cases. What happens when the user does something unexpected? What if I complete the “How many children do you have?” field by … Continue reading »
The first step in building a load test is to choose the scenarios to test – this is frequently harder than one might guess. When we ask customers which scenarios we should test first, a common answer is “test them all”. While this might yield the most accurate results, it is rarely practical for the allotted budget and schedule. There is great value in getting load test results sooner rather than later – so we recommend testing as early as possible and taking an iterative approach.
Start with the most common operations that users will … Continue reading »
Just because you are paying for a 100MB connection does not mean that you will get that much. And if you don’t test it, you will not know until it is too late.
Just because your admins insist that your test environment is an “exact copy” of your production site does not mean that they are. And if you don’t test it, you will not know until it is too late.
Just because your web server was the bottleneck in the last test and you added another front-end server and put a load balancer in … Continue reading »
If your project is replacing an existing system, it is immensely valuable to establish a baseline for the new system based on the existing system. Start by analyzing the usage patterns of the existing site. What operations are most common? What paths are users following through the site? How many users are accessing the system at various times throughout the day? Wherever possible, this data should come from system logs rather than assumptions and guesswork. Then start designing your test:
Create a mix of scenarios that account for 70-80% of the site usage
Add any other scenarios that are known, or suspected, … Continue reading »
Web Performance is one of the sponsors, along with OpenNMS, of Jason Tower in his Spec E30 race car for 2010 and 2011. He’s consistently made progress as a driver, so that by the end of the season he was able to place third in all three races in October’s Great Pumpkin Run at the Carolina Motorsports Park!
A video of the first race is below, along with Jason’s blow-by-blow description:
“Saturday qualifying was smooth except for a GTS4 car that spun, I nabbed 5th of 17 cars with only a tenth of a second separating P3 and P5. … Continue reading »
Looking for the snappiest, fastest web server software available on this here internet? So were we. Valid, independent, non-synthetic benchmarks can be difficult to find. Of course, we all know that benchmarks don’t tell us everything we need to know about real-world performance; but what’s the fun of having choices if we can’t pick the best?
Exactly. I decided to do a little research project of my own.
Test Plan
I selected for this exercise recent (as of October 2011) versions of Apache, Nginx, Lighttpd, G-WAN, and IIS — a list that includes the most popular web servers as well as web servers … Continue reading »
Out of our entire list of services customers, only a handful have satisfied their performance goals on the first test. Of those, all but one had been through a performance testing campaign with us in the previous year. If this is the first time for your project or your organization to undertake performance testing, you are virtually guaranteed to fail the first test.
There is a large list of things that can go wrong with modern web systems – firewalls, load balancers, databases, web servers and, of course, the code. One setting buried deep in an … Continue reading »
This post will focus on providing tips for implementing a CDN. Since there are multiple CDN providers, each with their own setup procedures, configuration of a CDN will be contingent on the provider and the service rendered. However, whether it be a CDN for a blog or website, the following pointers will be useful while implementing a CDN.
Ensure that YSlow recognizes the CDN. YSlow is pre-loaded with a list of popular Content Delivery Networks, however all CDNs are not included in the list. If a CDN is not included in the list, a site will most likely get an F … Continue reading »