CODEWITHSUNDEEP
htmlsessioncookies
user_78361084
user_78361084

Reputation: 3928

How big of a cookie can/should I create?

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)?

Upvotes: 6

Views: 3972

Answers (2)

hvgotcodes
hvgotcodes

Reputation: 120258

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.

Upvotes: 3

ThiefMaster
ThiefMaster

Reputation: 318568

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.

Upvotes: 4

Related Questions