Chris/List, further to my last post ( http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/31062F4798B21631 )about experiencing problems with CST under 2.3.3, I now have a bit more information. Unfortunately, I don't anticipate it will be very helpful in diagnosing the problem :-(. So, the new setup is: - winNT4 - zope250 - DCO2 - built-in session machinery from zope250 (i.e. not CST anymore) - using the same site (exported from zope233 then imported to 250) as before The site is under considerably less load now, so errors are few an far between, but they *are* happening (I'm fairly certain this is not a load issue now). Here's a sample traceback... Traceback (innermost last): File C:\PROGRA~1\zope250\lib\python\ZPublisher\Publish.py, line 98, in publish File C:\PROGRA~1\zope250\lib\python\ZPublisher\mapply.py, line 88, in mapply (Object: details) File C:\PROGRA~1\zope250\lib\python\ZPublisher\Publish.py, line 39, in call_object (Object: details) File C:\PROGRA~1\zope250\lib\python\OFS\DTMLDocument.py, line 127, in __call__ (Object: details) File C:\PROGRA~1\zope250\lib\python\DocumentTemplate\DT_String.py, line 473, in __call__ (Object: details) File C:\PROGRA~1\zope250\lib\python\DocumentTemplate\DT_Util.py, line 159, in eval (Object: sdm.getSessionData().has_key('your_results')) (Info: sdm) File <string>, line 2, in f File C:\PROGRA~1\zope250\lib\python\Products\Sessions\SessionDataManager.py, line 91, in getSessionData (Object: sdm) File C:\PROGRA~1\zope250\lib\python\Products\Sessions\SessionDataManager.py, line 174, in _getSessionDataObject (Object: sdm) File C:\PROGRA~1\zope250\lib\python\Products\Transience\Transience.py, line 133, in new_or_existing (Object: session_data) File C:\PROGRA~1\zope250\lib\python\Products\Transience\Transience.py, line 159, in new (Object: session_data) KeyError: duplicate key 30923427A0M9AWdSVF0 Although obviously different than before (due to the different session machinery), it sounds like a pretty similar issue (i.e. the session machinery is getting a bit mixed up with session keys - although before it seemed that it was losing keys, it now seems like it's duplicating them). As for your other suggestions last time, I'm afraid we haven't got round to using 'ab' against the site. Neither have we tried "Sessions.stresstests.stresstestMultiThread.py", although now we are using the 250 session stuff, this should be fairly easy right? I'll look into this next, but I won't have much spare time for the next 2 weeks. Other interesting facts are: We appear to have a memory leak: This was present under zope233 as well, but we didn't spot it at the time. Do you or anyone else have a good suggestion for tracking this problem down? I am next to clueless in ways to do this :-(. Could it possibly be my web code? Could it be related to the flakey sessioning? <I presume the answer to both is 'Yes', but it's difficult to say either way> We see periodic zodb conflicts: I can't tell you much more than that until they happen again (we lost that particular log). The confusing thing is, I don't think there are any parts of the site that actually allow people to modify objects in the zodb. People can update an oracle database, and obviously they can query it as well, but that's about it. So what is trying to write to the zodb? The only thing I can think of is the session machinery, which I why I mention it. Sorry to be the bearer of bad tidings. cheers tim