Hey,
Let's cut this thread because it's not going anywhere.
Once 5.0 is out I'll try and play with a few things and see if memory
consumption can be reduced. It's not something which I meant to happen for
5.0 anyway which is now in bug fix only mode. Whether it's by supporting a
--lean-and-mean
On Thu, 8 Jan 2004, Ilia Alshanetsky wrote:
> On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> > Well, if we really get to save 100K as Ilia imagined, for a thousand
> > children, it's 100MB, and there are those with more. I doubt we can easily
> > get 100K though.
>
> 'Freeing' 100k is not as
> At 23:24 08/01/2004, Sterling Hughes wrote:
> >> >p.s. Is there a technical reason the function table could be shareable
> >> >across children? I can't think of one of the top of my head.
> >>
> >> I guess you're missing a 'not' in this question? :) Anyway, the reason
> >it
> >> cannot be shar
> >p.s. Is there a technical reason the function table could be shareable
> >across children? I can't think of one of the top of my head.
>
> I guess you're missing a 'not' in this question? :) Anyway, the reason it
> cannot be shared is that it also contains user-defined functions. It
> sta
> At 20:57 08/01/2004, George Schlossnagle wrote:
>
> >On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
> >>
> >>Personally, I'm not convinced this is that case, even if the people we're
> >>dealing with run thousands of Apache processes per server (which they do).
> >
> >Unless they're running th
On Thu, 8 Jan 2004, Christian Schneider wrote:
> Rasmus Lerdorf wrote:
> > Yup, thousands of little servers with less than 100 httpd children on each
> > is how the biggest web load in the world is handled.
>
> I completely agree and think this is the way to do it. The only point to
> consider
On Jan 8, 2004, at 5:31 PM, Christian Schneider wrote:
Rasmus Lerdorf wrote:
Yup, thousands of little servers with less than 100 httpd children on
each is how the biggest web load in the world is handled.
I completely agree and think this is the way to do it. The only point
to consider might be
Rasmus Lerdorf wrote:
Yup, thousands of little servers with less than 100 httpd children on each
is how the biggest web load in the world is handled.
I completely agree and think this is the way to do it. The only point to
consider might be KeepAlive which binds processes without using any
CPU/I
On Thu, 8 Jan 2004, George Schlossnagle wrote:
> As a complete aside - I've always found it to be really hard to avoid
> context-switching myself to death running near that many processes. I
> believe the Y! folks had similar experience. I'm having trouble
> envisioning an app were that runs w
Hello Zeev,
Thursday, January 8, 2004, 10:40:19 PM, you wrote:
> At 23:34 08/01/2004, Ilia Alshanetsky wrote:
>>On January 08, 2004 04:11 pm, Zeev Suraski wrote:
>> > Well, if we really get to save 100K as Ilia imagined, for a thousand
>> > children, it's 100MB, and there are those with more. I
On Jan 8, 2004, at 4:40 PM, Zeev Suraski wrote:
At 23:34 08/01/2004, Ilia Alshanetsky wrote:
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we
can easily
> get
At 23:34 08/01/2004, Ilia Alshanetsky wrote:
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we can easily
> get 100K though.
'Freeing' 100k is not as difficult a
At 23:24 08/01/2004, Sterling Hughes wrote:
> >p.s. Is there a technical reason the function table could be shareable
> >across children? I can't think of one of the top of my head.
>
> I guess you're missing a 'not' in this question? :) Anyway, the reason it
> cannot be shared is that it also co
On Jan 8, 2004, at 4:24 PM, Sterling Hughes wrote:
p.s. Is there a technical reason the function table could be
shareable
across children? I can't think of one of the top of my head.
I guess you're missing a 'not' in this question? :) Anyway, the
reason it
cannot be shared is that it also cont
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we can easily
> get 100K though.
'Freeing' 100k is not as difficult as it sounds in PHP 5 when you consider
that
At 21:59 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 2:12 PM, Zeev Suraski wrote:
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of
On Jan 8, 2004, at 2:12 PM, Zeev Suraski wrote:
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of Apache processes per server
(which they do).
Un
On Thu, 8 Jan 2004, Zeev Suraski wrote:
> Obviously we're talking about httpd children and not 1,000
> roots... Anyway, depending on the module, if there's any sort of RINIT
> initialization, the CoW trick doesn't work very well and it consumes some
> per-process memory. There's also the funct
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people we're
dealing with run thousands of Apache processes per server (which they do).
Unless they're running thousands of apache server in
On Thu, 8 Jan 2004, Zeev Suraski wrote:
> Personally, I'm not convinced this is that case, even if the people we're
> dealing with run thousands of Apache processes per server (which they do).
But could you explain where you see the significant incremental memory
usage going from 20 to 2000 httpd
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of Apache processes per server (which
they do).
Unless they're running thousands of apache server instances (not just
children), shouldn't the memo
At 19:53 08/01/2004, Rasmus Lerdorf wrote:
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> It wouldn't hurt anyone and it *is* a pressing problem from talks I've had
> with all sorts of ppl that have high traffic machines.
You must be talking to different people than I am.
We are :)
100 or so function
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> It wouldn't hurt anyone and it *is* a pressing problem from talks I've had
> with all sorts of ppl that have high traffic machines.
You must be talking to different people than I am. 100 or so functions
all sitting in shared pages and thus shared across
On Jan 8, 2004, at 12:22 PM, Marcus Boerger wrote:
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be
more
dangerous than the performance benefit. Which, BTW, I estmate as
pretty
mini
On Thu, 08 Jan 2004, Andi Gutmans wrote:
> You are all missing the point. All the ext/standard would still be enabled
> by default, but it would allow people with very high traffic sites who need
> to save every bit of memory they can to build a lean-and-mean version of
> PHP.
If they want lean
Hello Andi,
Thursday, January 8, 2004, 6:02:42 PM, you wrote:
> At 02:24 PM 1/8/2004 +0100, Christian Schneider wrote:
>>Stanislav Malyshev wrote:
>>>I'm concerned that this problem of breaking common platform might be more
>>>dangerous than the performance benefit. Which, BTW, I estmate as prett
Andi Gutmans wrote:
I don't even mind if --disable-all doesn't disable ext/standard but it'd
be nice that if we do a split to core/ and standard/ (I wouldn't go into
more granularity than that) that we could have a --disable-standard.
I see no problem if it's not included in --disable-all. It is
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
> Stanislav Malyshev wrote:
>> I'm concerned that this problem of breaking common platform might be more
>> dangerous than the performance benefit. Which, BTW, I estmate as pretty
>> minimal - code space is shared on all modern O
Andi Gutmans wrote:
At 06:43 PM 1/8/2004 +0200, Jani Taskinen wrote:
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for leven
On January 08, 2004 12:02 pm, Andi Gutmans wrote:
> You are all missing the point. All the ext/standard would still be enabled
> by default, but it would allow people with very high traffic sites who need
> to save every bit of memory they can to build a lean-and-mean version of
> PHP. These kinds
At 06:43 PM 1/8/2004 +0200, Jani Taskinen wrote:
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
>meta
At 02:24 PM 1/8/2004 +0100, Christian Schneider wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
>metaphone etc.), ext/std_hash (crc32, sha1) and have
Removing few functions from standard will not save more then a few kilobytes
from the final binary (stripped). However, it'll create problems for people
who try to write portable scripts relying on those extensions. For example
ext/ctype is pretty basic functionality and is even enabled by defau
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
I think that's a good point for leaving it the way it
On Thu, 8 Jan 2004, Wez Furlong wrote:
> As Stas mentioned, I'm not sure that this is a good idea, unless
> we split some of these things out of ext/standard and into their
> own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
> metaphone etc.), ext/std_hash (crc32, sha1) and h
As Stas mentioned, I'm not sure that this is a good idea, unless
we split some of these things out of ext/standard and into their
own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
metaphone etc.), ext/std_hash (crc32, sha1) and have those extensions
compiled in by default.
II
AG>> but I think it'd be nice to brainstorm about this to see how we can
AG>> solve this, maybe for 5.1? If regex isn't required by the core that's
AG>> one of the first things I'd like to see disabled when building with
AG>> --disable-all. I think ext/standard should maybe be split up into
AG>> tw
38 matches
Mail list logo
