httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml
Date Mon, 24 Jul 2017 20:03:14 GMT
On Mon, Jul 24, 2017 at 9:46 PM, Jacob Champion <> wrote:
> On 07/24/2017 12:39 PM, Yann Ylavic wrote:
>> Hmm, don't we close the backend connection (i.e. conn->close = 1) whenever
>> an error occurs in the fgci loop? What do you mean by
>> "queue up for later", by whom? Where do that coonection go on the
>> httpd side?
> I mean that the FCGI application (PHP-FPM) has a listen queue for
> connections. I haven't looked into the source to see how this queue is
> implemented.

What if the fpm queue in ap_proxy_connect_backend or at POLLOUT time?
If both cases I think the socket is not reused by mod_proxy_fcgi for
the next request, so I don't see how it's a enablereuse issue...

> FPM has a status page that can be set up to debug these sorts of things,
> which I might try to enable later this week for more research.

Thanks, hopefully we'll see more clearly what happens for such
connections on the httpd side.

> I think
> the "correct" way to go is to query the app for the max connection
> number, use that if the admin hasn't set up another max, and warn if the
> admin has forced us to use a max that's more than what the app can
> handle concurrently.

Sure the warning is nice to have, but having max < ThreadsPerChild is
really not ideal, so the true fix is sizing fpm's max connection to
httpd's max workers (rather than waiting for available connections on
the reverse proxy side).

In any case we should behave correctly (i.e. according to the
configured timeouts) when the backend queues connections.


View raw message