Hi Luca, On Sun, Feb 4, 2018 at 12:37 AM, Luca Toscano <[email protected]> wrote: > > After some tests and code reviewed I have a theory about what's happening, > let me know if it makes sense. PHP-FPM uses a "prefork-like" model, so one > worker process per connection, that is really important when thinking about > using enablereuse=on in mod_proxy_fcgi. As Yann mentioned, by default a > total of ThreadsPerChild connections for each httpd process can be opened > towards the FCGI backend. This was the case in my tests reported above: the > overall (persistent) connections created/attempted was way more than the > php-fpm processes. This can in my opinion explain very well the stall > mentioned by Hajo in his email, and possibly the one that I was observing > with gdb. Once all the PHP-FPM processes are busy with httpd persistent > connections then all the other attempts will be queued and served only > if/when a PHP-FPM process is freed (for example Timeut/ProxyTimeout > elapsed).
This looks a very plausible scenario IMO, and clearly what happens if "MaxClients"/max_children is reached on fpm side. > > I re-tested everything using the mod_proxy's 'max' parameter to limit the > number of connections in the proxy pool (of each httpd process) and > everything worked like a charm. I'm not sure playing with 'max' is the the right thing to do in this case, it makes few sense to configure max_children on fpm lower than httpd's MaxRequestWorkers, they probably should be the same in the first place. Limits should indeed be imposed by the proxy (according to upstream capacity), but 'max' is kind of waste of resources here on the proxy side, the right/same MaxRequestWorkers on httpd should be enough (with possibly reasonable/agressive MaxSpareThreads/Servers) provided it does not exceed fpm's max_children. > So as far as I can tell mod_proxy_fcgi's > connection reuse works for both TCP and Unix sockets as intended, but the > docs should be more explicit about gotchas and precautions to take in the > configuration. If this makes sense I'll take care of the docs updates :) Yes, it could be useful to document the need to tune the proxy according to the capacity of the backend (oversizing the proxy is useful only if its work is higher than the backend's), inconsistencies there can leed to stalls. Regards, Yann.
