
In the spring of this year, our
team received an order for load testing and optimization of several versions of the
CMS 1C-Bitrix . Great task, but how to do it? In this article we will talk about how to test properly and what does “
load testing ” generally mean? And in the following - how we tested Bitrix and what we did.
Goals
Let's start with goals, because the goal of load testing is not just to fill up the site, such results do not give anything for the development of the project. Our task is to understand how the system behaves under load, where the bottlenecks are and how to recognize them.
Lyrical digression . A few years ago, the project “ Rambler-Photo ”, is carried out load testing. System administrators are carefully studying the behavior of the system. The result is strange - the system spends most of the time in System Mode (this can be seen with a simple top utility). This means that instead of executing the project code, the operating system is running, wasting time on context switches and making system calls.
')
According to the results of the analysis (shared with programmers), it turned out that HTML :: Mason (template engine used in the Rambler-Photo project) performs several dozens of checks for the presence of various files “by default” for each request. One directive in the HTML :: Mason settings solved the problem.
How to spend?
This terrible scheme is shown to show: even when executing a simple CGI script, many components, many interfaces and subsystems are involved. Hence the most important conclusion:
The load is given on the system as a whole!
After a little thinking, we will realize that it takes a long time to test the loadable system while imitating various actions of editors and users. For example, loading a new article may cause a cache to drop, which in turn leads to a sharp increase in the number of operations performed (the cache must be filled!). Therefore:
The load is given for a long time
What should a stream of users look like? The answer is simple - as close as possible to real conditions. The best option is to take a real site on 1C-Bitrix and real log files and, having analyzed them, compile:
Load profile
Users not only walk on different pages, but also walk differently. The trouble of any large project is users on modems;) Imagine that such a slow imposing user requests a page, connects to a heavy mod_php server, the server quickly and quickly processes it and is ready to return it to the user. And the user slowly begins to take this page, for example, at a speed of 1 kilobyte per second. Thus, with a page size of 100 kilobytes, our php server will be busy for 100 seconds, almost two minutes.
It is obvious that twenty of these users are able to occupy all available apache children (for example) and he will stop responding. The classic situation is that the machine is not loaded, but the web server is not responding.
For these purposes, a light frontend is put in front of a heavy backend, capable of processing thousands of requests simultaneously.
Accordingly, we have to test, taking into account the fact that some users will slowly take away the result of the server’s quick work:
Load system should simulate slow users.
Well, the last rule for today - remember the example we gave at the beginning of this article:
Everybody is watching the loaded system: testers, administrators and developers!
What we should get as a result, what is the degradation curve, how to interpret the results and how 1C-Bitrix surprised us, we will talk next time.