
A couple of days ago, a man asked me with a rather routine request: to tweak the VPS settings to speed it up - lately there was a sharp increase in attendance on the site, and the server began to bend at peak times.
It would be an ordinary and dismal article about nginx and opcode-caching if the server had not been "optimized" by the technical support of the hoster before :-)
About what I discovered in the process of optimization, I am writing this small note in order to protect others from similar tricks of hosters. :-)
')
Since a quick solution was required (for 1 hour of work), I went along the standard path: nginx / PHP / expires accelerator for static / disabling access logs. nginx was already, and the rest was done by the 3rd number. Out of the corner of his eye he noted that PHP is working in CGI mode, and not mod_php (I didn’t touch it right away - you always have to figure out if something was tied to the user from which PHP was working). Of course, there was an improvement in performance (see the graph on the right), but very far from what I expected (only 50% of the CPU is available on the graph, so where the graph is 50%, everything becomes very bad). In addition, when I woke up in the morning, I saw a letter stating that some of the pages had stopped working (and as luck would have it, the pages that I watched after changing the settings worked).

Went to look more in detail the second time, starting with CGI. I have never seen anything like this, mod_php is everywhere for a long time and by default, and in all respects faster than CGI (I don’t say anything about FCGI here). And as we know, when working in the CGI mode, the opcode cache APC is not fumbled between PHP processes, and accordingly no performance gain comes out of it.
Non-working pages turned out to be due to the conflict between APC and Zend Optimizer (I didn’t expect to see it here) - it shouldn’t work at all, but some of the pages miraculously worked.
Having talked with the customer, I find out that this is how the server has configured technical support for the optimization request. Let's take a closer look at what they set up for them:
What has been configured hoster compared with the default configuration:
1) nginx: 8 processes, 65k connections (despite the fact that the server is dying already from 100, and nginx is preparing to process 650'000). expires statics is not configured (not to mention the return of statics directly without Apache2). Access logs are written in both Apache and nginx.
2) PHP in CGI mode. This eliminates the use of popular PHP accelerators. Zend Optimizer practically does not help. The slowest mode of PHP, worse is hard to come up with something.
3) Apache for nginx is zealously trying to run up to 150 processes of itself and up to 150 PHP processes. Obviously, the memory is very vigorously surviving. Hoster recommends switching to a thicker tariff, and the customer actually transfers, however, a thicker tariff is not enough for a long time.
4) MySQL with a config for 50MB of used memory (with available gigabytes).
What was configured by me / had to be configured from the very beginning:
1) nginx, 1 process (the ordinary server and 10,000 connections are “not in a standing” state, the rest is extra memory consumption). Return expires headers for statics.
2) PHP in the default mode, mod_php. Any PHP opcode cache (for example, APC).
3) apache2 is limited to 8-16 processes = fixed memory consumption.
4) MySQL - config for half the available memory.
The result is visible on the 4th. The load is dramatically reduced, the memory consumption is now stable, and allows you to switch to the tariff twice cheaper (however, they did not do this, because attendance is growing rapidly).
Summary
In this case, there was either a low administrator qualification (which I sincerely want to believe) performing the server optimization ticker, or
direct sabotage (that's what it is called) in order to hook the client on the fatter tariff, and in the future - on a dedicated server. Host name leave a secret, so that no one thought that this can not happen to him. Only mentally send a ray of diarrhea.

(of course I informed the management of the company about the problem)
Obviously, there is a clear conflict of interest: it is NOT profitable for a hoster to have your site run quickly after optimization, and consume little memory - after all, then it will lose a lot of money in the coming long years.
So make sure that the hoster is setting you up there and keep an eye on the munin charts.
