httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Scoreboard redesign
Date Thu, 17 May 2001 00:06:04 GMT

>
> > > > hmmm...more thought, code reading, and whiteboard doodling is called
> > > > for.  Off the top of my head, I would think one of the config hooks in
> > > > mod_status could allocate a big chuck of shmem for its use on every
> > > > restart.  Then the new worker processes would see the Right Stuff as far
> > >
> > > You can't allocate on every restart,
> >
> > sure we can, if we are careful about cleaning up
> >
> > >                                       because if you do, the information
> > > won't survive a restart.  Imagine the pathological case, where a single
> > > request is very long-lived, and it happens to survive multiple restarts.
> > > If we reallocate during each restart, we will lose the status of that
> > > request.
> >
> > good point...easily solved I think.  "last guy out turns out the lights"
> > - when the last process for generation x goes away, it's time to clean
> > up generation x's huge chunk of shmem.
> >
> > >
> > > > as pointers.  The core should also allocate a new chunk of shmem to
> > > > represent the processes at restart time, so we can get rid of the
> > > > HARD_SERVER_LIMIT stuff (it's a PITA...think of admins in big shops who
> > >
> > > Again, you can't do that,
> >
> > understand your concern, but it just requires code.
>
> You are talking about adding a lot of logic that has very little benefit
> IMO.  The purpose for these changes, are to remove HARD_SERVER_LIMIT, and
> to make it easier to remove some shared memory if mod_status is not
> loaded.  How big a hardship is HARD_SERVER_LIMIT, and how much memory are
> we really talking about?
>

 I am working with a customer that wants to support 10,000 concurrent clients on a single
machine.
That number will just grow in the future.  I think the actual memory used by the scoreboard
in this
case may be trivial compared  the savings with moving to a threaded server.  On some systems,
shared
memory is pinned (non-pagable) real memory. How big a chunk can you expect to allocate at
a time?
If we can safely allocate say 20MB of shared storage, then maybe you are right and we shouldn't
be
worrying about eliminating HARD_SERVER_LIMIT.

Bill


Mime
View raw message