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 NOT BE SET TOO
LOW.
# It is intended mainly as a brake to keep a runaway server from
taking
# the system with it as it spirals down...
#
MaxClients 150
>On Wed, Jan 03, 2001 at 10:25:04PM -0500, Justin wrote:
> 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 patient people are getting anything.. most page
> production is wasted: goes from modperl-->modproxy-->/dev/null
>
> I know exactly why .. it is because of a long virtual
> "request queue" enabled by the front end .. people "leave the
> queue" but their requests do not.. pressing STOP on the browser
> does not seem to signal mod_proxy to cancel its pending request,
> or modperl, to cancel its work, if it has started.. (in fact if
> things get real bad, you can even find much of your backend stuck
> in a "R" state waiting for the Apache timeout variable
> to tick down to zero..)
>
> Any thoughts on solving this? Am I wrong in wishing that STOP
> would function through all the layers?
>
> thanks
> -Justin
Thanks,
Jeff
---------------------------------------------------
| "0201: Keyboard Error. Press F1 to continue." |
| -- IBM PC-XT Rom, 1982 |
---------------------------------------------------
| Jeff Sheffield |
| [EMAIL PROTECTED] |
| AIM=JeffShef |
---------------------------------------------------
