Let's start with load testing. The term, load testing, is rather generic and is the simplest form of performance testing. The goal of such a test is to see how a system would perform under a specific amount of load. When you simulate a load test, you should know:
- How many concurrent users you are expecting on your server
- What transactions (user actions) you would like to simulate
- The duration you would specify to carry out this load test
Determining the number of concurrent users you are expecting on your server
Concurrent simulated users are the number of users you would like to simulate on your site at the same time. This is very different from visitors per day or per month. We wrote a little blog article that describes this more in depth and shows how you can determine this number using Google Analytics.
Once you have determined the number of concurrent users you have on your site, it is always a good idea to run a load test with 1.5 to 2 times the amount of users. This would help to show if your site is at its limits or has more capacity to spare.
Determining the transactions to simulate in a load test
Like in the charity party example shown above, not everyone does the same thing when they go to a party. Some are just there for the free punch, while others are there to network and make donations.
We refer to this as transactions, user actions or user scenarios. In some cases, it is important to simulate as many (or even all) of the transactions that are being carried out on your website as possible. Most site owners or developers have a good idea of which transactions are the most important to their particular service. For e-commerce sites the checkout process might be key, whereas a video streaming transaction might be more important in news-related sites. Beware though - not all web pages are equal.
Scaling up - How long should it take?
Should I ramp up the load in 1 minute? How about 15? Or maybe 3 hours? How long should I hold the load there for? The answer is - as much as we hate hearing it - it depends. If you're thinking of doing an instant ramp up or holding the load for a long time, you're probably looking at doing a Spike Test or Endurance Test. We'll cover more on that in future posts but for now, we'll focus on running a regular load test that has a gradual ramp up to simulate slightly more than your usual load (1.5 to 2 times the usual load).
If you have a static amount of resources (i.e. a fixed number of servers allocated to you), these systems usually adapt quite quickly and are able to ramp up quite fast. However, if you are dependent on dynamic resources like cloud servers, your system might need some time to acquire the necessary resource from your cloud service provider. Another thing to note is that if you have a smaller site with limited resources, you should scale up less quickly so you can see where the site starts to fall apart. If you're in doubt, Load Impact does provide some default recommendations for your ramp up.
These are just suggestions though, but the ground rule is that unless you are looking at simulating a Spike Test (covered later in our stress testing post), we would recommend giving more time for your test to ramp up in order to better simulate actual user behavior.
If you are ramping up to a large number of concurrent users, consider a test configuration like below, where the test ramps up in stages in order to ensure that your site is able to handle certain levels of load with ease before moving on to the next load level.
If you are using Load Impact, remember that the test runs through the entire load script, including sleeps (https://loadimpact.com/learning-center/faq/sleep-time), before it is able to report any results. This means that if your load script is several minutes long, it is a good idea to ramp up the test until a certain level and hold it there for a period of time to ensure that the results reported are for that load level.