These days, when during the development of the site it was not necessary to pay attention to the cleanliness of the code and the rate of calls to the database, are gone. And even the concept of "caching" was generally not pronounced in the development of the site. And now even the little-known resource may involve overnight goers if it turns out to be a successful site link ... but this is about something else.
Optimization of the performance of sites is a comprehensive approach. These are caching, server resources, optimization of queries to the database and so on and so forth. But know is not about it. How to check if everything is done? We use a unique service Load Impact.
Most of the features described by the service are available only after registration, but if you just need to check how the site behaves under load, you can specify the site address directly at the main page. And then you can see how you can interpret the graphs. If you are interested in more detailed and accurate assessment, you should register.
As I mentioned early, it is enough 50 simultaneous visits for small sites. Even at these numbers it will be clear whether the site is ready to at least some load or not.
For a simple test of fail-over of the site you can set a limit in the 500-1000 users with step 100. This gives quite clear idea of behavior of the site under load, but it strongly reduces both test time and limits on traffic.
If it is necessary a detailed picture you will have to set the step of 10-20 users. This ensures that the test will run maximally exact and that you will get a true assessment of the power of the site.
Once all parameters are set you can confirm the test (for users with less than 500 - the usual formal, then it will be necessary the file loadimpact.txt with your user-name in the site root). Also, when you save the settings you should made a test run to see if everything is set correctly.
And now there is the most interesting part. After we spent a few (dozen) minutes to set up a test, it's time to run it. The testing could take up several hours (if it is a lot of steps), and in general it is better to run it in a period of lowest user activity (e.g. at night). After completing the test, you will get a lot of summary charts; let's take a look at them.
The main graph is the response time of the server (user load time) and full-time of load (accumulated user time). The latter option may have little relevance to real-time download site under load (because the main servers are in Sweden), but the dynamics will be shown precisely.
Server response time reflects the cost of the server to create HTML-document with an appropriate number of simultaneous visits to the site. There will be a critical point in 10-15 seconds, when up to 80% of users will simply leave the site without waiting for it to boot. Also, with suitable server settings it can begin a timeout error (nginx, for example).
For good sites the schedule of resiliency resembles an exponential (as in the example early), which crosses the value in 10 seconds in 3-5 times more than the current peak load. This means that a sharp increase of the number of visitors, your site is, in principle, bear the load.
The situation is worse if the graph is going up dramatically, even as the number of visitors grows in 2 times (or even at the peak value). In this case, you need to take action optimizing, and urgently.
Load Impact is a unique tool for load testing, and thus allows itself to ask any scenario, user behavior and to check how well a site ready for them. In this case, most information is available free of charge during the test up to 50 users.
QATestLab is a team of professionals working in various fields to ensure the quality of IT projects: test managers, manual, automated and load testing test engineers, consultants and trainers.