| Summary: | Connections are starved and not balanced when concurrent requests exceed FcgidMaxProcessesPerClass | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Scott <scottpakula> |
| Component: | mod_fcgid | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | stefan |
| Priority: | P2 | ||
| Version: | 2.4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
To produce the buffer.exe application, I'm compiling using libfcgi located here: http://www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz Here's an example of what buffer.exe would look like. #include "fcgi_stdio.h" #include <stdlib.h> void main(void) { FCGI_init(); /* Response loop. */ while (FCGI_Accept() >= 0) { char *buf = NULL; unsigned int bufsz = 1024*1024; printf("Content-type: text/html\r\n\r\n" buf = malloc(bufsz); FCGI_fwrite(buf, bufsz, 1, stdout); free(buf); } } In addition, I am running Apache on the Windows platform. The build is Windows 32-bit compiled under Visual Studio 2010. Apache 2.4.6. |
When a large number of concurrent requests are made to a FastCGI process which exceeds the number defined in FcgidMaxProcessesPerClass, connections become starved. From reviewing the source code, In fcgid_spawn_ctl.c when this condition happens, the following piece of code is executed. /* * Process count of this class higher than up limit? */ if (current_node->process_counter >= current_node->max_class_process_count) { ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, main_server, "mod_fcgid: too many %s processes (current:%d, max:%d), skip the spawn request", command->cgipath, current_node->process_counter, current_node->max_class_process_count); return 0; } For example, if I have a FastCGI application which returns a 1MB buffer called buffer.exe. I have configured FcgidMaxProcessesPerClass to 4, and now I launch 64 concurrent requests to buffer.exe which are looping. The result is that some threads obtain the the buffer while others are simply staved. The expected result is that I would want these 64 concurrent requests to equally be slow at obtaining the result rather then a few connections getting the result while others are staved.