Kernl's WordPress load testing service is a highly scalable load testing platform that requires no coding or knowledge of load testing to get started. It is built on top of RoboSwarm and utilizes Locust to generate load.
It is important to understand that you can and likely will bring your WordPress site to it's knees with our load testing tool. This is good, but with great power comes great responsibility! Start small and work your way up. If you have no idea how many users your site can handle you probably shouldn't start with a 20,000 user load test. Maybe start at 200 and see how things go.
With Kernl's WordPress load testing there are two concepts that you need to understand: Templates and Load Tests.
A "template" is a blueprint for load testing your site. It tells Kernl what routes on your site we should generate load against and also how frequently we should generate load against them. Kernl will automatically generate templates for you by using the WP-JSON API to fetch your site's layout.
A "load test" is the actual traffic generating test against your site. Kernl generates a Locust load test based off of template and instructs RoboSwarm to start the test. The load testing infrastructure is automatically created based on the number of users you select during test creation.
Before you can begin load testing you must verify that you own or manage the site that you will be load testing against. To do that, go to the "Site Ownership Verification" tab in the Kernl "Load Testing" area. Once there, add your site to the list of verified sites.
Now you need to verify your ownership of the site. To do that download and install the Kernl Site Ownership Verification plugin. Once installed, go to Settings, then General, and look for the site verification code input at the bottom. You may need to clear your site's cache after the change.
Finally, go back to Kernl and click the "verify" button on your site. When you see the "x" turn into a check mark you are free to start load testing.
The first step in running a load test against your WordPress site is to create a template. To do that, go to "Load Testing" from the top-level Kernl menu and then click the "Add Template" button in the upper-right. After that, enter the URL of the WordPress site you would like to load test (ex. https://blog.kernl.us).
Kernl will now attempt to read your site's layout via the WP-JSON API. If you have this API disabled you will need to re-enable it for this step. After the template has been generated and saved you can disable it again.
Once Kernl has your site's layout you get the opportunity to remove pages and posts that you don't want tested. You can do that by simply clicking the "remove" button for each route that you don't want tested. You can also adjust the frequency with which certain routes are tested. The default value is "1". With all values set to "1" each route will be visited with the same frequency as any other route. If you increase a value to "10", that route will be visited 10x more frequently than a "1" route. You can adjust these numbers to make your test more representative of actual traffic going to your site.
Once you have a template created you can run a load test! Go to the "Load Testing" section of Kernl from the top-level menu. Now click the "Start a Load Test" button. Below is a description of each option available to you for your load test.
Name - The name of your load test. Use something descriptive like "[SITE NAME] Nginx Config Changes" or "[SITE NAME] 3000 users, London, 2 hours".
Load Test Template - Have a big release and want to be cautious? Using a percentage based roll-out you can slowly release your feature to your users and gather feedback along the way.
Base URL - This is the URL of your WordPress site. You'll notice in the template that all routes are relative ("/some-path" versus "http://my.site.com/some-path"). The reason we do it this way is so that you can run the same load test against different environments. Maybe you don't want to run your test against your production environment, but instead of against staging? No problem, just change the Base URL.
Traffic Region - Not everyone is based in the US. In fact, most people aren't! Thats why we allow you to choose where your test traffic is generated from. You can select from 8 different regions around the world: Amsterdamn, Bangalore, Frankfurt, London, New York City, San Francisco, Singapore, and Toronto.
# of Users - The number of users that Kernl should simulate. Select a number that represents your best guess at a realistic amount of traffic. Be warned, if you set this too high it is very likely that you will bring down your site.
Duration - How long your load test should last in minutes. I recommend starting out small (15-20 minutes) and increasing ever higher as you gain confidence in your site's performance characteristics.
Spawn Rate - You don't want Kernl to throw 3000 users at your site instantaneously. Use the spawn rate to configure how quickly we should ramp up to the full load. I suggest somewhere between 1-5 users per second depending on your infrastructure.
Once you start your load test it will take several minutes before it becomes active. The reason for this is that we spin up as many machines as necessary to produce the load requested. If you request 10,000 users we have to spin up 15 machines or so which can take some time. If you find that your load test never starts, contact us so we can investigate what went wrong.
Now that your load test has started you'll want to monitor it's progress. To do that, Kernl gives you several different methods of observing the state of the WordPress site under test. Below is a list of the available metrics that Kernl captures during the load test and how to interpret them.
Requests - This graph shows you how many requests per second your site is handling throughout the load test. You may notice that this graph levels out as your test goes longer. This is fine, but be sure to check the "Failures" graph and the "Distribution" graph to make sure that all the requests are actually successful and that the experience for your users is acceptable.
Failures - The failures graph shows you the total number of failures over time. When you start to hit your WordPress site's maximum traffic this graph will likely increase very quickly. Be on the lookout for sharp increases and consider ending your load test if the error rate starts to spike.
Distribution - This may be the most interesting and important graph. It shows your what percentage of requests finish within some period of time. To read the graph, pick a column. Let say we picked the 90% column. Now see what the value of that column is. Perhaps it is 2500. This means that 90% of all requests finished in under 2500 milliseconds. If you see these numbers start to grow but your failure rate doesn't increase, it means that you are still serving traffic to your users but that their experience probably isn't great.
Final Results by Route - Once the load test completes Kernl will generate a report that contains detailed information about how each route performed during the load test. If you notice one route in particular performed poorly, it might mean that you need to focus your optimization efforts there.
Usage limits for WordPress load testing are a bit different then other limits on Kernl because spinning up new infrastructure on-demand can be expensive.
Kernl has the concept of "load test hours". This means how many hours worth of machine time have you used running load tests. For example, if you ran a load test of 2000 people for 30 minutes, you would have used roughly 2 hours worth of machine time. Why? Because we had to spin up 4 machines to generate that load, and each machine was run for 30 minutes. 30 * 4 = 120 minutes.
Data retention is also slightly different with our load test offering. Load tests generate LOTS of data which can be expensive to store. To help offset costs different plans have different data retention periods.
The maximum duration for load tests varies by plan as well. If you find that you are restricted by the load test duration, you'll need to upgrade to a higher Kernl plan.