On Wed, 19 Apr 2000, Joshua Chamas wrote:
> Stas Bekman wrote:
> >
> > Geez, I always forget something :(
> >
> > You are right. I forgot to mention that this was a scenario for the 23 Mb
> > of unshared memory. I just wanted to give an example. Still somehow I'm
> > almost sure that there are servers where even with sharing in place, the
> > hypothetical scenario I've presented is quite possible.
> >
> > Anyway, it's just another patent for squeezing some more juice from your
> > hardware without upgrading it.
> >
>
> Your scenario would be more believable with 5M unshared, even
> after doing ones best to share everything. This is pretty typical
> when connecting to databases, as the database connections cannot
> be shared, and especially DB's like Oracle take lots of RAM
> per connection.
Good idea. 5MB sounds closer to the real case than 10Mb. I'll make the
correction. Thanks!!!
> I'm not sure that your scenario is worthwhile if someone does
> a good job preloading / sharing code across the forks, and
> the difference will really be how much of the code gets dirty
> while you run things, which can be neatly tuned with MaxRequests.
Agree. But not everybody knows to do that well. So the presented idea
might still find a good use at some web shops.
> Interesting & novel approach though. I would bet that if people
> went down this path, they would really end up on different machines
> per web application, or even different web clusters per application ;)
:)
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------
