6

When users log into our site we retrieve an object from our database that contains various settings that are used throughout the site. In order to reduce server load from going back to our database each time the user interacts with our site, we are trying to think of alternative ways. (We serialize and de-serialize the object, when needed). The object is likely to be <1MB but could vary.

  1. How big of an object can we have in a session without significantly affecting performance?
  2. How big of an object can we store in a cookie?
  3. Are there any other alternatives (other, than, retrieving the data from our DB)?
Kiquenet
  • 14,494
  • 35
  • 148
  • 243
user_78361084
  • 3,538
  • 22
  • 85
  • 147
  • Is your database really so slow that fetching the values from it is that problematic? This should probably really, really be handled on server side – Pekka Jan 03 '12 at 01:13
  • 1
    possible duplicate of [What is the maximum size of a cookie file?](http://stackoverflow.com/questions/3107140/what-is-the-maximum-size-of-a-cookie-file) – Pekka Jan 03 '12 at 01:14
  • and if you really need to do this, see [Local Storage vs Cookies](http://stackoverflow.com/q/3220660) – Pekka Jan 03 '12 at 01:14
  • @Pekka...speed isn't the issue. We wanted to know if there is a better way to do things. – user_78361084 Jan 03 '12 at 01:17
  • possible duplicate of [Local Storage vs Cookies](http://stackoverflow.com/questions/3220660/local-storage-vs-cookies) – Dan Jan 03 '12 at 01:17
  • @user it depends on what exactly you are doing with the settings - you're not saying which part of your app needs to access them and for what. – Pekka Jan 03 '12 at 01:18

2 Answers2

4

The maximum allowed cookie size depends on the client. For example, a MSDN article from 2005 says that the whole cookie may have at least 4096 bytes available (including expiry date etc). The RFC mentioned in the same article contains some more information regarding limitations:

6.3 Implementation Limits

Practical user agent implementations have limits on the number and size of cookies that they can store. In general, user agents' cookie support should have no fixed limits. They should strive to store as many frequently-used cookies as possible. Furthermore, general-use user agents should provide each of the following minimum capabilities individually, although not necessarily simultaneously:

  • at least 300 cookies

  • at least 4096 bytes per cookie (as measured by the size of the characters that comprise the cookie non-terminal in the syntax description of the Set-Cookie header)

  • at least 20 cookies per unique host or domain name

If your session data is not valuable (as in "shouldn't be lost in case of e.g. a reboot"), consider storing it in memcached. This is pretty fast and avoids accessing the DB just to get session data. You might actually want to consider using a mix of both: You could create a small cookie containing the session id and login information. Then a loss of your server-side sessions would not result in users being logged out so the impact would be pretty low.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
3

An alternative to cookies is html5 local storage. It's not supported by old browsers, but if that doesn't matter to you its a good option for user preferences. Keep in mind the following:

1) The default limit is 5MB per domain (I think)
2) If you store settings-type data in local storage, you still need to sync with a server, or else changing browsers will result in user settings not being present in the new browser.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236