Check the site resiliency (with Habra )

source:. http://habrahabr. ru/blogs/hi/109247.
Author: sunnybear.

Check the site resiliency.

This is another post of their traditional New Year's eve is a series of site verification of fault tolerance and a willingness to accept all of your visitors puzzled choice of gifts or New Year's discount. In this issue I will discuss the creation of tests in verbose mode using record actions (Proxy recorder), which allows almost completely emulate the behavior of real users in real browser on your website. Also some will be discussed by analyzing the graphs themselves resiliency.
So there you go.

We'll discuss the use of service. Load Impact. First we need to make the actual test.

Creating a test.

Most of the described service options is available only after registration, but if you just need to check how the site behaves under stress, you can specify the site address directly to the. home page. And then see how you can interpret the charts (as at end of article ). If you are interested in more detailed and accurate assessment, you should still register.

Record of Action (Proxy recorder) is available in. >>Advanced mode - Load script generation - Record session. Here you can specify a set of HTTP-requests to emulate any visits to your site, and any number of concurrent users. Very handy tool. To use it you need only specify the appropriate settings on your browser.

As for the settings.

At the beginning of the recording is given a hint to the proxy settings (probably with a screenshot ready for the current browser). This allows you to really drive a minute all the options. The only thing worth paying attention - is the port. For each new use of it is created separately, and separately also checked.

If you use a proxy it is possible to test all the dynamic and AJAX- requests: includes a visit to the site they just recorded and then available in the appropriate field when you create a test....

But before you use a proxy, it is necessary to check that everything is configured correctly. Otherwise we will have to record all the test script again.

Finally, the last stage in the formation of the test - a choice of limits for users and a step increase in load.

For smaller sites, as I mentioned above, rather 50 simultaneous visits. Even at these numbers it will be clear whether a site ready for some sort of load or not.

For a simple test failover site, you can specify a limit in the area of ​​500-1000 users in 100. This will completely sane site picture of the behavior under load, but greatly reduce the time of testing, and limits on traffic.

If necessary, a detailed picture will specify the amount of 10-20 members. This ensures that the test will tell you exactly what you get true power rating site.

Once all parameters are set, you can confirm test ( for users of less than 500 - the usual formal, then it will be necessary if the file loadimpact. txt with your login to the site root ). Also, when you save the settings made ​​a trial run to see if everything is set to true.

Run the test.

Now the most interesting. After we spent a few ( tens of ) minutes, which set up a test, it is time to start and. Self testing can take up to several hours ( if a lot of steps), and in general it is best done in a period when the user activity (eg at night). After the test you get a lot of summary charts, let's take a look at them.

The main graphs is server response time (user load time) and complete loading time (accumulated user time). The last parameter may have little relationship to real -time site load under load ( because the servers are in Sweden), but the dynamics will be shown exactly.

Server response time reflects the cost of the server to create a 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 its loading. Also, when sootvetvuyuschih server settings can begin to be granted a timeout error (nginx, for example).

For a schedule of good sites like resiliency exponent (as in the example above), which crosses the value in 10 seconds 3-5 times more than the current peak load. This means that the sudden increase in the number of visitors your site is, in principle, bear the load.

Worst case, if the graph is going up dramatically, even with an increase in the number of visitors in 2 times (or even at the peak value ). In this case, you need to take action optimizing, and urgently.

But it's good, when any ( test ) load schedule will be a straight line ( with minor deviations). This means that the margin of stability at the site is very good, and oen.

Also, the test results can be compared to a number of different resources (HTTP- requests) to find the most narrow spot ( sometimes it may even be a dynamic picture that consume too much server time ). In this case, even with quick returns HTML-document site will load slowly. But almost always the main problems are in the rate of creation of HTML-pages.

summary.

Load Impact. is a unique tool for load testing, and thus allow themselves to ask any scenario, user behavior and to check how the site ready for them. At the same time a lot of information available free of charge during the test up to 50 users.

I hope this article helps you prepare your sites for the New Year boom:).