[Zope-dev] How to make Zope fail nicely under high load?

[Jamie Heilman]

Bjorn Stabell wrote:
> You'll always reach the bottleneck sooner or later, and in 99% of the
> cases it'll be Zope.  It's not exactly a racing horse.

Tell me about it, in a former life I was the guy with the pager.

> With KeepAlive on, wouldn't everything in one "session" sent over one
> TCP connection?  If that is the case, each accept() will basically
> service a whole session, and so you should be able to do the easy thing
> of refusing a connection just after an accept().

No, a session isn't that nice and tidy, clients can and do open multiple
simultaneous connections, connection re-use and pipelining aren't all
that define a session.  If it were that easy, ZServer would do this
already, so would, I imagine, Apache.  Its not a pretty problem, which
is why I suggest you spend your time looking at what you can do to
scale better, or look for an Apache module that implements some
sane-sounding session heuristic and give it a whirl, it will increase
the resources needed by Apache, but maybe the costs will balance out.

> We'll do that as well, but this problem is pretty serious; we can't
> overload our server for even just a little while before latencies start
> building up to ridiculous levels and users start hitting reload, further
> compounding the problem.  In the end we have to restart the server, same
> as Dario reported.

You'll have to move to load spreading, zeo, etc if you can't tweak
your app any further.  I personally feel that the ZEO seperation
should be compulsary anyway, it just makes more sense, but I digress.
Find yourself an Apache module that can spit out 503s, then work on
load balancing infrastructure, which is probably the most viable
longterm solution (next to simply not using Zope for something it
evidently isn't very good at).

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/