Hi, all
I prefer the following solution, can anyone review it?
procmgr_post_spawn_cmd() will be blocked until process manager create a new
fcgid process, the worst case is someone else take the new created process
before I do, and I have to post another spawn command to PM again. The extreme
case is loop FCGID_APPLY_TRY_COUNT but get no process slot.
Index: fcgid_bridge.c
===================================================================
--- fcgid_bridge.c (revision 1373226)
+++ fcgid_bridge.c (working copy)
@@ -30,7 +30,7 @@
#include "fcgid_spawn_ctl.h"
#include "fcgid_protocol.h"
#include "fcgid_bucket.h"
-#define FCGID_APPLY_TRY_COUNT 2
+#define FCGID_APPLY_TRY_COUNT 4
#define FCGID_REQUEST_COUNT 32
#define FCGID_BRIGADE_CLEAN_STEP 32
@@ -447,19 +447,13 @@
if (bucket_ctx->procnode)
break;
- /* Avoid sleeping the very first time through if there are no
- busy processes; the problem is just that we haven't spawned
- anything yet, so waiting is pointless */
- if (i > 0 || j > 0 || count_busy_processes(r, &fcgi_request)) {
- apr_sleep(apr_time_from_sec(1));
-
- bucket_ctx->procnode = apply_free_procnode(r, &fcgi_request);
- if (bucket_ctx->procnode)
- break;
- }
-
/* Send a spawn request if I can't get a process slot */
procmgr_post_spawn_cmd(&fcgi_request, r);
+
+ /* Try again */
+ bucket_ctx->procnode = apply_free_procnode(r, &fcgi_request);
+ if (bucket_ctx->procnode)
+ break;
}
/* Connect to the fastcgi server */
2012-08-15
pqf
发件人：Mike M
发送时间：2012-08-15 04:29
主题：mod_fcgid concurrency bottleneck, issue#53693
收件人："dev"<dev@httpd.apache.org>
抄送：
Ahoy!
With mod_fcgid I've observed a performance bottleneck in which concurrent
requests to a virtualhost where the number of concurrent requests exceed
the number of available fcgid-spawned processes result in a significant
delay in responding to requests.
Details of this situation, how to reproduce, various scenarios tried, etc
are detailed in the issue submission [1].
In file modules/fcgid/fcgid_bridge.c, there is this section of code:
if (i > 0 || j > 0 || count_busy_processes(r, &fcgi_request)) {
apr_sleep(apr_time_from_sec(1));
If I change the sleep time from 1 second to 0 seconds (or, comment out
this section of code entirely), the bottleneck goes away. It seems like
the more appropriate action here would be to turn the sleep time into a
configurable value, with the current 1s value as the default.
I presume this code is meant to be a way to help defer spawn requests so
that a server is not over-whelmed with spin-up related I/O.
My questions are:
- Is this intended to be a throttling mechanism and if so, is there a more
efficient way to handle this throttling?
- If I outright reduce that sleep delay to 0 (or comment out this code),
what potential or expected problems am I introducing to mod_fcgid?
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53693
---
Mike M
You can't learn in school what the world is going to do next year.
