How to speed up Apache: serving static files and executing PHP?

Question

PHP

Will switching to FastCGI with mod_php help?
And here's the question.
There is a site that used to be hosted, we are switching to VPS and the task is to make it at least not slower than it was.
On VPS, even more powerful hardware is Intel Xeon 3.4 GHz, versus 2.2 on hosting.
Cores - there are 4 and the load limit is 25%, here 3 and there is no limit, these are our cores)
Disk - SSD.
OS is Ubuntu.
PHP - there is 7.0.7 and we seem to have it too.
But alas, it works much slower, it takes a lot of time from the beginning of the response to its end, on all requests, including the main GET html.
And it would be fine only pages, but even a simple text / plain file on the hosting is given 3 times faster, although this is the first request, and not Not Modified.
Or rather, hosting is unstable, sometimes faster, sometimes slower, but it's better than the stable slowness of VPS.
I studied the entire httpd.conf, dug up a bunch of guides on highload (they are old and with dubious advice like "disable unnecessary modules", although on the hosting, judging by the list of modules in the admin, they obviously did not do this, as well as advice on a bunch of parameters in httpd.conf, which I twirled this way and that), tried pagespeed.
Nothing helped, pagespeed actually didn't help much even for pages (well, it shouldn't help for txt), although the page looks cooler in Code View.
Well, well, the success of hosting with statics is explained by CDN or some other cache.
You can also drag the Internet channel here.
But here's another experiment: we insert a more time-consuming PHP code into the file (without adding a single byte to the response weight) - and the hosting immediately goes into the gap by 10 times.
Obviously, the problem is not in the absence of a CDN and not in the Internet channel, memcached is not here will help, the problem is in the speed of the Apache + PHP bundle.
Questions:
1) Is the so-called "powerful" processor slower for all VPSs than for some miserable hosting, albeit with a VIP tariff?
2) Will FastCGI help in this situation?
3) Why are chips like eAccelerator (AST caching, etc.) not popular?
I know that many of them are abandoned, but this is not a cause, but a consequence.
4) What else can help?

Answer 1

Studied the whole httpd.conf, dug up a bunch of guides on highload (they are old and with dubious advice like "disable unnecessary modules"

One of the first modules that should be disabled in Apache, for speed, is support for .htaccess files, this performance support itself does not add, and the presence of these files is even more so.

1) Is the so-called "powerful" processor slower for all VPSs than on some miserable hosting, albeit with a VIP tariff?

No, maybe you, personally, have some kind of crappy VPS hoster, or even worse, a tariff like "OpenVZ, we don't resell the sold resources... well, maybe 10 times, but we don't resell anymore"

2) Will FastCGI help in this situation?

FastCGI is a PHP mode of operation, it does not directly affect performance to a large extent, moreover, the FCGI operation logic itself (if we compare Apache-FCGI and Apache-mod_php) will be slower, because a socket will be used for FastCGI interaction (" normal" or unix socket), which implies network communication, instead of the direct operation of the PHP interpreter "inside" the server. I think a little something else will help you (I will try to describe below).

3) Why are chips like eAccelerator (AST caching, etc.) not popular?

I have no idea why they are not popular and where you get such statistics from ... But perhaps the fact is that eAccelerator is morally and physically outdated, and if you believe, for example, such a banal article (no, I do not work with such a " masterpiece" CMS like "Bitrix", it's just the first mention of eAccelerator that came to my mind) - it does not work with PHP versions higher than 5.3.

I know that many of them are abandoned, but this is not a cause, but a consequence.

I cannot comment on this, since you did not indicate the consequence - what exactly. In other words, I don't quite understand what you mean by that.

4) What else can help?

Well, right off the bat, from memory (options may not be related to each other):
1. Refusal to support .htaccess in Apache or at least reduce their number
2. Installing Nginx as a front-end server to return statics
3. Complete rejection of Apache in general, and the transition to Nginx + FCGI (just don’t think, I really love Apache for its configuration flexibility and wide possibilities, another question is that few people actually need this flexibility and few people are able to correctly, efficiently and fully configure it ... Nginx in this regard, it will be much simpler). Why FCGI? Because I don't know any other acceptable way to interact with Nginx with PHP. Setting up an FCGI pool is required.
4.OpCache _- since version 5.5 "sparks" are built in, to enable and configure - it is highly recommended. I do not know how things are with CMS and whether you use CMS on the site, but from my experience, the speed of PHP frameworks increases on average 8-20 times.
5. HHVM as an alternative
6. Checking:
a) That it's really about PHP. In particular, it is worth collecting all the server logs, for example, how long the requests lasted, in the database, their number, and so on.
b) Checking the speed of the disk subsystem ... I will not "poke a finger", but at one time I rented a fairly large number of VPS's from one popular hosting provider, and at some point, I noticed that the average speed of the disk subsystem subsystems - 1.4Kb / sec., while "failures" (like "it is impossible to write a block") were about 50% of cases ... it did not last very long, but after a few months, the same hoster had tariffs with " ordinary HDD", for some reason they had a faster disk subsystem than tariffs with "fast SSD" ... we can draw conclusions ...
c) Check the real speed of the processor, it often differs from the declared one quite strongly.
PS If you formulate the question (s) more precisely, I can give more precise recommendations,
PPS There is a solution to the problem in general "on the forehead", the most probably complex and perhaps the most productive in some cases. This is Varnish+ fine-tuning it, allows you to issue most of the pages from the cache (RAM) in nanoseconds, sometimes it allows you to serve a lot of thousands of requests per minute, while this is not just code caching or something like that ... this is caching entire pages and /or server responses. Among other things - allows you to "not touch the backend at all", i.e. when requesting a page, there may be no database access, no execution of the same PHP (or any other) code on the server side. Requires rather fine tuning, not very suitable for sites "on CMS", for sites on frameworks - it requires an initially correct approach to development and thinking over what and how will / should be cached. With an incorrect approach - the most likely result - it will work, but not as fast as we would like, and part of the site may cease to function normally. There are also other solutions, but given the rather general wording of the question, it is rather difficult to talk about them.
Oh yes, I forgot an important detail... Why do "hosts" use Apache and won't abandon it (completely)? To a greater extent, because Apache allows you to delegate part of the settings to the user through .htaccess. At the same time, for statics, the same Nginx is often worth it, which, as you understand, does not allow the user to delegate part of the settings in this way, which means that it is not suitable for these tasks and does not “slip” on this (unlike Apache ). Incl. and for this, we have 99% abandoned "hosting" (due to the presence of Apache, and the inability to get rid of it or configure it ourselves, and as a result of the "brakes" that come along with this approach).

Answer 2

nginx for serving statics, and as a frontend before apache. You can also completely abandon Apache in favor of nginx + php-fpm.
If you need a CDN, try Cloudflare, at least for some of the resources.

Answer 3

https://blackfire.io/

Answer 4

on a cheap VPS I have a slaughtered one core per 1000 gigahertz, on hosting I have 8 cores at 3.9 gigahertz, as they say the difference is in the face
there is no php mod the fastest option for php
they are super popular but in new versions of php there is already a built-in zend op cache their replacement and they just died
nginx ?

Answer 5

You made the typical mistake of buying a xeon and you think that it will work just as fast depending on its cost.
And so you need
a skylike with a maximum frequency, dada - your "uh iron" will overtake the usual core i3, not to mention the normal i7
Renting it will be cheaper, buying it too, and the performance will be much better.
And the reason here is in the clock frequency, the Apache poorly parallels the processes, and even paralleling them, it still performs a hit on 1 process. As a result, the speed of your xeonao in 2Ghz is your peak speed and 30 cores do not solve anything here, an ordinary office computer will do it.
All you get from this hardware is a large number of parallel requests, at the same speed.
But as you understand, what you need is not 10-50 thousand people a day, it’s quite enough for yourself to pull 1 percent of I7
, in fact, without consulting, you bought or rented complete rubbish that is not suitable for web applications. Particularly for websites.
yes, you can host on this hardware, and some things will also work better on it, but the average hit will fall into a hard toilet.
Recommend.
Remove didikate, so it's not so difficult.
hetzner options
- germany excellent rates, we take only ssd and only skylike pints 50
https://chipcore.com/ - peter, ping 5-10 any of the rates will be more cheerful.