I myself have not used the services of domestic hosting providers for a long time and for my own use I rent a server in Germany. And one wonderful morning I decided to check how high-quality those services that Russian hosting providers offer us and for this it was decided to select several domestic VPS, install the necessary software on them, test site and conduct large-scale load testing.
For testing, 7 domestic hosting providers providing test period services for VPS (VDS) were selected randomly, which I could not use for my own good purposes. The cost of a VPS varies from 500 to 700 rubles and belongs to the budget segment. So, our applicants:
Testing methodology:
The testing method is simple - we send tons of requests to the WEB server from a remote server and see how the VPS behaves. We can say that this is a small DDos.
As an attacker, I used my rented server in Germany in the following configuration:
')
- Intel i7 2600 Quad-Core + Hyper-Threading;
- 32 GB of RAM;
- 1 Gbit channel.
All tested VPSs have an OS installed - Debian 7 x64. In cases where the hoster does not support this OS, another OS is used, as indicated above in the description of applicants.
Basic installed software on a VPS (Debian 7):
- Apache 2.2.22;
- PHP 5.4;
- MySQL 5.5.
Basic VPS Installed Software (Debian6):
- Apache 2.2.16;
- PHP 5.3;
- MySQL 5.1.
To obtain the most accurate results, identical conditions were created for all VPS: I installed all the software myself. WEB servers run on bare Apache (NGINX and other amenities were not installed), all configs by default. All VPS was installed Joomla 3.1.5 with demo data blog. Apache Benchmark version 2.3 was used as software for the test itself.
For each VPS, testing was carried out in 3 stages:
- The first stage - 30 threads and 500 requests.
- The second stage - 50 threads and 1,000 requests.
- The third stage - 100 threads and 10,000 requests.
The number of streams can be equated to the site visitors, and the number of requests for requests from these visitors to the VPS WEB server.
For example, the first stage can be represented as 30 users on the site at the same time and in total made 500 requests to the WEB server.
Each stage was run 3 times and the average values ​​from the test results were used as the result.
The table took into account the main, in my opinion, parameters:
- Failed requests - the number of requests that the VPS could not process.
- Requests per second - everything is clear from the name; the more requests per second are processed by the WEB server, the higher its speed.
- The execution time of 1 request (... across all concurrent requests) - the smaller this value is, the faster the WEB server processes requests and the higher the overall speed.
- Time to complete all requests (Time per request) - total time to process all requests sent to the WEB server. The lower the value, the better.
- Connection Time - consists of
a. Connect string: - the time that the utility spent on connecting to the server.
b. Processing line: - the request execution time.
c. Line Waiting: - request idle time. That is, the time that the request waited for its turn to complete.
d. Total string - Total time.
As a result, I present the totals of the Total line. The first value is the minimum, the second is the maximum. The parameter shows how long the slowest and fastest request was executed. The smaller these figures, the server processes requests faster. - The total time per test (Time taken for tests) is often the same as the total processing time for all requests. The lower the value, the better.
The test does not give an assessment of such characteristics as the disk subsystem, the volume of the external channel, the cost and the quality of the additional services.
Testing:
First round: 30 stream and 500 requests.
And in the very first test VPS from 1gb.ru could not process even 100 requests. It’s hard to say what it’s about, I didn’t have a goal to understand the reasons for such a fatal speech of this candidate, so we’re going further.
The following challenger from Timeweb proved to be much better and coped with the task with little effort, having processed all the requests sent to its WEB server:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 6.2 | 161.3 ms | 4758 ms | 1616 - 8988 ms. | 79.6 seconds |
Next, the VPS from Agava “attacked”, which also successfully coped with its task:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 10.1 | 99.1 ms | 2981 ms | 827 - 5373 ms. | 49.5 seconds |
The next challenger is the infobox:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 3.4 | 291.7 ms | 8750 ms | 1524 - 10142 ms. | 145.8 seconds |
Following in fact showed himself hosting from It-mcp:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 2.3 | 436.4 ms | 13091 ms | 2662 - 15462 ms. | 218 sec. |
The penultimate candidate is Fozzy:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 5.3 | 189.5 ms | 5685 ms | 1304 - 7210 ms. | 94.7s |
And completes the first stage of testing VDS24.net:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 10.4 | 96.5 ms | 2895 ms | 919 - 4941 ms. | 48.3 seconds |
Let's summarize the first intermediate result:
All VPS, except 1gb, coped with the task, so 1gb is eliminated from further tests. The leader in speed, after the first stage, is the VDS24, in second place is the VPS from Agava. Go to round 2.
Second round: 50 streams and 1000 requests.
Timeweb:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
449 | 4.6 | 218.4 ms | 10919.5 ms | 538 - 38114 ms. | 218.4 seconds |
In the second round, Timeweb could not cope with the task and was able to process only a little more than half of the requests.
Agava:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 7.6 | 131.5 ms | 6574.7 ms | 635 - 9781 ms. | 131.5 seconds |
Infobox:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 3.4 | 291.3 ms | 14563.8 ms | 2018 - 16325 ms. | 291.3 seconds |
It-mcp:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 2.3 | 436.6 ms | 21827.7 ms. | 2548 - 24240 ms. | 436.6 seconds |
Fozzy:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 5.5 | 182.7 ms | 9133.7 ms | 1620 - 11103 ms. | 182.7 seconds |
VDS24:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 9.6 | 104 ms. | 5202.3 ms. | 987 - 10296 ms. | 104 seconds |
According to the results of the second stage of testing, the VDS24 still leads with a small margin, Agava breathes in its back. At the tail end of the list is It-mcp.
Third round: 100 threads and 10,000 requests.
Timeweb:
In the third round, Timeweb for all 3 attempts tightly fell MySQL and Apache gave a sad message: Error displaying the error page: Application Instantiation Error. The test site came to life only after MySQL restart. In the third stage, Timeweb VPS from the ranks of the lagging behind, along with 1gb.
Agava:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 7.6 | 125.8 ms | 12576 ms | 606 - 15627 ms. | 1257.6 seconds |
Infobox:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 3.4 | 292.2 ms | 29216.5 ms | 1576 - 35362 ms. | 2921.6 seconds |
It-mcp:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 2.3 | 4396.1 ms | 43961.3 ms | 2683 - 81978 ms. | 4396.1 seconds |
Fozzy:
Failed requests | Number of requests per second | Lead time 1 request | Execution time of all requests | Connection time | Total time |
---|
0 | 5.2 | 1910.3 ms | 19103.4 ms | 1488 - 23609 ms. | 1910.3 sec |
VDS24:
We approached our leader of the first two stages. And here we are disappointed. VDS24 at all three attempts tightly hung, managing to process only slightly more than 2000 requests.
This completes the third testing phase.
Results:
The winner of our testing, which demonstrated quite good performance and fault tolerance, was announced by Agava VPS.
The outsider of our test, of course, was VPS from 1gb, which was able to cope with only 10 threads and 50 requests.
The final table looks like this:
- Agava
- Despite the failure in the last test, I give second place to VDS24
- Fozzy
- Infobox
- It-mcp
- Timeweb
- 1gb
For the experiment, an attempt was made to test the possibilities of the VPS that had not yet dropped out of the race. They were sent to the load 300 threads and 50,000 requests. I will say right away that no one has managed to cope with such a load.
Of course, we were able to test far from all the VPS that are on the market, as well as the speed and resiliency can be significantly improved by properly configuring the VPS, but the potential was well traced in this test. As it turned out, not always performance rests on megahertz and the amount of RAM.
You can view the summary table of test results
here .