...as in stick a fork in it, its 'DONE". ;)
Rasmus Lerdorf wrote:
>>As it happens, DONE is defined to be -2. :-)
>>
>
> Ok, I will use that, but 'DONE' doesn't really give the impression of
> being a fatal error return value.
>
> -Rasmus
>
>
>
--
Paul J. Reder
-
> >>-1 on buffering across requests, because the performance problems
> >>caused by the extra mmap+munmap will offset the gain you're trying
> >>to achieve with pipelining.
> >>
> >>
> >
> >Wait a second. Now you want to stop buffering to fix a completely
> >differeny bug. The idea that we can'
> From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
> > > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > > Ryan Bloom wrote:
> > > >>From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > > >>Ryan Bloom wrote:
> > Wait a second. Now you want to stop buffering to fix a completely
> > differeny bug. The i
> > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > Ryan Bloom wrote:
> >
> > >>From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > >>
> > >>Ryan Bloom wrote:
> > >>
> > >>
> > >>
> > >>>I think we should leave it alone. This is the difference between
> > >>>benchmarks and the real world. How ofte
> From: Brian Pane [mailto:[EMAIL PROTECTED]]
> Ryan Bloom wrote:
>
> >>From: Brian Pane [mailto:[EMAIL PROTECTED]]
> >>
> >>Ryan Bloom wrote:
> >>
> >>
> >>
> >>>I think we should leave it alone. This is the difference between
> >>>benchmarks and the real world. How often do people have 8 requ
On Mon, 24 Jun 2002, Brian Pane wrote:
> On Mon, 2002-06-24 at 02:16, Andi Gutmans wrote:
>
> > > * PHP's nonbuffered output mode produces very small socket writes
> > > with Apache 2.0. With 1.3, the httpd's own output buffering
> > > alleviated the problem. In 2.0, where the PHP mo
> From: Brian Pane [mailto:[EMAIL PROTECTED]]
>
> Ryan Bloom wrote:
>
> >I think we should leave it alone. This is the difference between
> >benchmarks and the real world. How often do people have 8 requests
in a
> >row that total less than 8K?
> >
> >As a compromise, there are two other opti
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote:
> Up from 397 requests/second but still nowhere near the 615 requests/second
> for Apache 1.3. But, doing this buffering internally in PHP and then
> again in Apache doesn't seem efficient to me, and the numbers would seem
> to reflect this inefficienc
Brian Pane wrote:
> That definitely will improve the numbers, but I'd rather not spend the
> next few years saying "turn on buffering in mod_php" every time another
> user posts a benchmark claiming that "Apache 2.0 sucks because it runs
> my PHP scripts ten times slower than 1.3 did." :-)
Well
> * Saying "turn on buffering" is, IMHO, a reasonable solution if you
> can make buffering the default in PHP under httpd-2.0. Otherwise,
> you'll surprise a lot of users who have been running with the default
> non-buffered output using 1.3 and find that all their applications
> are far
On Mon, 2002-06-24 at 02:16, Andi Gutmans wrote:
> > * PHP's nonbuffered output mode produces very small socket writes
> > with Apache 2.0. With 1.3, the httpd's own output buffering
> > alleviated the problem. In 2.0, where the PHP module splits
> > long blocks of static text int
Ryan Bloom wrote:
>>>It would be nice
>>>if there was an apxs flag that would return the MPM type.
>>
>>+1
>
>
> There is. -q will query for any value in config_vars.mk, and MPM_NAME
> is in that file. So `apxs -q MPM_NAME` will return the configured MPM
> type.
>
> Ryan
>
This is the wrong
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
>
> > As it happens, DONE is defined to be -2. :-)
>
> Ok, I will use that, but 'DONE' doesn't really give the impression of
> being a fatal error return value.
I know. It's original use was for use during request processing, when a
module wa
> As it happens, DONE is defined to be -2. :-)
Ok, I will use that, but 'DONE' doesn't really give the impression of
being a fatal error return value.
-Rasmus
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
>
> On Mon, 24 Jun 2002, Cliff Woolley wrote:
> > On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
> >
> > > Hrm.. Nope. doing 'return DECLINED' from the post_config phase
does
> not
> > > stop the server from starting. I have this:
> >
> > I thought
On Mon, 24 Jun 2002, Cliff Woolley wrote:
> On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
>
> > Hrm.. Nope. doing 'return DECLINED' from the post_config phase does not
> > stop the server from starting. I have this:
>
> I thought you were supposed to return HTTP_INTERNAL_SERVER_ERROR.
In include/
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
>
> On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
>
> > Hrm.. Nope. doing 'return DECLINED' from the post_config phase
does
> not
> > stop the server from starting. I have this:
>
> I thought you were supposed to return HTTP_INTERNAL_SERVER_ERROR
cisco, CA
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 8:34 AM
> To: Ryan Bloom
> Cc: [EMAIL PROTECTED]
> Subject: RE: Apache 2.0 Numbers
>
>
>
> On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
>
> &
On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
> Hrm.. Nope. doing 'return DECLINED' from the post_config phase does not
> stop the server from starting. I have this:
I thought you were supposed to return HTTP_INTERNAL_SERVER_ERROR.
--Cliff
On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
> > > What is the correct way to fail in a filter post_config? Do I return
> > -1
> > > from it if my filter finds a fatal error? I can't use ap_log_rerror()
> > at
> > > this point, right? How would I log the reason for the failure?
> >
> > I'm con
> > What is the correct way to fail in a filter post_config? Do I return
> -1
> > from it if my filter finds a fatal error? I can't use ap_log_rerror()
> at
> > this point, right? How would I log the reason for the failure?
>
> I'm confused by the question, but I'll try to answer. If you mean
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
>
> > Runtime is harder, but you can just use ap_mpm_query to get the MPMs
> > characteristics. This won't give you the MPM name, but it will let
you
> > know if the MPM is threaded or not.
>
> What is the correct way to fail in a filter post_co
> Runtime is harder, but you can just use ap_mpm_query to get the MPMs
> characteristics. This won't give you the MPM name, but it will let you
> know if the MPM is threaded or not.
What is the correct way to fail in a filter post_config? Do I return -1
from it if my filter finds a fatal error?
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
>
> > > > It would be nice
> > > > if there was an apxs flag that would return the MPM type.
> > >
> > > +1
> >
> > There is. -q will query for any value in config_vars.mk, and
MPM_NAME
> > is in that file. So `apxs -q MPM_NAME` will return the
> > > It would be nice
> > > if there was an apxs flag that would return the MPM type.
> >
> > +1
>
> There is. -q will query for any value in config_vars.mk, and MPM_NAME
> is in that file. So `apxs -q MPM_NAME` will return the configured MPM
> type.
Ah right. Is there a way to check at runti
On Sun, 23 Jun 2002, Brian Pane wrote:
> On Sun, 2002-06-23 at 18:58, Rasmus Lerdorf wrote:
>
> > Someone asked me for numbers when I mentioned the other day that Apache
> > 2-prefork was really not a viable drop-in replacement for Apache 1.3 when
> > it comes to running a PHP-enabled server.
>
Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> From: Brian Pane [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 23, 2002 9:38 PM
> To: [EMAIL PROTECTED]
> Subject: core_output_filter buffering for keepalives? Re: Apache 2.0
> Numbers
> > It would be nice
> > if there was an apxs flag that would return the MPM type.
>
> +1
There is. -q will query for any value in config_vars.mk, and MPM_NAME
is in that file. So `apxs -q MPM_NAME` will return the configured MPM
type.
Ryan
> Bill Stoddard wrote:
> .
>
> >So changing the AP_MIN_BYTES_TO_WRITE just moves the relative postion of the write()
and
> >the check pipeline read.
> >
>
> It has one other side-effect, though, and that's what's bothering me:
> In the case where core_output_filter() decides to buffer a resp
On Mon, Jun 24, 2002 at 01:07:48AM -0400, Cliff Woolley wrote:
> Anyway, what I'm saying is: don't make design decisions of this type based
> only on the results of an ab run.
+1
I think at this point ab should have the ability to interleave issuing
new connections, handling current requests, an
> On Sun, 2002-06-23 at 20:58, Brian Pane wrote:
>
> > For what it's worth, I just tried the test case that you posted. On my
> > test system, 2.0 is faster when I run ab without -k, and 1.3 is faster
> > when I run with -k.
>
> I studied this test case and found out why 2.0 runs faster in the
Hi Rasmus..
I did the same test (without Keepalives) on my machine and found that
for the static HTML page Apache 2.0 was nearly the same.
Script is attached.. basic summary
For Static Files:
version
5 concurrent20 concurrent
1.3.26
429.39 418.62
2.0.40-d
430.08
On Sun, 2002-06-23 at 20:58, Brian Pane wrote:
> For what it's worth, I just tried the test case that you posted. On my
> test system, 2.0 is faster when I run ab without -k, and 1.3 is faster
> when I run with -k.
I studied this test case and found out why 2.0 runs faster in the
non-keepalive
On Sun, 2002-06-23 at 18:58, Rasmus Lerdorf wrote:
> Someone asked me for numbers when I mentioned the other day that Apache
> 2-prefork was really not a viable drop-in replacement for Apache 1.3 when
> it comes to running a PHP-enabled server.
>
> Apache 1.3 is still significantly faster than A
34 matches
Mail list logo
