On Tue, 2005-05-03 at 09:18 -0700, [EMAIL PROTECTED] wrote: I cc'ed Tim Peters on this, perhaps to his chagrin, but he seemed to be interested in this. ;-)
> Thank you for that reference (I have an older dead trees version). Now > I understand that these errors happen, but what I don't understand is > why my users see them ("The requests which experience conflict errors > will be retried automatically by Zope, and the end user should *never* > see one." emphasis in original). Yes. Although that's an intent and not a promise. > Is it simply a matter of too much traffic for the server? This is a > dual 2.3 GHz box, 2G of RAM, 10,000 RPM SCSI drives (two, mirrored as 1 > logical RAID 1 drive), serving 8,000 members (now about 1,000 new > members a month, hence the urgency), 80,000 visits per month, 400,000 > page views per month. Is it time to dip my toe into ZEO? ZEO may help. But may not help here, especially if you put your session data in it. The main reason for read conflict errors are that a particular transaction is "slow" and that other simultaneous transactions come along and modify the data which the slow transaction is trying to read. When the slow transaction figures this out, it bails out. ZEO actually just makes it slower because the data involved in a transaction typically needs to be encoded and decoded for travel across a network. That said, if you have multiple appservers, and you keep your session configuration as the default, each appserver will have its own (non-ZEO)_ session database, and thus will presumably be less prone to conflict due to the disbursement of sessions across multiple machines. But you'll need to keep "session affinity" (every subsequent request from a user with a particular browser id needs to go to the same appserver). I use pound for this. You should try to determine a pattern to the errors your users are seeing (many simultaneous requests to a specific resource). This may be better solved by changing application code to do fewer session accesses or might be solveable via changing sessioning configuration. See http://www.plope.com/Members/dunny/conflicts/view for an idea about what sort of conflict rates to expect under torture situations. Apparently your configuration has managed to torture sessions more than our torture tests, however, because I've personally not managed to have Zope try more than three times to complete a request that encounters a sessioning conflict during this type of testing in the "default" configuration. - C _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )