The busy holiday shopping season is only a month away and the National Retail Federation forecasts 12 percent growth in online sales over last year. Sounds like good news, doesn’t it? It is, if you can keep your virtual doors open and sales flowing around the clock. Recently, Rackspace offered up five tips to prep your e-commerce site for the holiday crunch. We invited some of our e-commerce partners to provide a guest blog post looking at those tips and offering further advice.
Submodal is a web design studio and a Rackspace e-commerce partner that works with companies of all sizes – from startups to established consumer brands. Here, Submodal Director of Engineering Jason Gordon discusses why load testing is a critical step for your e-commerce site.
We know how crucial load testing is: it’s the reason such a detailed approach has been developed to address this aspect of web application deployment. Here’s what you need to know about load testing and all the issues that come with it.
When someone uses the term “load testing,” they are usually talking about a larger set of tasks involved in delivering a responsive web application.
For us, load testing is the final step in the testing process, during which all performance tests are run simultaneously over a period of time to see how the system will hold up for a couple of days. It’s similar to how automotive engineers run an engine by itself for a few months straight to test its safety and capabilities.
“Load” is the number of concurrent connections to a system. Since we specialize in Magento, load will be discussed here in the context of a Magento e-commerce application. We also run another CMS in tandem with Magento, which helps determine what type of users a system will have: non-authenticated shoppers, authenticated shoppers and content administrators. A performance plan should include tests designed for each of these three users, because each type of user creates a different load on the system.
Before the performance-testing phase, it’s important to follow a few development best practices. First, minimize HTTP connections as much as possible by:
The next step is to determine which parts of each page don’t change and are cacheable. In our applications, most parts fall into this category. For the sections that don’t fit this bill, we often employ ajax to fill in the “holes,” and Varnish’s ESI technique (“edge side includes”).
By implementing a very lightweight code review process, we identify obvious performance issues in new code. By running our code tests with a tool such as JMeter during the development process, performance and load testing is much easier later on, and poor performing code is identified earlier in the process.
The process essentially tests from left to right; as a request comes into the system, it gets jiggled around, and then comes back to the browser. The goal is to determine how many of these types of requests a system can handle. Here’s a simplified view of the request flow:
Here’s what is being tested:
In practice, the load test environment ends up being:
The first step is to define the set of requests that makes up the basis of how users will interact with the site, such as:
We use apache bench to quickly benchmark each request in a test list. This is when the reverse proxy cache system will be tuned to ensure it is getting as many hits as possible. Apache bench will also give a basic sense of how many requests per second the system can handle for each URL.
Next, we create scripts to generate test data and simulate user interaction. Although we create some stand-alone scripts for data generation, the main goal is to make a large suite of scripts for JMeter. A script will be made for each test path, cookies and all. JMeter scripts are easy to make into templates, and can be copied and pasted to create new ones.
A list of necessary scripts:
The idea is to run these scripts both individually and simultaneously to find performance limits. This will fill up a database with lots of data so that during load testing you can identify bottlenecks that occur only when a good amount of data is present.
Then comes the testing system setup. Laptops quickly run out of capacity for testing, so load testing tools usually get set up on cloud machines. During load testing, several machines will run for several days.
Now it’s time to actually run tests. Because running tests can be very time consuming, it’s important to ensure we get the most information possible out of each test run and avoid wastefully repeating the same test. To do so, we create a spreadsheet with the following information:
Using a set of monitoring tools allows us to obtain truthful data about actual test performance in simple visual graphs: Cacti for capturing metrics, MONyog for monitoring the database and statsd to put stats logging into code so we can monitor code performance in real time. By saving this information in spreadsheets, we achieve provable results and can identify the most effective tests.
Once we churn through the performance tests and apply all possible optimizations, we start running longer tests. A nice side effect of all this setup is that it puts in place a monitoring system that can be used throughout the life of the site, which is very helpful during new software releases.