On Tue, Apr 24, 2001 at 12:39:29PM +0800, Lincoln Yeoh wrote:
> At 03:09 PM 23-04-2001 -0300, you wrote:
> >Basically, if great to set max clients to 256, but if load hits 50
> >as a result, the database is near to useless ... if you set it to 256,
> >and 254 idle connections are going, load won't rise much, so is safe,
> >but if half of those processes are active, it hurts ...
>
> Sorry, but I still don't understand the reasons why one would want to do
> this. Could someone explain?
>
> I'm thinking that if I allow 256 clients, and my hardware/OS bogs down
> when 60 users are doing lots of queries, I either accept that, or
> figure that my hardware/OS actually can't cope with that many clients
> and reduce the max clients or upgrade the hardware (or maybe do a
> little tweaking here and there).
>
> Why not be more deterministic about refusing connections and stick
> to reducing max clients? If not it seems like a case where you're
> promised something but when you need it, you can't have it.
The point is that "number of connections" is a very poor estimate of
system load. Sometimes a connection is busy, sometimes it's not.
Some connections are busy, some are not. The goal is maximum
throughput or some tradeoff of maximum throughput against latency.
If system throughput varies nonlinearly with load (as it almost
always does) then this happens at some particular load level.
Refusing a connection and letting the client try again later can be
a way to maximize throughput by keeping the system at the optimum
point. (Waiting reduces delay. Yes, this is counterintuitive, but
why do we queue up at ticket windows?)
Delaying response, when under excessive load, to clients who already
have a connection -- even if they just got one -- can have a similar
effect, but with finer granularity and with less complexity in the
clients.
Nathan Myers
ncm@zembu.com