On Fri, 02 Feb 2007 14:43:29 +0000 Tiago Macedo <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey, > > I've been using Mongrel for quite some time now but I ran into an issue > that threw me back to lighttpd + fastcgi. > > The application in question was running fine in the production > environment with SQLSessionStore and using a mongrel cluster behind a > load balancer. However, by switching to a MemcacheSessionStore (using > either memcache-client or Ruby-MemCache), users kept being logged out > due to the fact that the processes lost their connection to the memcache > server (they reconnected but the users were already "logged out"). > > The funny thing is that this behaviour didn't occur if only one mongrel > process was running. > > This was using mongrel 0.3.13.4 without fastthread. Switching the > application back to fastcgi solved the problem. > > I was wondering if this was a known issue or if anyone else had this > problem before. Maybe switching to Mongrel 1.0.1 with fastthread solves > this? Do you have log files and exception traces to look at? Without a stack trace showing memcache getting suddenly disconnected it's difficult to figure out what could be wrong. Try with 1.0.1 and fastthread, and then if not file a bug. The problem is there's not much of a reason why fastcgi vs. Mongrel would be the difference. The problem you describe sounds more like a problem of memcache storage levels. Are you able to see how full the memcache is when this is happening? As an aside, I haven't found a compelling reason to put sessions into a memcache. The problem is that if you have large amounts of session data then memcache will frequently "lose sessions" because it rotates them out too frequently. This means that sessions can't be reliably maintained for your set period and there's a good chance you'll piss off customers under heavy loads. Typically people use memcache for their sessions thinking it'll solve a deeper problem: Java Session Bloat Syndrome. Rails works better when you store a minimal amount of information with just basic types into the session, and then use the database for the rest of your storage. What recovering Java programmers do is assume that the session is faster than the database and so they store intermediate objects during process workflows in the session. So, my recommendation is to go with sql sessions and also trim the size of your sessions down. Then run some benchmarks of your pages with sql store and with memcache, but ALSO run a test where you have an insane number of users enter the site and try to maintain their session. This second test will show you the failing of memcache. But do see if you can reproduce the bug in a simplified form under 1.0.1 and fastthread. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
