You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2001/12/22 06:28:40 UTC
[PATCH] Eliminate HARD_THREAD_LIMIT on Windows
So I says to myself, "self, why introduce the ThreadLimit directive when the scoreboard on
Windows is not shared between processes, ever?". So here is a patch: the scoreboard is
always allocated to be exactly big enough for ThreadsPerChild entries. And it can grow or
shrink across restarts because the scoreboard is never shared across processes. Why didn't
I think o this sooner? It's late so posting a patch rather than committing code...
Bill
Index: mpm_winnt.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v
retrieving revision 1.202
diff -u -r1.202 mpm_winnt.c
--- mpm_winnt.c 2001/12/18 13:48:53 1.202
+++ mpm_winnt.c 2001/12/22 05:21:53
@@ -75,27 +75,9 @@
#include "mpm_common.h"
#include <malloc.h>
-/* Limit on the threads per process. Clients will be locked out if more than
- * this * HARD_SERVER_LIMIT are needed.
- *
- * We keep this for one reason it keeps the size of the scoreboard file small
- * enough that we can read the whole thing without worrying too much about
- * the overhead.
- */
-#ifndef HARD_THREAD_LIMIT
-#define HARD_THREAD_LIMIT 4096
-#endif
-
-/* Limit on the total --- clients will be locked out if more servers than
- * this are needed. It is intended solely to keep the server from crashing
- * when things get out of hand.
- *
- * We keep a hard maximum number of servers, for two reasons --- first off,
- * in case something goes seriously wrong, we want to stop the fork bomb
- * short of actually crashing the machine we're running on by filling some
- * kernel table. Secondly, it keeps the size of the scoreboard file small
- * enough that we can read the whole thing without worrying too much about
- * the overhead.
+
+/*
+ * Maximum number of processes access the scoreboard at once
*/
#define HARD_SERVER_LIMIT 1
@@ -1592,7 +1574,7 @@
*result = HARD_SERVER_LIMIT;
return APR_SUCCESS;
case AP_MPMQ_HARD_LIMIT_THREADS:
- *result = HARD_THREAD_LIMIT;
+ *result = ap_threads_per_child;
return APR_SUCCESS;
case AP_MPMQ_MAX_THREADS:
*result = ap_threads_per_child;
@@ -2016,7 +1998,10 @@
ap_log_error(APLOG_MARK, APLOG_INFO, APR_SUCCESS, ap_server_conf,
"Child %d: Child process is running", my_pid);
- /* Set up the scoreboard. */
+ /* Set up the scoreboard. The size is based on the setting of
+ * ap_threads_per_child. Since the scoreboard is not shared
+ * between processes, it can be resized across restarts.
+ */
ap_run_pre_mpm(pconf, SB_NOT_SHARED);
/* Humm... Should we put the parent pid here? Does it matter
* since the scoreboard is not shared?
@@ -2090,20 +2075,8 @@
if (err != NULL) {
return err;
}
-
ap_threads_per_child = atoi(arg);
- if (ap_threads_per_child > HARD_THREAD_LIMIT) {
- ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
- "WARNING: ThreadsPerChild of %d exceeds compile time"
- " limit of %d threads,", ap_threads_per_child,
- HARD_THREAD_LIMIT);
- ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
- " lowering ThreadsPerChild to %d. To increase, please"
- " see the HARD_THREAD_LIMIT define in %s.",
- HARD_THREAD_LIMIT, AP_MPM_HARD_LIMITS_FILE);
- ap_threads_per_child = HARD_THREAD_LIMIT;
- }
- else if (ap_threads_per_child < 1) {
+ if (ap_threads_per_child < 1) {
ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
"WARNING: Require ThreadsPerChild > 0, setting to 1");
ap_threads_per_child = 1;
Re: [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Saturday, December 22, 2001 2:51 PM
> We would be best served by having an event driven/async MPM for scalability rather than
> pursuing the thread-per-connection model.
Agreed ... however; that doesn't diminish the benefit of multiple processes.
> Getting two (or more) Windows processes accepting connections off the same listening
> socket is certainly possible, but the cross process mutex that will be required to
> serialize the accepts will likely be a performance killer. What works well on Unix
> probably will not be optimal on Windows. I could probably work something up in an hour or
> so.
That sort of presumes that we might encounter the thundering hurd issue
on Windows. I suspect, based on other, earlier experiments that this
won't be a problem. Especially with the AcceptEx semantic. The scoreboard
itself doesn't need any mutexing, so that leaves this pretty vanilla.
If you want to pursue some other optimizations, that would be very cool.
I won't start pounding on this in the next few days, so anything you are
experimenting with won't get in my way.
I suspect there is a magic number in the threshold of how many listeners
and workers that a given worker-dispatch thread can optimially service.
Leaving the process entity around [multiple processes, that is] should help
us significantly.
Re: [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Posted by Bill Stoddard <bi...@wstoddard.com>.
> From: "Jeff Trawick" <tr...@attglobal.net>
> Sent: Saturday, December 22, 2001 6:57 AM
>
>
> > "Bill Stoddard" <bi...@wstoddard.com> writes:
> >
> > > So I says to myself, "self, why introduce the ThreadLimit directive when the
scoreboard on
> > > Windows is not shared between processes, ever?". So here is a patch: the scoreboard
is
> > > always allocated to be exactly big enough for ThreadsPerChild entries. And it can
grow or
> > > shrink across restarts because the scoreboard is never shared across processes. Why
didn't
> > > I think o this sooner? It's late so posting a patch rather than committing code...
> >
> > it makes sense to me, but what do I know about the NT MPM? (answer:
> > almost nothing)... but it either works or it doesn't, so commit it
> > already if it does
>
> No... thanks for taking the time to post the patch, Bill! Since it would
> interfere with moving the WinNT port twords a more scaleable solution, I'm
> glad to have a chance to comment, instead of asking for the code to be
> reverted.
>
> On your other [earlier] always-single-process patch, it's just as well
> that we simplified the MPM first, so that making the code more APR-based
> [first!] became a more trivial task :)
Your welcome ! A thought or two worthy of consideration...
We would be best served by having an event driven/async MPM for scalability rather than
pursuing the thread-per-connection model.
Getting two (or more) Windows processes accepting connections off the same listening
socket is certainly possible, but the cross process mutex that will be required to
serialize the accepts will likely be a performance killer. What works well on Unix
probably will not be optimal on Windows. I could probably work something up in an hour or
so.
Bill
>
> Bill
>
Re: [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jeff Trawick" <tr...@attglobal.net>
Sent: Saturday, December 22, 2001 6:57 AM
> "Bill Stoddard" <bi...@wstoddard.com> writes:
>
> > So I says to myself, "self, why introduce the ThreadLimit directive when the scoreboard on
> > Windows is not shared between processes, ever?". So here is a patch: the scoreboard is
> > always allocated to be exactly big enough for ThreadsPerChild entries. And it can grow or
> > shrink across restarts because the scoreboard is never shared across processes. Why didn't
> > I think o this sooner? It's late so posting a patch rather than committing code...
>
> it makes sense to me, but what do I know about the NT MPM? (answer:
> almost nothing)... but it either works or it doesn't, so commit it
> already if it does
No... thanks for taking the time to post the patch, Bill! Since it would
interfere with moving the WinNT port twords a more scaleable solution, I'm
glad to have a chance to comment, instead of asking for the code to be
reverted.
On your other [earlier] always-single-process patch, it's just as well
that we simplified the MPM first, so that making the code more APR-based
[first!] became a more trivial task :)
Bill
Re: [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Posted by Jeff Trawick <tr...@attglobal.net>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> So I says to myself, "self, why introduce the ThreadLimit directive when the scoreboard on
> Windows is not shared between processes, ever?". So here is a patch: the scoreboard is
> always allocated to be exactly big enough for ThreadsPerChild entries. And it can grow or
> shrink across restarts because the scoreboard is never shared across processes. Why didn't
> I think o this sooner? It's late so posting a patch rather than committing code...
it makes sense to me, but what do I know about the NT MPM? (answer:
almost nothing)... but it either works or it doesn't, so commit it
already if it does
(I'm glad somebody is running with the malloc-the-scoreboard code I
had to hack up recently.)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Friday, December 21, 2001 11:28 PM
> So I says to myself, "self, why introduce the ThreadLimit directive when the scoreboard on
> Windows is not shared between processes, ever?". So here is a patch: the scoreboard is
> always allocated to be exactly big enough for ThreadsPerChild entries. And it can grow or
> shrink across restarts because the scoreboard is never shared across processes. Why didn't
> I think o this sooner? It's late so posting a patch rather than committing code...
So I read your patch... and think; we need a shared scoreboard, if we are
ever going to introduce multiple processes on Windows.
The 'let a child gracefully die, but start up yet another right away' logic
really starts to prove we need more robust mpm on Win32.
So I'm very -1 on breaking the HARD_THREAD_LIMIT on win32, since it only
needs to be re-added later, once I introduce a shared scoreboard :(
Bill