httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "pqf" <...@mailtech.cn>
Subject Re: mod_fcgid concurrency bottleneck, issue#53693
Date Wed, 15 Aug 2012 06:59:52 GMT
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. 
Mime
View raw message