In our last article, we talked about the importance of Load Testing for websites and web applications.
This time, we would like to introduce you to the Apica System LoadTest(tm) application that allows you to test the limits of your site.
Apica LoadTest Overview
Apica LoadTest is basically a system that allows you to use different test profiles against any given web server.
Through a series of simple steps, you can specify which URLs are going to be tested and fine tune variables like concurrency or frequency.
You will then get a full report on how the test went, what the average response was and other relevant tidbits of information that will form a strong foundation for your future decisions on how to optimize the site.
First of all, you need to have a site or application ready for testing. Ideally, it’s located on a separated test or development server and you are safe to perform as many tests as you’d please.
Sometimes, you are forced to do that against live servers. In that case, care must be taken to avoid bringing the site down. It’s recommended that you have absolute control over the site in terms of remote access and redundancy or you will find yourself in an ugly situation.
So, let’s just assume that you have a simple website ready. You have also a small database connected to this website and everything is prepared to receive traffic.
Naturally, you also need to become a customer of Apica, so you can request a quote or information, here.
Our first test class
So we log into the customer portal and immediately go to the “Generate runnable loadtests”.
Here we will create our profiles or “classes” as they are called inside Apica.
In order to do this you have to provide up to three urls, 1 of them is mandatory and the other two are optionals. On each URL you can fine tune which files should be downloaded by the test application, you can for instance tell it to ignore script files or images.
You can optionally select the urls and files through a Selenium script, which is part of the Selenium Test Automation platform.
Two of the most important variables you will need to setup are “Think time per page” expressed in seconds. This basically gives a small delay to the testing application. When we browse a website, we are not clicking (okay, not always) as mad men on the first link or image we see. This nice touch helps the system simulate a real person navigating the site. There is also a variance to add further randomness.
Once we are done, we click on “Generate executable file” which could take a few seconds.
Our first bombardment
Okay then, we have our first “class” configured with one or more URLs. We must go to the “LoadTest scheduler” tab.
Here we select the aforementioned class file on “Available class files”. Then we go onto the real magic, here are the most important variables that will give us absolute control on how we want to stress our site:
- Number of concurrent users: How many “users” will access the site at the same time.
- Load test duration: How many minutes will the test last.
- Max. network bandwidth: This gives us the ability to simulate many low connection users or a few with high speed broadband.
- Request timeout: How many seconds should the users wait before they consider the connection timed out.
- Startup delay per user: Useful to avoid all users starting at once and clogging the server. On the other hand, you can put a small number to simulate a heavy peak of connections.
- Exec agent: Here we can select several agents, on several locations (Europe and US).
- Start loadtest immediately: We can tell the system to start right away or schedule it for a specific date and time.
Once we are happy with the parameters, we click on “Initiate loadtest” and wait for the job to be inserted on the queue.
A legend like the following should appear:
“Loadtest job saved with id 939.
You can check the status under the ‘My loadtest jobs’ tab.
Remaining user count for this time period: 490”
If we go to the “My loadtests” you will see the row corresponding to this load test job.
If this job is ongoing, you will be able to refresh it with the corresponding button and if you click on the looking glass, you will get a popup with real-time information on the process.
On this window, as you can appreciate, you have several graphs describing how your website is performing. Of course, it’s always a good idea to have tools for different metrics on your backend side, so you can cross-reference both results.
Here you can abort the job if you want and take a peak at important information such as “Average time (ms)” which indicates how much are your pages taking to load on the client, Soft errors and Hard errors which give you an overall idea of how much failed requests there are.
You can click on the graphs to see a detailed view.
Once the job has ended, you can come back anytime to the “My loadtests” tab and check the report.
What you are aiming here is to have as few errors as possible on a specific load condition. For instance, If you know your site will need to handle 100concurrent real users, you would probably want it to be able to manage 150, just to be sure.
Until next time
We just saw how easy it is to test a website for performance using part of the Apica System. This combined with other tools, enable you to tweak your site to its fullest.
Next time, we’ll do a couple of real tests against our own virtual servers at City Cloud and give you interesting data about how web servers perform under load and also, to understand a point of reference in this elusive world of web performance.