On 7/05/2004, at 4:39 PM, Tres Seaver wrote:

Michael Dunstan wrote:
On 7/05/2004, at 5:15 AM, Kris Erickson wrote:
No, that's not the problem;
in THEORY that's what is happening, but in reality there is no way that this is the case;
We just unrolled a registration system with participation rates at or around 100 to 200 participants per month;
At any given time, monitoring the session data container, there are *at most* 1 or 2 items in the transient object container--EXCEPT when it spikes...
I have seen such spikes occur (in a corner case) where some breads of web robots were aggressively hitting a page that used sessions. These robots did not bother to return the cookie handed out by the server. Each page hit effectively constructs a new session.
Have a look through your access logs to see if can see signs of something similar happening.
Not all web robots are created equal. I ended up sniffing for the user agent and returning a page that does not use sessions for the offending robots. (From memory, robots.txt was not useful for this bread.) Alternatively you can set the maximum-number-of-session-objects to something a lot higher and see if you can just live through the bot invasion.

Even better, avoid writing to the session on each request! Your application will be *much* happier if you write to the session only when the human makes a gesture; neither bots nor casually-browsing humans will consume sessions, but only session keys (which are cheap).

Yup - certainly that is a whole lot better if you can arrange for that.


Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to