httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Burry" <dbu...@tagnet.org>
Subject Re: dynamically change max client value
Date Mon, 04 Nov 2002 18:44:22 GMT
I realize that allowing _everything_ to be dynamically configured via SNMP
(or signal or something) would probably be too substantial of an API change
to be considered for the current code base, but it would be nice to consider
it for some future major revision of Apache....

And it would be more than just "nice" if at least the max client value thing
could be somehow worked into the current versions of Apache...  There is a
current very real and very large problem that could be solved by this, not
just a "nice to have" feature.  This is what I meant to emphasize in my
original email...

Dave

----- Original Message -----
From: "Dirk-Willem van Gulik" <dirkx@webweaving.org>
To: <dev@httpd.apache.org>
Sent: Monday, November 04, 2002 9:35 AM
Subject: Re: dynamically change max client value


>
> In my ideal world every config directive would be able to advertize or
> register an optional 'has changed' hook. Which, if present, would be
> called in context whenever a value is somehow updated (through snmp, a
> configd, signal, wathever). If there is no such hook; the old -update- on
> graceful restart is the default (though it sure would be nice to have some
> values also advertize that they need a full shutdown and restart).
>
> Of course one could also argue for not just a put but also for a 'get'
> interface in context :-)
>
> Dw
>
> On Mon, 4 Nov 2002, David Burry wrote:
>
> > Recently there has been a little discussion about an API in apache for
> > controlling starts, stops, restarts, etc...
> >
> > I have an idea that may help me solve a problem I've been having.  The
> > problem is in limiting the number of processes that will run on a
machine to
> > somewhere below where the machine will keel over and die, while still
being
> > close to the maximum the machine will handle.  The issue is depending on
> > what the majority of those processes are doing it changes the maximum
number
> > a given machine can handle by a few orders of magnitude, so a
multi-purpose
> > machine that serves, say, static content and cgi scripts (or other
things
> > that vary greatly in machine resource usage) cannot be properly tuned
for
> > maximum performance while guaranteeing the machine won't die under heavy
> > load.
> >
> > The solution I've thought of is... what if Apache had an API that could
be
> > used to say "no more processes, whatever you have NOW is the max!"  or
> > otherwise to dynamically raise or lower the max number (perhaps "oh
there's
> > too many, reduce a bit")....  You see, an external monitoring system
could
> > monitor cpu and memory and whatnot and dynamically adjust apache
depending
> > on what it's doing.....  This kind of system could really increase the
> > stability of any large Apache server farm, and help keep large traffic
> > spikes from killing apache so bad that nobody gets served anything at
all.
> >
> > In fact this idea could be extended someday to dynamically change all
sorts
> > of apache configuration things, but all I really need that I know of
right
> > now is the max client value...
> >
> > What do you all think of this idea?  Does this already exist perhaps?
> >
> > Dave
> >
> >
>


Mime
View raw message