-----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? Thanks, Tiago Macedo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFw04RxFuRTtCTMvIRAoXHAJ41fxL1G/TPyIGgCMrWrbx8WX2fqwCeI26Q gdK8xLTsbflH4J4/BFn9Ut4=CsME -----END PGP SIGNATURE-----
On Feb 2, 2007, at 11:26 AM, Zed A. Shaw wrote:> On Fri, 02 Feb 2007 14:43:29 +0000 > Tiago Macedo <tmacedo at student.dei.uc.pt> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> 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?I can vouch for the fact that Mongrel and memcache sessions play just fine together. JibJab has been using them for about 6 months without issue, though they do have a truck load of memcache storage. the amount of data stored in session is also very small, user_id and string or 2 when needed.> As an aside, I haven''t found a compelling reason to put sessions > into a memcache.They are doing it because there is still enough legacy .NET code that''s not using memcache to keep the DB pretty busy, but under normal conditions keeping sessions in the DB is a better choice as it will survive a memcache restart. Michael-
On Fri, 02 Feb 2007 14:43:29 +0000 Tiago Macedo <tmacedo at student.dei.uc.pt> 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.
> 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").Personally, I wouldn''t ever use memcache without a persistent backing store for sessions. It works best when writes always hit memcache and the backing store, and reads check memcache first then fall back to the persistent store. Assuming a normal scenario where you aren''t writing to the session store that often, then your cache hit rate will still be pretty good and your site won''t stop working if memcache fails. Chris
I like this idea, do you have an example or suggestions on how you could implement it easily? On 2/4/07, snacktime <snacktime at gmail.com> wrote:> > 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"). > > Personally, I wouldn''t ever use memcache without a persistent backing > store for sessions. It works best when writes always hit memcache > and the backing store, and reads check memcache first then fall back > to the persistent store. Assuming a normal scenario where you aren''t > writing to the session store that often, then your cache hit rate will > still be pretty good and your site won''t stop working if memcache > fails. > > > Chris > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >
I experienced Tiago''s problem. I store in session a little string telling the application what''s the current language (e.g ''fr'' for french). Users kept being switched back to default language because the session ends prematurely. Playing with memcache expiration time don''t solve the issue. I switch to SQLSessionStore and the problem is gone. Like Tiago, I am in production environment with a bunch of mongrel behind a load balancer (apache2). As my sysadmin skill isn''t that good, I didn''t investigate further and I will stay with SQLSessionStore. Franck y sysadmin skilled On 2/5/07, Joey Geiger <jgeiger at gmail.com> wrote:> > I like this idea, do you have an example or suggestions on how you > could implement it easily? > > > On 2/4/07, snacktime <snacktime at gmail.com> wrote: > > > 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"). > > > > Personally, I wouldn''t ever use memcache without a persistent backing > > store for sessions. It works best when writes always hit memcache > > and the backing store, and reads check memcache first then fall back > > to the persistent store. Assuming a normal scenario where you aren''t > > writing to the session store that often, then your cache hit rate will > > still be pretty good and your site won''t stop working if memcache > > fails. > > > > > > Chris > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070205/7fc5b15b/attachment.html
On 2/4/07, Joey Geiger <jgeiger at gmail.com> wrote:> I like this idea, do you have an example or suggestions on how you > could implement it easily?I would use the active record store as a base and modify it. active_record_store.rb has some sample code on how to do this. Would take a bit of time but doesn''t look that difficult. Chris