Bug 59656

Summary: PATCH: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Product: Apache httpd-2 Reporter: Ivan Zahariev (famzah) <famzah>
Component: mod_fcgidAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal CC: famzah
Priority: P2 Keywords: PatchAvailable
Version: 2.4.20   
Target Milestone: ---   
Hardware: PC   
OS: All   
URL: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait

Description Ivan Zahariev (famzah) 2016-06-02 08:53:35 UTC
Hi all,

I'd like to propose a new configuration setting for "mod_fcgid". The source code changes to review follow:
- The whole patch compared to version 2.3.9: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait
- The whole patch as a single file: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified&name=maxnowait
- Every single commit compared to version 2.3.9: https://github.com/famzah/mod_fcgid/commits/maxnowait
- There should be no merge conflicts with the current "trunk" version 2.3.10.

The motivation is that the current behavior to queue up new pending requests differs from the RLimitNPROC directive behavior. When there is a spike in the web hits, lots of Apache children get busy just waiting for up to 30+ seconds to get an idle FastCGI process. Thus we "waste" Apache children doing nothing while they could serve static content. This also puts unneeded memory pressure. Additionally, users today won't wait for a page to load, if it takes more than a few seconds, and we'd rather notify them that we are currently overloaded by sending them a 503 HTTP response immediately.

Here is the documentation for the new directive: http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt

Let me know what you think.

Best regards.
--Ivan
Comment 1 Ivan Zahariev (famzah) 2016-09-19 08:31:01 UTC
It's been four months since I originally proposed this new feature in "mod_fcgid". During this time I've tested and deployed it on hundreds of busy production servers. It works as expected. If enabled, web visitors get an immediate response when FastCGI is overloaded, and no RAM is over-utilized.