Selecting the operation of the web server on personal experience
This article will be useful to those people who already have a website, or who plan to open it. Particularly interesting is the article will be ambitiously tuned webmasters who feel that the high point of their project is not far off and want to prepare for the influx of visitors to the page.
Even those who are only dreaming of thousands of users on their site, probably wondered: “How many users will my site survive if they log in at the same time?” I immediately recall the famous expression “Habraeffect” - the phenomenon of a site’s failure that turned out to be not ready for numerous transitions to it after the appearance on the Internet links.
Suppose that the site is already there (or will be soon): where is it located? Should it be a classic hosting or vps server? If vps, which one and how best to configure it? Or maybe there is no difference at all and it is easier to choose what is cheaper? In this article, we will look at several options and, in practice, we will see which one is better for our site.
We will experiment: set different modes of server operation and measure performance. We will simulate the load on the site using the service Loaddy.com. There you can set the number of users, the growing type of load and the schedule will show how the server responds to them. It is considered that one user generates approximately one request to the site within 10 seconds. As a test site, we take a demonstration online store on cms moguta. It will be filled with test “goods”, which are displayed on the main page by several criteria (that is, when the page is being formed, work is underway with a database, etc.). One way or another, it will allow you to compare modes with each other.
As a test site, let's create a VPS server on Ubuntu OS. Its configuration will be [1 core, 1Gb RAM]. We assume that such entry-level servers are created in most cases for new projects. A test version of the online store will be available at ip address http://130.193.44.219/
Another classic hosting will be useful, to which we will also upload the same online store to conduct tests. You can go our own way and conduct the same tests on your project!
Since in most cases a control panel is offered along with vps, we will make major changes to the settings in it. On the vps server we have 3 modes of its operation:
But first we will carry out tests on the hosting:
The result is available by reference .
Errors occur when the number of visitors exceeds 50 people. Hosting ceases to give content, while if you go to the hosting control panel, we can see something like the following:
Next in line is our test airborne unit with the Apache mode, which by the way is suggested by default, when installing an ISP control panel.
The result is available by reference .
Problems begin when the number of users exceeds 90. If we log in to our server via ssh and look at this moment on the list of processes using the top command, sorted with Shift + M (by the amount of memory consumed), we will see something like this:
We we see that the apache2 process has grown into many children and they have eaten all the RAM of our vps server.
Here you need to make a small remark. The fact is that for the Apache server, theoretically, there is a mode that allows instead of this large number of child processes for each connection to create several so-called multi-thread ones, each of which would serve several connections. This mode is called worker , in contrast to the default prefork . But it is not easy to install it, in the ISP panels it is impossible to do this, and if you become puzzled and try to implement it via ssh, it turns out that it is not enough to turn off the prefork and enable the worker, you still need a safe version of php. And if modules like Zend or IonCube are used, they must also be thread-safe. Anyway, the official PHP site does not recommend installing this mode.
Let's see what happens when using the CGI mode. To do this, you need to allow using PHP in CGI mode in the ISP control panel; this is done in the section “Accounts - users - settings for the user”.
The result is available by reference .
Joyless picture turned out. The server refuses to issue content already with 55+ visitors, the entire memory is eaten by php processes. Next, there is an attempt to restore performance, but still everything ends almost 100% with failures.
It’s time for a mode in which the Apache server is not used at all, Nginx works instead, and php is processed by the php-fpm module. If you use the ISP control panel, then you need to enable this mode for the user. This is also done in the “Accounts - Users - Settings for User” section. Also, this mode should be available in the section "Settings - Features - Web server (www)".
The result is available by reference .
Exactly what is needed! 100% availability, while the download speed and server response time are at acceptable levels, although they increase with increasing load. Nevertheless, the server copes!
Let's look at the process table at the moment of maximum load on the server:
We see that we still have a stock of available RAM. And the child processes php-fpm7.0 do not grow in large quantities, but are limited to 5 instances, each of which serves several threads.
Well, it looks like a "winner mode" is defined. Let's find out how many simultaneous visitors can serve our server in this mode. But before we do a little "tuning". Firstly, since apache is not used for such server operation, it can be turned off altogether. We will do this in the ISP control panel in the “System - Services” section. Secondly, let's change a bit the principle of running php-fpm processes. By default it is dynamic. This means that child processes will hang in memory even when they are not needed. In this case, the memory is not released and over time, these processes can grow more than we would like. Therefore it is proposed to set the “ondemand” mode - on demand. And set the number of child processes and timeout for them.
To do this, you will need to log in to the server using ssh and register these settings in the php configuration file. This is convenient to do in the file for the user for which the domain was created in the ISP.
It is usually located in /etc/php/7.0/fpm/pool.d
So:
We see the default settings there:
To make the ondemand mode work, you need to replace this with:
And restart php-fpm with the command
After this, the php-fpm7.0 processes will be created on demand (with load), their maximum number will be = 5, and after 10 seconds of idle time, the process will be killed, freeing up RAM.
Just in case, we will run our test again to make sure that all this amateur activity did not affect the performance of the site for the worse:
The result is available by reference .
Now let's run Loaddy with a large number of visitors to see how many connections our server can handle:
The result is available by reference .
The good news is that all requests were processed, albeit with a long delay, with a large number of them per second. The server response time approaches 10 seconds with the number of calls of 190+. But let's recall the graph of the apache mode, where we received 4 seconds of the server’s response for 80+ users, whereas in the php-fpm mode, similar lags are observed for 130 requests that we specifically identified the cursor on the chart above.
But this is the same VPS.
The top process table at the end of the test (with 200 users):
Note that after the end of the test, the memory used by pfp-fpm was freed:
So our server is ready for new loads.
It must be remembered that the site works in the nginx + php-fpm mode, this means that apache2 is not used in the work and, as a result, .htaccess is not used. This may not seem convenient, but it is the fastest possible option, and search engines rank sites that are fast.
At the end another small point: If you configured everything on the server and decided to disable the ISP control panel, or you have run out of a license for it, please note that the “core” process of it will remain on your server. After months, it can grow, so it's better to “kill” it and remove crona from startup.
If you want to test the site yourself using Loaddy or other methods, it is available at http://130.193.44.219/
Even those who are only dreaming of thousands of users on their site, probably wondered: “How many users will my site survive if they log in at the same time?” I immediately recall the famous expression “Habraeffect” - the phenomenon of a site’s failure that turned out to be not ready for numerous transitions to it after the appearance on the Internet links.
Suppose that the site is already there (or will be soon): where is it located? Should it be a classic hosting or vps server? If vps, which one and how best to configure it? Or maybe there is no difference at all and it is easier to choose what is cheaper? In this article, we will look at several options and, in practice, we will see which one is better for our site.
We will experiment: set different modes of server operation and measure performance. We will simulate the load on the site using the service Loaddy.com. There you can set the number of users, the growing type of load and the schedule will show how the server responds to them. It is considered that one user generates approximately one request to the site within 10 seconds. As a test site, we take a demonstration online store on cms moguta. It will be filled with test “goods”, which are displayed on the main page by several criteria (that is, when the page is being formed, work is underway with a database, etc.). One way or another, it will allow you to compare modes with each other.
As a test site, let's create a VPS server on Ubuntu OS. Its configuration will be [1 core, 1Gb RAM]. We assume that such entry-level servers are created in most cases for new projects. A test version of the online store will be available at ip address http://130.193.44.219/
Another classic hosting will be useful, to which we will also upload the same online store to conduct tests. You can go our own way and conduct the same tests on your project!
Since in most cases a control panel is offered along with vps, we will make major changes to the settings in it. On the vps server we have 3 modes of its operation:
- Apache;
- Apache in CGI mode;
- Nginx + php-fpm (without Apache).
But first we will carry out tests on the hosting:
Classic inexpensive hosting
The result is available by reference .
Errors occur when the number of visitors exceeds 50 people. Hosting ceases to give content, while if you go to the hosting control panel, we can see something like the following:
Your site has been subject to restrictions in the last 24 hours. Processor resources limited for your site. You have reached the limits on the input processes (the number of simultaneously running PHP and CGI scripts, scheduled tasks and console sessions) 126 times.Well, of course, hosting is hosting, the more inexpensive. You can, of course, find such a tariff, which will provide more opportunities, but all this needs to be taken into account, in some way to know the exact data of the restrictions, and from each hosting provider.
VPS: Apache
Next in line is our test airborne unit with the Apache mode, which by the way is suggested by default, when installing an ISP control panel.
The result is available by reference .
Problems begin when the number of users exceeds 90. If we log in to our server via ssh and look at this moment on the list of processes using the top command, sorted with Shift + M (by the amount of memory consumed), we will see something like this:
We we see that the apache2 process has grown into many children and they have eaten all the RAM of our vps server.
Here you need to make a small remark. The fact is that for the Apache server, theoretically, there is a mode that allows instead of this large number of child processes for each connection to create several so-called multi-thread ones, each of which would serve several connections. This mode is called worker , in contrast to the default prefork . But it is not easy to install it, in the ISP panels it is impossible to do this, and if you become puzzled and try to implement it via ssh, it turns out that it is not enough to turn off the prefork and enable the worker, you still need a safe version of php. And if modules like Zend or IonCube are used, they must also be thread-safe. Anyway, the official PHP site does not recommend installing this mode.
VPS: CGI
Let's see what happens when using the CGI mode. To do this, you need to allow using PHP in CGI mode in the ISP control panel; this is done in the section “Accounts - users - settings for the user”.
The result is available by reference .
Joyless picture turned out. The server refuses to issue content already with 55+ visitors, the entire memory is eaten by php processes. Next, there is an attempt to restore performance, but still everything ends almost 100% with failures.
VPS: Nginx + PHP-FPM
It’s time for a mode in which the Apache server is not used at all, Nginx works instead, and php is processed by the php-fpm module. If you use the ISP control panel, then you need to enable this mode for the user. This is also done in the “Accounts - Users - Settings for User” section. Also, this mode should be available in the section "Settings - Features - Web server (www)".
The result is available by reference .
Exactly what is needed! 100% availability, while the download speed and server response time are at acceptable levels, although they increase with increasing load. Nevertheless, the server copes!
Let's look at the process table at the moment of maximum load on the server:
We see that we still have a stock of available RAM. And the child processes php-fpm7.0 do not grow in large quantities, but are limited to 5 instances, each of which serves several threads.
Well, it looks like a "winner mode" is defined. Let's find out how many simultaneous visitors can serve our server in this mode. But before we do a little "tuning". Firstly, since apache is not used for such server operation, it can be turned off altogether. We will do this in the ISP control panel in the “System - Services” section. Secondly, let's change a bit the principle of running php-fpm processes. By default it is dynamic. This means that child processes will hang in memory even when they are not needed. In this case, the memory is not released and over time, these processes can grow more than we would like. Therefore it is proposed to set the “ondemand” mode - on demand. And set the number of child processes and timeout for them.
To do this, you will need to log in to the server using ssh and register these settings in the php configuration file. This is convenient to do in the file for the user for which the domain was created in the ISP.
It is usually located in /etc/php/7.0/fpm/pool.d
So:
sudo nano /etc/php/7.0/fpm/pool.d/www-root.confWe see the default settings there:
[www-root]
pm = dynamic
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_children = 5
pm.max_spare_servers = 5To make the ondemand mode work, you need to replace this with:
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10sAnd restart php-fpm with the command
sudo service php7.0-fpm restartAfter this, the php-fpm7.0 processes will be created on demand (with load), their maximum number will be = 5, and after 10 seconds of idle time, the process will be killed, freeing up RAM.
Just in case, we will run our test again to make sure that all this amateur activity did not affect the performance of the site for the worse:
The result is available by reference .
Now let's run Loaddy with a large number of visitors to see how many connections our server can handle:
The result is available by reference .
The good news is that all requests were processed, albeit with a long delay, with a large number of them per second. The server response time approaches 10 seconds with the number of calls of 190+. But let's recall the graph of the apache mode, where we received 4 seconds of the server’s response for 80+ users, whereas in the php-fpm mode, similar lags are observed for 130 requests that we specifically identified the cursor on the chart above.
But this is the same VPS.
The top process table at the end of the test (with 200 users):
Note that after the end of the test, the memory used by pfp-fpm was freed:
So our server is ready for new loads.
It must be remembered that the site works in the nginx + php-fpm mode, this means that apache2 is not used in the work and, as a result, .htaccess is not used. This may not seem convenient, but it is the fastest possible option, and search engines rank sites that are fast.
Conclusion
At the end another small point: If you configured everything on the server and decided to disable the ISP control panel, or you have run out of a license for it, please note that the “core” process of it will remain on your server. After months, it can grow, so it's better to “kill” it and remove crona from startup.
If you want to test the site yourself using Loaddy or other methods, it is available at http://130.193.44.219/