Having a lot of data in cookies is bad for performance, because the cookie gets sent across the wire with every request ([1]http://www.yuiblog.com/blog/2007/03/01/performance-research-part-3/ ). The impact is worse if you have a ton of data ending up in your cookie, as as seems to be happening. So memcache (or any other fast server-side storage) should be a clear win from the performance perspective.
On a side note, are we using memcache for sessions now? I would have thought that memcache's lack of guarantees about what data it's going to throw out would make it an unattractive choice for session storage. On Sun, Apr 6, 2014, at 06:31 PM, Benjamin Wanicur wrote: Chris, Yes, I realized my assumptions about the cookie / session storage were outdated in terms of Rails 4. See my last response to “The Dude”. I did not realize Rails 4 had gone with the full cookie session storage. I guess I’m just an Rails 3 old timer when it comes to session storage, gash dangit. Just kidding, but sorry to all for answering ignorantly. Dude, As for for the performance tradeoff between cookie-based versus something like memcache for your session… I do not have any concrete answers. I’m sure the cookie-based storage is faster as there is no need for “querying” memcache. I’m guessing that if your memcache server is set up correctly, it is a negligible loss in performance. Ben W On April 6, 2014 at 6:16:53 PM, Chris McCann ([2][email protected]) wrote: Ben, If the session store is set to ActionDispatch::Session::CookieStore then everything stored in the session will be stored in the user's browser cookie. So in effect, the 4k cookie limit is the limit on how much you can store in the session, which is why it's not recommended to store much more than an ID or two in the cookie-based session. My question was in regard to what else he might be storing in the session in addition to whatever Devise is putting in there. Still, it's odd to me that Devise alone could be blowing up the session cookie for two logins. Here's what I would do, just to get a better bead on this. Put a raise session.inspect call in one of your controllers at a point that will execute after you've logged in as a regular user and an admin. This will trigger a runtime exception and allow you to see what Rails says you have stored in session. Post that here. CM On Sunday, April 6, 2014 12:50:35 PM UTC-7, Benjamin Wanicur wrote: Hi Dude and Chris Chris, it’s worth noting that he is exceed his 4k cookie storage limit, not session limit. I second Chris’ question about "what are you storing in the cookie ?” . Without seeing any code, I’m just guessing, but typically you should only store light weight stuff in the cookie. It’s been awhile since I’ve set up Devise, but in general, you should usually just store unique keys that point to values in the session (or other data store) in your cookie. You should also not store anything sensitive in the cookie. I’ve used Devise with multiple users logged in at the same time (admin and reg user) without problems. Maybe you can show us some code ? Apologies in advance if I am misinterpreting your problem. Cheers Ben W On April 6, 2014 at 11:53:41 AM, Abiding Dude ([3][email protected]) wrote: Hi Chris, a number of Stack Overflow answers to Devise ActionDispatch::Cookies::CookieOverflow mentioned the 4k cookie limit problem with the recommended solution being to use a different store. [4]https://coderwall.com/p/dqdyig At this point in testing I'm not storing anything else in session, the 4k limit seems to be exceeded when I login as a customer AND as admin using Devise. Logging into just 1 works perfectly fine, its the second login adding to the cookie that appears to cause the overflow. I'm not using memcache at the moment and felt hitting the db may not be ideal for performance. Once you login with Devise with session stored in db, will it hit the db every time to verify access to a page or could that be handled by having just the user_id in a cookie session. So on login store session info in db, set only the user_id in cookie session and use only that value to enable access to various pages or sections. I wired up auth from one of the wire it yourself railscasts, it works fine but not ideal for forgot password. Devise is powerful and pretty user friendly cept for this cookie overflow issue. I checked Sorcery v briefly yesterday but per your suggestion will revisit in more detail this afternoon. Thanks for the tip not to wire it myself. On Sunday, April 6, 2014 9:10:25 AM UTC-7, Chris McCann wrote: There are other options for authentication in Rails. Depending on your needs, Sorcery is a fairly well-written, lighter weight alternative to Devise: [5]https://github.com/NoamB/sorcery I, along with most other experienced Rails developers here, would strongly discourage writing your own authentication solution. There's no need to reinvent something so critical to an app as authentication when there is battle-tested, community-vetted code already available. The bigger question here, though, is why you're getting the cookie overflow error. Does this Stack Overflow post describe your situation? [6]http://stackoverflow.com/questions/7117200/devise-for- twitter-cookie-overflow-error You should take a close look at what you're storing in the cookie-based session, in addition to what Devise is stashing there. If you find for some reason that you have to put more than 4k of data in the session then a database or memcached session store would certainly allow that. Is there a particular reason why neither of these session stores is an option? Cheers, Chris On Sunday, April 6, 2014 1:25:49 AM UTC-7, Abiding Dude wrote: Am building an ecommerce app and finding a problem with overflow on cookies if I have 2 models with Devise. The suggested solution via stack overflow is to use the db to get around this issue which I'd rather not, or memcache. Is there any other solution recommended for authentication? Or maybe write my own? There's customer login, affiliate login and admin login. Neither will login on same browser at same time, but the overflow issue seems to be common in exceeding the 4k limit once you do 2 logins using cookies with Devise. Other than that its been a very user friendly and quite powerful gem. Thanks for any pointers. -- -- SD Ruby mailing list [7][email protected] [8]http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [9][email protected]. For more options, visit [10]https://groups.google.com/d/optout. -- -- SD Ruby mailing list [email protected] [11]http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [12][email protected]. For more options, visit [13]https://groups.google.com/d/optout. -- -- SD Ruby mailing list [email protected] [14]http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [15][email protected]. For more options, visit [16]https://groups.google.com/d/optout. References 1. http://www.yuiblog.com/blog/2007/03/01/performance-research-part-3/ 2. mailto:[email protected] 3. mailto:[email protected] 4. https://coderwall.com/p/dqdyig 5. https://github.com/NoamB/sorcery 6. http://stackoverflow.com/questions/7117200/devise-for-twitter-cookie-overflow-error 7. mailto:[email protected] 8. http://groups.google.com/group/sdruby 9. mailto:[email protected] 10. https://groups.google.com/d/optout 11. http://groups.google.com/group/sdruby 12. mailto:[email protected] 13. https://groups.google.com/d/optout 14. http://groups.google.com/group/sdruby 15. mailto:[email protected] 16. https://groups.google.com/d/optout -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
