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/