Jeff Trawick wrote:
Pier Fumagalli [EMAIL PROTECTED] writes:
I'm about to attempt to build Apache 2.0.37-dev at 64 bits with the Sun C
compiler (kindly donated by Sun), on Nagoya (worker MPM). Anything I should
be aware of? I'll report back on how the baby flies (if it does)...
There is
Hmm, why do I get this warning on stop:
WARNING: MaxClients (10) is not an integer multiple
of ThreadsPerChild (3), lowering MaxClients to 9
for a maximum of 3 child processes,
httpd (no pid file) not running
I do get it on start as well, which is expected, but why on stop?
Ian Holsman wrote:
jean-frederic clere wrote:
Jeff Trawick wrote:
Pier Fumagalli [EMAIL PROTECTED] writes:
I'm about to attempt to build Apache 2.0.37-dev at 64 bits with the
Sun C
compiler (kindly donated by Sun), on Nagoya (worker MPM). Anything I
should
be aware of? I'll report
BTW.. you do know that 64bit programs take a ~10% hit in performance
don't you?
Why's this?
-aaron
Jeff Trawick wrote:
Stas Bekman [EMAIL PROTECTED] writes:
Hmm, why do I get this warning on stop:
WARNING: MaxClients (10) is not an integer multiple
of ThreadsPerChild (3), lowering MaxClients to 9
for a maximum of 3 child processes,
httpd (no pid file) not running
I do get it on
A user posted [1] a benchmark today in the German PHP Newsgroup [2]
stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
than Apache 1.3.
Are there any official benchmarks out there? I can't quite believe
this...
--
[1] Message-ID: [EMAIL PROTECTED]
[2]
Ian Holsman wrote:
BTW.. you do know that 64bit programs take a ~10% hit in performance
don't you?
The JVM seems a lot faster (perceived performance, no actual data on hand)
at 64 bits rather than 32...
Pier
On Thu, 6 Jun 2002, Sebastian Bergmann wrote:
A user posted [1] a benchmark today in the German PHP Newsgroup [2]
stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
than Apache 1.3.
Are there any official benchmarks out there? I can't quite believe
this...
None
Cliff Woolley wrote:
On Thu, 6 Jun 2002, Sebastian Bergmann wrote:
A user posted [1] a benchmark today in the German PHP Newsgroup [2]
stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
than Apache 1.3.
Are there any official benchmarks out there? I can't quite
Aaron Bannert wrote:
BTW.. you do know that 64bit programs take a ~10% hit in performance
don't you?
Why's this?
Because of various reasons.
Maybe the major of them, is the size of used memory:
Memory usage is higher, because of default sizes of various types,
alignments, etc.
I/O is
I got myself into a bug that is way over my head:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
It seems that conditional GET (If-Modified-Since) is not working at all
correctly with output filters. If someone wants to take a look, please
have at it.
Joshua.
On Thu, Jun 06, 2002 at 05:15:33PM -0400, Cliff Woolley wrote:
On Thu, 6 Jun 2002, Joshua Slive wrote:
I got myself into a bug that is way over my head:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
It seems that conditional GET (If-Modified-Since) is not working at all
On Thu, 6 Jun 2002, Cliff Woolley wrote:
On Thu, 6 Jun 2002, Joshua Slive wrote:
I got myself into a bug that is way over my head:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
It seems that conditional GET (If-Modified-Since) is not working at all
correctly with output
On Thu, Jun 06, 2002 at 03:25:01PM -0600, Jean-Jacques Clar wrote:
Here are results done on a 4 x 450Mhz server with 1 Gb of RAM, 1
SysKonnect Gb LAN.
The tests were done using WebBench with 26 clients and 1 controller
running the default static test.
The OS is Linux RH 7.3 and Apache 2.0 is
[EMAIL PROTECTED] 06/06/02 03:33PM On Thu, Jun
06, 2002 at 03:25:01PM -0600, Jean-Jacques Clar wrote: Here are results
done on a 4 x 450Mhz server with 1 Gb of RAM, 1 SysKonnect Gb
LAN. The tests were done using WebBench with 26 clients and 1
controller running the default static test. The
Jean-Jacques Clar wrote:
I tried to build 2.0 with the worker and the perchild model but it seg
faults all the time.
Is anyone as RH7.3 working binaries of 2.0.36 I could use to run the
same suite of tests?
Maybe I could make more pretty neat graphs.
I recommend using 2.0.37 (either one
Mostly because I've been running threadpool for a while and the lack of this
support was getting annoying.
Cheers,
-Thom
--
Thom May - [EMAIL PROTECTED]
ICANN has been making all their meetings closed door so nobody can see that
they've been spending the majority of their budget on crack...
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
On Thu, Jun 06, 2002 at 05:15:33PM -0400, Cliff Woolley wrote:
On Thu, 6 Jun 2002, Joshua Slive wrote:
I got myself into a bug that is way over my head:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
It seems that
Thom May wrote:
Mostly because I've been running threadpool for a while and the lack of this
support was getting annoying.
Cheers,
-Thom
I've actually been thinking that it's time to remove threadpool
and leader/follower, because all the improvements that we developed
in those experimental
On Thu, Jun 06, 2002 at 04:23:05PM -0700, Brian Pane wrote:
I've actually been thinking that it's time to remove threadpool
and leader/follower, because all the improvements that we developed
in those experimental MPMs have been incorporated into worker as of
2.0.37. But if you have a setup
On Thu, 6 Jun 2002, Aaron Bannert wrote:
I think it's useful to have these alternative designs in our experimental
category, and I'm willing to maintain the threadpool MPM. If anything I'd
like to keep them around to help foster ideas about other potential MPMs.
+1 to hanging onto them for
Cliff Woolley wrote:
On Thu, 6 Jun 2002, Aaron Bannert wrote:
I think it's useful to have these alternative designs in our experimental
category, and I'm willing to maintain the threadpool MPM. If anything I'd
like to keep them around to help foster ideas about other potential MPMs.
On Thu, Jun 06, 2002 at 04:44:15PM -0700, Brian Pane wrote:
Fair enough; I'll commit the -k patch. If the goal is to encourage thinking
about other potential MPMs, though, then IMHO the right solution is to
add an
empty server/mpm/experimental/event-loop directory :-)
I'd *love* to see
On Thu, Jun 06, 2002 at 04:51:10PM -0700, Aaron Bannert wrote:
I'd *love* to see progress on something like this, but whenver I start
thinking about this kind of a MPM I run into the problem where brigades
(or filter chains) can't be multiplexed over. Is this what you have
in mind? (Let's get
On Thu, Jun 06, 2002 at 04:11:12PM -0700, Ryan Bloom wrote:
If you delay calling ap_meets_conditions, then you are going to slow
down the server. Think about the easiest case, default_handler and
mod_deflate. The default_handler grabs a file from the disk and sends
it to mod_deflate, which
Ryan Bloom wrote:
For the limits stuff, we need to decide if we want to return 413 if the
server doesn't care about the request. For example, default_handler
always just discards the request body, so is it an error if the user
sends 100 Meg of data with a request that is just going to ignore
On Thu, Jun 06, 2002 at 04:44:15PM -0700, Brian Pane wrote:
Fair enough; I'll commit the -k patch. If the goal is to encourage
thinking
about other potential MPMs, though, then IMHO the right solution is
to
add an
empty server/mpm/experimental/event-loop directory :-)
I'd *love* to
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
On Thu, Jun 06, 2002 at 04:51:10PM -0700, Aaron Bannert wrote:
I'd *love* to see progress on something like this, but whenver I
start
thinking about this kind of a MPM I run into the problem where
brigades
(or filter chains) can't be
On Thu, Jun 06, 2002 at 05:10:58PM -0700, Brian Pane wrote:
Ryan Bloom wrote:
For the limits stuff, we need to decide if we want to return 413 if the
server doesn't care about the request. For example, default_handler
always just discards the request body, so is it an error if the user
On Fri, Jun 07, 2002 at 12:59:03AM -, [EMAIL PROTECTED] wrote:
jerenkrantz2002/06/06 17:59:03
Modified:.STATUS
Log:
Clarify note on ap_discard_request_body(). If we want to change it,
we should do it before .37 - hence its remaining as a showstopper.
Why
On Thu, 6 Jun 2002, Greg Stein wrote:
On Thu, Jun 06, 2002 at 05:10:58PM -0700, Brian Pane wrote:
Ryan Bloom wrote:
For the limits stuff, we need to decide if we want to return 413 if the
server doesn't care about the request. For example, default_handler
always just discards the
++1 to everthing in this e-mail.
Thank you Greg, you have just stated everything that I have been thinking
for sometime. Remember when I tagged 2.0.33? I did that without any
notice to prove that it could be done without a four week discussion
on-list. Granted, we didn't release that
On Thu, 6 Jun 2002, Ryan Bloom wrote:
So... why a showstopper? Why hold up .37? Let's hear it.
Guys, chill. If I could have released .37 last week, don't you think I
would have? But the damned thing wouldn't even work on Windows until mere
days ago. So now it's tidy up a few issues and .37
As of 12:15am or so EDT as 2.0.37-dev4. I'll keep an eye on it, but
please let me know if you see any unusual behavior.
--Cliff
flood STATUS: -*-text-*-
Last modified at [$Date: 2002/01/17 01:09:45 $]
Release:
milestone-04: In development
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
milestone-02: Tagged August 13, 2001
httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
36 matches
Mail list logo
