I ran some tests to compare the performance of the worker, leader/follower,
and threadpool MPMs under heavier traffic loads.
Server configuration:
Sun E4000, 8 CPUs at 167 MHz, 2GB RAM, Solaris 8 Update 7
2.0.36-dev snapshot from today
MaxRequestsPerChild 0
ThreadsPerChild 64
MinSpareThreads 64
M
Rose, Billy wrote:
>If I could receive feedback on the following email made on the 11th, I'd be
>willing to burn some hours to make the following MPM for testing:
>
>>I hope my emails are not annoying you guys. To give a more complete picture
>>of this (pulled from methods I used in a client serv
I just built httpd-2.0 out of CVS a minute ago, and I'm getting a
warning on my FreeBSD 4.5 system (gcc 2.95.3):
httpd-2.0/server/log.c:221: warning: control reaches end of non-void function
I'm just a passing APR/Subversion developer, but hey, I thought maybe
this is the correct patch for log
At 04:26 PM 4/17/2002, William A. Rowe, Jr. wrote:
>At 04:05 PM 4/17/2002, Greg Stein wrote:
>>Why is this change required?
>
>So we had to add the apr_progtype_e * so that it could be updated to reflect
>the new choice of interpreter.
Doug and I were just chatting about this. Perhaps if we chan
At 05:28 PM 4/17/2002, Cliff Woolley wrote:
>On Wed, 17 Apr 2002, Aaron Bannert wrote:
>
> > On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> > > Then copy the ,v file, then do a cvs rm of the original file. Finally,
> > > remove the tags from the new file.
> >
> > +1
>
>Better, thou
On Wed, 17 Apr 2002, Aaron Bannert wrote:
> On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> > Then copy the ,v file, then do a cvs rm of the original file. Finally,
> > remove the tags from the new file.
>
> +1
Better, though it still makes checkout by date be wrong. +0
--Cliff
-0.9 on simply moving them... this would make it impossible to check out
an older version of Apache (even 2.0.35!) and get the same thing that's in
the tarball.
We don't have much choice but to cvs rm, cvs add IMO.
--Cliff
On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> Then copy the ,v file, then do a cvs rm of the original file. Finally,
> remove the tags from the new file.
+1
-aaron
In my experience this argument always ends with: copy the ,v files, then
cvs rm the old version, with a comment on the order of "moved to
../wherever". Perhaps with a "moved from .../wherever" comment added to
the new version. I think it's even ended that way on this list a couple
times.
Messi
Then copy the ,v file, then do a cvs rm of the original file. Finally,
remove the tags from the new file.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message--
On Wed, Apr 17, 2002 at 03:16:43PM -0700, Ryan Bloom wrote:
> I would much rather move the ,v files. This is a standard argument on
> this list, and there has never been consensus. The history is important
> with stuff like MPMs, and doing a cvs rm, cvs add removes the history.
I'm more concern
I would much rather move the ,v files. This is a standard argument on
this list, and there has never been consensus. The history is important
with stuff like MPMs, and doing a cvs rm, cvs add removes the history.
Ryan
--
Ryan Bloom [
On Wed, Apr 17, 2002 at 10:17:07PM +0100, Thom May wrote:
> Hi,
> currently to do a vpath build you have to create certain directories in
> directory that you wish to build in, ie:
> build/
> srclib/{apr,apr-util,pcre,expat-lite}
> docs/conf
>
> This patch enables you to create a clean directory
On Wed, Apr 17, 2002 at 03:10:10PM -0700, Justin Erenkrantz wrote:
> Okay, so it seems we have consensus to move it.
>
> Uh, how do we move it?
>
> - Delete it and re-add them in the new directory
> - Move the .v files on icarus
If you move the ,v files you'll be messing with history, how about
On Tue, Apr 16, 2002 at 04:37:45PM -0700, Justin Erenkrantz wrote:
> Would people have issues if we move perchild to experimental?
Okay, so it seems we have consensus to move it.
Uh, how do we move it?
- Delete it and re-add them in the new directory
- Move the .v files on icarus
Thoughts? --
At 01:01 PM 4/17/2002, you wrote:
>Any chance of getting this patch implemented in a future 1.3.x release?
As the author of that patch for 2.0 ... I have to suggest no. Many other
interrelated changes have gone into 2.0's negotiation and other entangled
modules. Changing that back in 1.3 is no
At 03:41 PM 4/17/2002, Bill Stoddard wrote:
>I am not at all sure I like ap_rlog_error() adding an error-notes (to
>r->notes) under the
>covers. For those that are not familer with this, if you call
>ap_rlog_error() for a
>failed request, the first call will copy your log message to the output
At 04:05 PM 4/17/2002, Greg Stein wrote:
>Why is this change required?
Sorry... pulled in 30 directions at once. Here's the short answer.
This bugfix is required. If you study the entire code path of CGI creation
for Win32... you will discover that -most- exec's are by explicit full path
name
On Wed, Apr 17, 2002 at 01:57:32PM -0700, Aaron Bannert wrote:
> On Wed, Apr 17, 2002 at 01:56:13PM -0700, Greg Stein wrote:
> > Can we stop copying pod.[ch] all over the place? Maintenance is going to be
> > from hell. Just move the frickin' thing up into server/.
> >
> > And before anybody says
On Wed, Apr 17, 2002 at 10:40:34AM -0700, Aaron Bannert wrote:
>...
> I don't think we should treat this as a special case at all. If an
> empty brigade happens to be passed down the filter chain, oh well. It
> shouldn't be fatal (as with an assert()), but it should be discouraged
> (punishable by
On Tue, Apr 16, 2002 at 05:43:09AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/04/15 22:43:09
>
> Modified:.CHANGES STATUS
>include http_protocol.h
>modules/http http_protocol.c
>server protocol.c
> Log:
> Adds support f
The problem is that we have two different versions of the pod code.
That code really needs to be merged where possible, and #ifdef'ed where
it can't be merged.
When I originally did the split, it was just for worker, so it wasn't
such a big deal, but I whole-heartedly agree with Greg now. This c
Bill? Comments?
Why is this change required?
-g
On Tue, Apr 16, 2002 at 02:46:25AM -0700, Greg Stein wrote:
> Woah... this just blew away all modules built for 2.0.35. This is an API
> change, which thus means a very careful review of WHY this change was
> required. Specifically, is there any w
On Wed, 17 Apr 2002, Greg Stein wrote:
> Can we stop copying pod.[ch] all over the place? Maintenance is going to
> be from hell. Just move the frickin' thing up into server/.
++1
The only problem is it's already there, in mpm_common.c -- worker has a
variant of the code, so it had its own copy
On Wed, Apr 17, 2002 at 01:56:13PM -0700, Greg Stein wrote:
> Can we stop copying pod.[ch] all over the place? Maintenance is going to be
> from hell. Just move the frickin' thing up into server/.
>
> And before anybody says, "but not everybody will need those function, so it
> will bulk up the s
On Tue, Apr 16, 2002 at 11:37:06PM -, [EMAIL PROTECTED] wrote:
> brianp 02/04/16 16:37:06
>
> Added: server/mpm/experimental/threadpool config5.m4 Makefile.in
> mpm_default.h mpm.h pod.c pod.h threadpool.c
Can we stop copying pod.[ch] all over the place?
I am not at all sure I like ap_rlog_error() adding an error-notes (to r->notes) under
the
covers. For those that are not familer with this, if you call ap_rlog_error() for a
failed request, the first call will copy your log message to the output stream sent
back
to the client. You can end up w
Hi,
currently to do a vpath build you have to create certain directories in
directory that you wish to build in, ie:
build/
srclib/{apr,apr-util,pcre,expat-lite}
docs/conf
This patch enables you to create a clean directory and run configure
directly.
Cheers,
-Thom
--
Thom May -> [EMAIL PROTECTE
On Wed, Apr 17, 2002 at 02:58:03PM -0500, Rose, Billy wrote:
> If I could receive feedback on the following email made on the 11th, I'd be
> willing to burn some hours to make the following MPM for testing:
I think one part that is missing from this design is how you translate
these "connection o
If I could receive feedback on the following email made on the 11th, I'd be
willing to burn some hours to make the following MPM for testing:
>I hope my emails are not annoying you guys. To give a more complete picture
>of this (pulled from methods I used in a client server app):
>
>The initial p
Any chance of getting this patch implemented in a future 1.3.x release?
--
From: David Young <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Mar 2002 12:51:41 -0500
To: <[EMAIL PROTECTED]>
Subject: [PATCH] implement ForceLanguagePriority in 1.3
Implements the ForceLanguag
On Wed, Apr 17, 2002 at 01:27:19PM -0400, Cliff Woolley wrote:
> I would, too. Silently returning APR_SUCCESS seems bad to me; it could
> hide problems, plus it might be the case that some hypothetical filter
> might consider an empty brigade passed to it to be indicative of failure.
> ap_pass_br
> > Aren't global pools still cleaned up on exit? If the threads are still
> > running we'll still have the same problem. The only way I see to fix this
> > is to make sure that all threads have terminated before cleaning up
> > the pool.
>
> I don't see that they're getting cleaned up on exit.
On 17 Apr 2002, Jeff Trawick wrote:
> Is this so prevalent a problem in third-party modules that we need to
> protect ourself from PRs? If not, I'd prefer a segfault.
I would, too. Silently returning APR_SUCCESS seems bad to me; it could
hide problems, plus it might be the case that some hypot
"Sander Striker" <[EMAIL PROTECTED]> writes:
> > 1) always do libtool --install
>
> +1.
>
> > 2) look in installed .la file for the name that must be passed to
> >dlopen and rename that file in the target directory to what we
> >think a DSO ought to be named
>
> But we only need to do
Aaron Bannert <[EMAIL PROTECTED]> writes:
> On Wed, Apr 17, 2002 at 03:45:27PM -, [EMAIL PROTECTED] wrote:
> > trawick 02/04/17 08:45:27
> >
> > Modified:server/mpm/worker worker.c
> > Log:
> > use an independent pool for threads so that when we abandon them
> > during gracel
"Sander Striker" <[EMAIL PROTECTED]> writes:
> Isn't this the introduction of a memory leak?
> The threads keep being created, and the pool is _never_
> cleared.
worker does not continually create threads, so no memory leak/no
growing footprint over time... the OS cleans it up when we exit
--
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick
> Sent: 17 April 2002 17:13
> "Sander Striker" <[EMAIL PROTECTED]> writes:
>
>> Yes, and we should fix it.
>
> sure
>
>> This patch works for me. Not an expert on libtool, so I'd like some feedback.
>
> As far as
Isn't this the introduction of a memory leak?
The threads keep being created, and the pool is _never_
cleared.
Sander
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 17 April 2002 17:45
> To: [EMAIL PROTECTED]
> Subject: cvs commit: httpd-2.0/server/mpm/
It seems that NID_uniqueIdentifier has been removed in the latest
OpenSSL snapshots (0.9.8). (OpenSSL 0.9.6c doesn't correctly
init the PRNG on my Linux box - go figure.)
Is there any reason not to commit this? I could check for the
version, but an even simpler check is to see if that variable
40 matches
Mail list logo
