Il giorno martedì 22 ottobre 2013 08:47:48 UTC+2, Tim Richardson ha scritto: > > I'm trying to understand better some of the tips for session optimisation. > I've read the book and explored this group. Any improvements and > corrections would be appreciated. > > * It seems that web2py needs sessions most of them when users are logged > in, if we're following recommendations for signed URLs etc. Also, disabled > sessions means no CRUD according to the book, which presumably also rules > out SQLFORM & family. >
session is needed in any web app to store the state. HTTP is stateless, so sessions are the only way to save the state. Kinda "bogus", but that's the way it works. Sessions are used in forms to prevent CSRF attacks. > > So session.forget is a specific circumstance which is perhaps not so > common. > Every action not altering state should use session.forget > > * if a session is not changed, there is no write penalty, but this is only > relevant whenever session.forget could have been used anyway. > session.forget just forgets about the session. an hash is computed for the current session against the saved state, and if are equals, no write is issued. This is good for all session backends > > * Sessions can be stored on the filesystem (default) or in a database. > the file system imposes locking which can block web2py if a user is doing > several session-altering requests at the same time, most likely because of > ajax use. > database sessions don't lock, which is an advantage. Or the ajax calls > could do session.forget (but I suppose this wouldn't work if the ajax calls > involved signed URLs) > > Hardly an advantage. With file-based sessions if you do session.whatever = session.whatever + 1 you're sure that those operations are atomic (also if slowest). With no locks, if your backend is not speedy and there are lots of session manipulations, you could loose some of those. AFAIK there's no safe way to handle this case, so it's just something that needs to be considered. Also, redis-based sessions have an option to lock the session so they behave correctly like the ones on the filesystem but they're much speedier. File-based and redis-based are the ONLY backends that support safe atomic manipulations of the session object. > On the pure comparison of filesystem vs database, I couldn't come to a > conclusive answer from googling. I imagine an in memory DB will be faster, > but a traditional database is going to end up as cached writes to the > filesystem, I wonder if it can be faster (thinking of SQLSERVER Express > edition, for example) > Did you try reading from a folder with 4000 files in it and asking the db to do the job ? Databases are MUCH more engineered than the filesystem to do such things, and they do better. Of course the db **should** be local (else, you incur in network latencies added for every operation). Of course the gains are greater when there are lots of sessions. > > Also, using the filesystem for sessions can lead to a lot of files in a > given directory which on some filesystems can be a problem (NTFS probably); > web2py includes a session clean script to help with this.The script cleans > up both filesystem and databaes sessions. It's possible to avoid all > session files ending up in the same directory with the separate=True > option, which distributes sessions between folders. > This is true only for Windows-based filesystem. Any other fielsystem can handle with ease that kind of situation without incurring in penalties. separate=True resolve it brilliantly. > > The ajax situation (avoiding locks) seems the biggest advantage to > database sessions, unless you have access to a database which strongly > outperforms the filesystem. > > Read before the concurrency issues with databases sessions -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
