On Tue, 2005-04-12 at 20:01, Richard Jones wrote:
On Wed, 13 Apr 2005 09:44 am, you wrote:
On Tue, 2005-04-12 at 19:08, Richard Jones wrote:
Is there a viable non-versioned alternative to the filestorage approach? My sessions database grows ridiculously quickly. I'm also fairly sure it's causing problems when my site gets ~5 requests a second (yes, that low)
You could use temporarystorage on the ZEO server if you don't really need your session data to be persistent across ZEO server restarts. This is what Fernando appeared to do in the end.
Having sessions persist across ZEO restarts is a handy thing.
Yup. I've not really needed it so far, but if you need it, you need it...
Also, I never figured how to configure a temp storage in a ZEO server. I started looking once, but either ran into a dead end or got distracted (or both ;)
Probably something like what Fernando had on the client: <zodb_db temporary> mount-point /foo/bar # ZODB cache, in number of objects cache-size 5000 <zeoclient> server localhost:8999 storage temp name zeotemporary var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo1 </zeoclient> </zodb_db> And in the ZEO server's zeo.conf file: %import tempstorage <temporarystorage temp> name sessions </temporarystorage> This resource is useful too: http://longsleep.org/howto/sharesessionwithzeo
There are no well-maintained nonundoing storages that I know of other than temporarystorage. Once upon a time, BerkeleyStorage minimal used to work, but its gone the way of the dinosaurs apparently.
And I distrust anything related to Berkely DB :)
I hear ya! ;-)
I think any sessioning setup that uses a ZEO-backed storage will be more conflict-prone than one that doesn't use ZEO, just because the transaction commit time is typically longer. I'm not sure if this is the problem you mention.
Could be.
It'd be pretty obvious with an inordinate number of conflict errors in the event log. "inordinate" is relative, though, so I'm not sure what to name as a number per minute for your app. You can get a sense of what's normal under contrived load by reading: http://www.plope.com/Members/dunny/conflicts/view
Probably not hard. You could write a "session data manager" implementation that used a relational database. The interface for those things is in Products/Sessions/SessionInterfaces.py
Yeah, I remember poking around that code way back, and it seemed reasonable. Its interactions with transactions are the bits that scare me. Using a standard RDBMS connection would probably solve that though.
Yeah. Probably OK to use a ZRDB connection, those are controlled automatically. - C