Paul J. Reder wrote:
Greg Ames wrote:
It would be great if somebody could beat it up on a live
non-FreeBSD system, and tell us what happens.
I'll run it through my battery of abuse tests tonight. If it survives the carnage
then we'll be in good shape.
After running the
Paul J. Reder wrote:
Greg Ames wrote:
It would be great if somebody could beat it up on a live
non-FreeBSD system, and tell us what happens.
I'll run it through my battery of abuse tests tonight. If it survives the carnage
then we'll be in good shape.
After running
On Wed, 25 Apr 2001, Roy T. Fielding wrote:
APR file io, when compiled with APR_HAS_THREADS (the default unless it
is specifically disabled or on a non-thread platform), is acquiring
mutex locks on every buffered file read or write. That is lunacy.
Whether or not locking is necessary
This stuff came up while Justin and Aaron were performance testing
mod_mbox -- right now you can double the requests per second simply
by recompiling with --disable-threads.
Wow, which MPM are you using? That is actually quite a suprise to me as Apache 2.0
performance is
close to
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Thursday, April 26, 2001 1:57 PM
This stuff came up while Justin and Aaron were performance testing
mod_mbox -- right now you can double the requests per second simply
by recompiling with --disable-threads.
Wow, which MPM are you
Justin Erenkrantz wrote:
Wow, which MPM are you using? That is actually quite a suprise to me as Apache 2.0
performance is
close to that of Apache 1.3 (on AIX at least) which does not use pool locking or
buffer locking for
file i/o.
We are currently using prefork because pthread
On Thu, Apr 26, 2001 at 11:57:26AM -0700, Justin Erenkrantz wrote:
...
We are currently using prefork because pthread is completely useless at
this point. Hopefully, the signals stuff gets fixed soon... Actually,
on FreeBSD, threaded MPMs are disabled, but no one tells APR, so it
defines
William A. Rowe, Jr. wrote:
Hmmm... notice that APR_HAS_THREADS is irrelevant to the MPM selected... you
_can_ using threading support in APR with a prefork MPM,
if you get this combo to work on FreeBSD, please let us know ASAP. But
do a top when it comes up, and be ready to do a
From: Greg Ames [EMAIL PROTECTED]
Sent: Thursday, April 26, 2001 2:46 PM
Hmmm... notice that APR_HAS_THREADS is irrelevant to the MPM selected... you
_can_ using threading support in APR with a prefork MPM,
if you get this combo to work on FreeBSD, please let us know ASAP. But
do a
Greg Ames wrote:
It would be great if somebody could beat it up on a live
non-FreeBSD system, and tell us what happens.
Looks fine here with Linux 2.2. Takes a few seconds (5 or so) with
threaded MPM to shut down completely. This is after hitting it with
about 5000 static requests
But we are still trying to link in pthreads, as witnessed by me getting
pthread_sigmask not found link errors on Darwin when building using
the prefork mpm. Or else it's just autoconf crud.
Chuck
On Thursday, April 26, 2001, at 03:18 PM, William A. Rowe, Jr. wrote:
From: Justin Erenkrantz
On Thu, Apr 26, 2001 at 01:56:56PM -0700, Justin Erenkrantz wrote:
Greg Ames wrote:
It would be great if somebody could beat it up on a live
non-FreeBSD system, and tell us what happens.
Looks fine here with Linux 2.2. Takes a few seconds (5 or so) with
threaded MPM to shut
Greg Ames wrote:
Paul, since you have quite a few monster files mixed in with the little
stuff, please tune the threaded parameters judiciously. We don't have
any automatic protection yet for low MaxRequestsPerChild combined with
high ThreadsPerChild combined with small scoreboards combined
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 2:52 PM
To: [EMAIL PROTECTED]
Subject: Re: thread locking within apr file io
On Thu, Apr 26, 2001 at 01:56:56PM -0700, Justin Erenkrantz wrote:
Greg Ames wrote
Greg Ames wrote:
Paul, since you have quite a few monster files mixed in with the little
stuff, please tune the threaded parameters judiciously. We don't have
any automatic protection yet for low MaxRequestsPerChild combined with
high ThreadsPerChild combined with small scoreboards
Linux 2.2 - threaded MPM - throw about 2000 requests at it and it runs
out of file descriptors (didn't pay attention to ab's error messages).
It seems to happen around the 1750-1950 request plateau.
I set ulimit -n to be 1024 - can't set it any higher in userspace -
/proc/sys/fs/file-max
Don't forget to raise:
/proc/sys/fs/inode-max (should be ~4 times file-max since sockets
count against these too)
/proc/sys/net/ipv4/ip_local_port_range (I like 32768-61000)
Furthermore, the file descriptor limit of 1024 only applies to earlier 2.2
kernels; what kernel
Paul J. Reder wrote:
Greg Ames wrote:
It would be great if somebody could beat it up on a live
non-FreeBSD system, and tell us what happens.
I'll run it through my battery of abuse tests tonight. If it survives the carnage
then we'll be in good shape.
Paul, since you have
18 matches
Mail list logo
