On 10/24/07, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> >
> > On Oct 24, 2007, at 10:20 AM, Jim Jagielski wrote:
> >
> > > Looking at the below... testing as we speak:
> > >
> >
> > Testing past and placed it on a test server which gets
> > hit
On 10/24/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Oct 24, 2007, at 10:20 AM, Jim Jagielski wrote:
>
> > Looking at the below... testing as we speak:
> >
>
> Testing past and placed it on a test server which gets
> hit with goodly amounts of traffic. So far, so good :)
The patch looks fi
On Oct 24, 2007, at 10:20 AM, Jim Jagielski wrote:
Looking at the below... testing as we speak:
Testing past and placed it on a test server which gets
hit with goodly amounts of traffic. So far, so good :)
Will give 24hrs and commit.
Looking at the below... testing as we speak:
Index: main/http_main.c
===
--- main/http_main.c(revision 587509)
+++ main/http_main.c(working copy)
@@ -362,7 +362,7 @@
/*
* Parent process local storage of child pids
*/
-sta
On Oct 24, 2007, at 9:49 AM, Jeff Trawick wrote:
Should I look at something like the above?
please ;)
I did a quick and dirty profile and we do save space (of
course, plus it's static space, as in non-growing) and
speed as well, even worse case.
On 10/24/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Oct 24, 2007, at 8:54 AM, Jim Jagielski wrote:
>
> >
> > On Oct 23, 2007, at 7:34 PM, Jeff Trawick wrote:
> >
> >>
> >> Alternative opinions?
> >
> > Alternative implementations are welcomed.
> >
>
> Certainly one trade-off would be speed
On Oct 24, 2007, at 8:54 AM, Jim Jagielski wrote:
On Oct 23, 2007, at 7:34 PM, Jeff Trawick wrote:
Alternative opinions?
Alternative implementations are welcomed.
Certainly one trade-off would be speed over space; having
pid_table an actual (C) array of pids. When "setting" we would
se
On Oct 23, 2007, at 7:34 PM, Jeff Trawick wrote:
Alternative opinions?
Alternative implementations are welcomed.
With 1.3.39, typically 16 bytes are lost forever in the parent process
at child process creation with the ap_table_set(). Did anyone work
through a rationalization of this?
Perhaps we could say that 8MB is the amount by which the size of the
parent could grow in three months before causing undue i
