Luke Rissacher

Thanks! So yes, setting `WSGIScriptAlias ... application-group=%{GLOBAL}` (and reverting `WSGIDestroyInterpreter` to its default) fixes the 5-second app restart delay, nearly instant now when my `application.py` files are touched. The full-httpd...

Feel free close this issue if you like BTW - for my purposes, adding `WSGIScriptAlias ... application-group=%{GLOBAL}` to all our apps solved the individual app-restart delay, as did adding `WSGIDestroyInterpreter...

Sure, no hurry - here's the basic MPM / WSGI configuration: ``` # Using mpm_worker # Top-level settings: StartServers 1 ServerLimit 1 ThreadLimit 256 ThreadsPerChild 256 MaxRequestWorkers 256 ThreadStackSize 1048576...

Just added `WSGIRestrictEmbedded On` to the config. No harm to applications (it's daemon procs only that run python) but the 60 second restart was still there on the 2nd restart.

Just updated to `ServerLimit 2`; on first restart switching to that new config (while `ServerLimit 1` was still in place), it actually completed in ~5 sec. Occasionally the delay doesn't...

Forgot to answer your KeepAliveTimeout question - those settings are on the defaults (keepalives on, 5 sec timeouts).

Interesting, yes 2nd restart might have been within 60 sec - no prob for me to wait > 60 sec between restart tests. I'll do some more tracing tonight on...

Thanks - normal requests are in the 5-30ms range. Occasionally one can block for 2-3 seconds waiting on external systems - API calls, long database queries, etc. But generally rare....

Interesting article, cool that mod_wsgi supports `` based daemon proc targeting. Might use some of those techniques down the line. I've found `inactivity-timeout` very handy for seldom-used sites/apps like admin...

Cool! Just took a tour through the `mod_wsgi` python module. Some really useful stuff in there. Especially `process_metrics()`, plus seeing the actual runtime values of `process_group`, `application_group`, utilized threads, etc....