mpm prefork outdated?

D

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,348
After reading the following discussion on Apache mailing list: https://lists.gt.net/apache/dev/470442 - it seems that soon to be released Apache 2.4.27 will have HTTP2 disabled as default if you are running mpm prefork. Please read the whole discussion, but here is two quotes from it:

Code: 
Well put. Confirming what Stefan wrote... the following appears in the error log 
at startup; 

[Thu Jul 06 12:18:58.005442 2017] [http2:warn] [pid 30121] AH10034: 
The mpm module (prefork.c) is not supported by mod_http2. The mpm 
determines how things are processed in your server. HTTP/2 has more 
demands in this regard and the currently selected mpm will just not 
do. This is an advisory warning. Your server will continue to work, 
but the HTTP/2 protocol will be inactive.
https://lists.gt.net/apache/dev/470523#470523

Code: 
I think the fallout is more nuanced than that. The mod_http2 
architecture currently cannot be mixed with prefork; it can lead to 
deadlock, and that's not okay for production systems in any way. 

Administrators using prefork who would like to switch to HTTP/2 in the 
future need to understand the limitations of the prefork architecture 
they have selected. And sure, our users can request that we implement a 
solution that "just works" with prefork, with the parent dispatcher that 
Stefan has mentioned, and we can weigh the cost/benefit of implementing 
it. [B]But IMO it's not that onerous to ask our users to upgrade to a 
modern MPM if they want a nice new protocol.[/B]

There are costs to making new things work with old machinery, and they 
affect you (the users) in real ways, even if you do not see them yourself.
https://lists.gt.net/apache/dev/470524#470524

I am running plain default Apache on my servers, and for PHP I am running mod_php with mod_ruid2. So after reading the disscussion above, what do the DirectAdmin users think is a "modern MPM" suited for shared hosting servers? As it seems mpm prefork is outdated and will not be usable for HTTP2.

Also maybe DirectAdmin support should be asked about this, because it currently seem to implement mpm prefork as default.
 
Most people use SuPHP, FastCGI or FPM, so they will be on Event MPM (if Apache 2.4) or Worker (if Apache 2.2). The mod_php is not a good option for shared hosting servers so you should consider changing it.
 
Last edited:
Thanks for the information. However I feel mod_php with mod_ruid2 is very good for shared hosting. So it is not possible to use mpm event when using mod_ruid2?

You mention suPHP, so I have to say that suPHP is not maintained anymore and is not getting any updates or not even security patches. So that is not a good option.
 
Last edited:
In mod_php + modruid2 Apache starts a new child PROCESS for every new user connection. That's done because it needs to run that with the user privileges (his user and group) instead of running it as "apache:apache" or "apache:none". This is accomplished that way - the main httpd process (which accepts the connection) runs as root and then it forks a child process by altering it's user and group.

If you read about the apache MPMs, that exactly what the prefork is - a new process is forked for every new connection. The Worker and the Event MPMs are using threads (they try to minimize process forking in order to save resources). Mod_ruid2 will not be possible with threads (you can't run a thread with different user/group).

Agreed on the SuPHP note - it's indeed not maintained (it's very simple anyway but that's a point). Still FastCGI and FPM are the best known methods. All three work flawless with the Event and Worker MPMs.

... And it's logical to be that way. Mod_php is an Apache module that compiles and executes the PHP script within the Apache process. That means that scripts are compiled inside the httpd process and not by an outside dedicated PHP compiller (like what FCGI, FPM and SUPHP do - they have the httpd accept the connection and then bring the php compiling work to and outside php program which itself can be run with the users user/group for security reasons).

Now what about HTTP2? I have no knowledge about the mentioned deadlocks and why/when they will occur. HTTP2 uses an Upgrade header - simplified speaking in order to be compatible with HTTP 1.1 it first accepts the connection as HTTP 1.1 one (simple text mode) and send back an Upgrade header - then the browser sends a second request via HTTP2 binary mode. ALPN (when using TLS) helps the clients to skip that upgrade part (the HTTP2 is negotiated during the TLS handshake) but still - that's how it's done over regular unencrypted TCP connection (h2c). First thing that comes to attention is that if upgrade header is used, that will fork two processes for the same thing with Prefork mode - and that's an overkill in performance. It does not answer on why it breaks the Prefork model though... Maybe reading more in the Apache lists will answer that.
 
Last edited:
Here is a brief info from the Apache docs regarding HTTP2 and Prefork:

HTTP/2 is supported in all multi-processing modules that come with httpd. However, if you use the prefork mpm, there will be severe restrictions.

In prefork mod_http2 will only process one request at at time per connection. But clients, such as browsers, will send many requests at the same time. If one of these takes long to process (or is a long polling one), the other requests will stall.

mod_http2 will not work around this limit by default. The reason is that prefork is today only chosen, if you run processing engines that re not prepared for multi-threading, e.g. will crash with more than one request.

If your setup can handle it, configuring event mpm is nowadays the best one (if supported on your platform).

If you are really stuck with prefork and want multiple requests, you can tweak the H2MinWorkers to make that possible. If it breaks, however, you own both parts.
Click to expand...
 
So it seems to be PHP FPM that is the alternative for shared hosting that want to run MPM Event instead of Prefork. However I am conserned about PHP FPM RAM usage.

I am perfectly happy with mod_php using mod_ruid2 except that I will need to run MPM event instead of prefork (because of HTTP2), and it seems by @wattie reply that MPM event might not work so nice together with mod_php/mod_ruid2.
 
SuPHP is memory friendly and very simple software. Unless a serious security flaw comes to the scene, it's one of the best options for servers with limited ram. I am so sad it's not maintained anymore :(
 
I think mod_ruid2 is a much better alternative then suphp.
 
It's faster in compiling PHP scripts, no doubt on that. But for plain static html files and other resources (like javascript, css, images) the Event mode is a huge advantage for Apache. Therefore if it is better or not can't be said that easy. It depends on what you run and how.

SuPHP is the slowest way to run PHP webserver. That's absolutely true.
 
I am considering to go from currently mod_ruid2 to fpm on all my servers. Is PHP FPM in Custombuild considered stable for production use, or is it still some bugs so watch out for? Also, are the default settings in Custombuild PHP FPM usable for most shared hosting server setups?
 
PHP-FPM is in the PHP core since 6 years (PHP 5.3.3). There is no reason to think it's unstable.

As for the second question... It will come with the defaults which will work but who knows if they are suitable for your server? Nobody can :)

Here is what can be "tweaked":

http://php.net/manual/en/install.fpm.configuration.php

Please share your upgrade experience. I am also considering to do that soon...
 
Last edited:
Thanks. However I was not talking about PHP FPM itself, but if DirectAdmin integration of PHP FPM was considered stable? As I understand it is very complex, so potential there could be more bugs with the integration then more simple ones like mod_ruid2 :)
 
It's a tricky question. It depends if everything works :)

From Apache viewpoint: php-frm is less complicated. With mod_php+mod_ruid2, it was an Apache task to take care of PHP compilation. With php-frm it's no longer Apache task - it's delegated via cgi to the PHP binaries.

From DA viewpoint: it does not matter a lot. It's all third party binaries. What DA do - it just sends commands like "restart", "reload", "stop" to them. It must work, that's all. Why should DA be depended if Apache or the PHP binaries compile the scripts? It's not a DA work at all.
 
You must log in or register to reply here.
Back
Top