"J" == Justin [EMAIL PROTECTED] writes:
J I received a helpful recommendation to look into "lingerd" ...
J that would seem one approach to solve this issue.. but a
J lingerd setup is quite different from popular recommendations.
I think that's mostly because lingerd is so new. I'm sure as
My bad. it is
www.dslreports.com/front/example.gif
Sorry for those curious enough to check the URL out.
On Thu, Jan 04, 2001 at 06:10:09PM -0500, Rick Myers wrote:
On Jan 04, 2001 at 17:55:54 -0500, Justin twiddled the keys to say:
If you want to see what happens to actual output when
Hi there,
On Thu, 4 Jan 2001, Justin wrote:
So dropping maxclients on the front end means you get clogged
up with slow readers instead, so that isnt an option..
Try looking for Randall's posts in the last couple of weeks. He has
some nice stuff you might want to have a play with. Sorry, I
-Original Message-
From: G.W. Haywood [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 04, 2001 10:35 AM
To: Justin
Cc: [EMAIL PROTECTED]
Subject: Re: the edge of chaos
Hi there,
On Thu, 4 Jan 2001, Justin wrote:
So dropping maxclients on the front end means you get
"J" == Justin [EMAIL PROTECTED] writes:
J When things get slow on the back end, the front end can fill with
J 120 *requests* .. all queued for the 20 available modperl slots..
J hence long queues for service, results in nobody getting anything,
You simply don't have enough horsepower to serve
Justin
Cc: [EMAIL PROTECTED]
Subject: Re: the edge of chaos
Hi there,
On Thu, 4 Jan 2001, Justin wrote:
So dropping maxclients on the front end means you get clogged
up with slow readers instead, so that isnt an option..
Try looking for Randall's posts in the last coup
I need more horsepower. Yes I'd agree with that !
However... which web solution would you prefer:
A. (ideal)
load equals horsepower:
all requests serviced in =250ms
load slightly more than horsepower:
linear falloff in response time, as a function of % overload
..or..
B. (modperl+front
i see 2 things here, classic queing problem, and the fact
that swapping to disk is 1000's of times slower than serving
from ram.
if you receive 100 requests per second but only have the
ram to serve 99, then swapping to disc occurs which slows
down the entire system. the next second comes and
Justin wrote:
Thanks for the links! But. I wasnt sure what in the first link
was useful for this problem, and, the vacuum bots discussion
is really a different topic.
I'm not talking of vacuum bot load. This is real world load.
Practical experiments (ok - the live site :) convinced me that
- Original Message -
From: "Justin" [EMAIL PROTECTED]
To: "Geoffrey Young" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, January 04, 2001 4:55 PM
Subject: Re: the edge of chaos
Practical experiments (ok - the live site :) convinced me that
the well
Hi, and happy new year!
My modperl/mysql setup does not degrade gracefully when reaching
and pushing maximum pages per second :-) if you could plot
throughput, it rises to ceiling, then collapses to half or less,
then slowly recovers .. rinse and repeat.. during the collapses,
nobody but real
this is not the solution...
but it could be a bandaid until you find one.
set the MaxClients # lower.
# Limit on total number of servers running, i.e., limit on the number
# of clients who can simultaneously connect --- if this limit is ever
# reached, clients will be LOCKED OUT, so it should
Yep, I am familiar with MaxClients .. there are two backend servers
of 10 modperl processes each (Maxclients=start=10). Thats sized
about right. They can all pump away at the same time doing about
20 pages per second. The problem comes when they are asked to do
21 pages per second :-)
There is
13 matches
Mail list logo
