On Mon, May 13, 2024 at 7:32 AM Stefan Eissing via dev <dev@httpd.apache.org> wrote: > > I have merged https://github.com/icing/mod_h2/pull/280 to the mod-h2 on > github. With mpm_event, this will return HTTP/2 connections more often to the > mpm, thus freeing a worker. > > While this sounds good, I am not sure this is beneficial for a server under > load. The current connection state handling is designed for HTTP/1.x where a > connection is "given back" to the MPM at the end of a request. > > AFAICT, the MPM assumes that, once any pending output is written, it may > close the connection under load. Because in HTTP/1.x it means the connection > has served the last response completely. The client should be grateful and > cope well with the connection being closed subsequently due to other clients > demands. > > In HTTP/2 so far, we did return to the MPM only when all requests had been > served. The connection is therefore really in a similar state to HTTP/1.x. > The client has got its responses, we are free to close. > > With the change in PR 280, we return on being flow blocked. The response(s) > are *not* finished. If MPM now closes such a connection under load, the > client will most likely try again. This seems counter productive. > > Therefore I am hesitant if this change is beneficial for us. It frees up a > worker thread - that is good - but. Do we need a new "connection state" here?
We have CONN_STATE_SUSPENDED too. These are all but forgotten by the MPM until something changes their state back. You may see some references to PT_USER that got backported in comments, but that is trunk-only. PT_USER is about how something gets help un-suspending. In the case of H2, I guess the non-worker thread knows/should know when it could resume a request already? ./modules/test/mod_dialup.c is a sample-ish program that uses SUSPENDED to not tie up a thread while it sleeps In trunk, modules/proxy/mod_proxy_wstunnel.c and mod_proxy_http use it to avoid an idle tunnel tieing up a thread.
