On Mon, Jul 24, 2017 at 10:44 PM, Jacob Champion <champio...@gmail.com> wrote: > On 07/24/2017 01:03 PM, Yann Ylavic wrote: >> >> 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... > > > I'm not sure I understand your question, but I think I've described the > problem incompletely. Let me give it another try:
Thanks, I better see your point now. > > Let's say FPM has been configured to handle 5 concurrent connections, > and httpd has been configured to use up to 10. With connection reuse > disabled, if we hit the server with ten requests to FPM, five > connections will be served immediately, and FPM will queue up the next > five. As requests finish, httpd closes each connection, and FPM grabs > the next connection to service. Everything works. Right, until connections start to be queued on the httpd side too, we won't service more quicky than the backend anyway. > > With connection reuse enabled, FPM still queues the last five > connections. But because httpd never releases the first five, and new > incoming requests continue to use them, those queued connections never > get serviced. I agree that httpd could be better about this, but mainly in the documentation IMHO (sizing...), because like in the disablereuse case if there were no more new requests than the capacity of servicing the existing ones (within the configured timeout), everything would work here too (with less fairness, granted). > That's not FPM's fault; it advertises how many concurrent > connections it can handle via the FCGI protocol, and if it refused those > queued connections by default, our first use case (which works fine) > would crash and burn. OK, fpm behaves correctly (although it could maybe service more fairly new vs kept alive connections, or even the other way around). But httpd is not really at fault either, I think the issue is mainly "administrative". Regards, Yann.
