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.
How big of an object can we have in a session without significantly affecting performance?
How big of an object can we store in a cookie?
Are there any other alternatives (other, than, retrieving the data from our DB)?
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.
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.
Related
I understand the textbook definition/concept of localstorage and sessionstorage. I really should write, "I believe I do". My 2 questions are as follows:
Can you provide a clear example of when one (localstorage/session storage) should be used over the other? Basically, what data should
be stored in the localstorage and what data would be stored in the
sessionstorage? I have read a list of country codes could go into the local storage, I ponder if this is really right. What would happen if the country list changes, wouldn't the old list always display and how would one refresh the list upon a change?
What happens when the localstorage and/or sessionstorage hits
the max mb for the browser?
1) The data you store either with LocalStorage or SessionStorage depends on how you want your user to experience your application.
For example, if you have a login page, the username should be something kept with LocalStorage, because probably this same user will log into your app multiple times and not necesseraly wants to save the password in the browser. Having the username in LocalStorage will make it easier for the user to login in the future, even after closing the browser or changing tabs.
But, if you have a system that provides services like booking, searching or maybe comparison between products, storing data with SessionStorage would be better, because although the values set by the user while using your application won't change during this session, they might - and probably will - change in a future use of your application.
In your case specifically, and repeating what was said in the beginning, even with changes in your list of countries, you need to have in mind how your user will interact with your system and what are your needs with the data that is being provided by them.
Don't forget you can always clean the localStorage if you need, and set new values as they appear.
2) There's a really good explanation of how the browser responds to a full memory here
I am trying to store an array in localStorage, It's working for 3000 records, but when records increases to 5-10 thousand code breaks.
Is there is anything so I can store huge data in localStorage.
LocalStorage has size limits that vary depending on the browser. This is to prevent malicious scripts from filling a user's hard drive.
You can test your browser's localStorage limits here: https://arty.name/localstorage.html
The simple answer is, you shouldn't try to store more than 5MB-10MB of data on the client, depending on the browser. Needing to store that much local data is a sign that you probably need to come up with a better solution.
One other possibility for storing data locally is IndexedDB, which has reasonable compatibility across modern browsers. It's a object store which acts a lot like document databases such as MongoDB. You can store objects without converting them to strings and you can query those objects the way you would a database.
Most browsers seem to have a "soft" limit of around 5MB on IndexedDB storage. It's a soft limit because it's not necessarily enforced so you can go store much more if the browser allows it. Your mileage may vary.
Max size for localstorage is 5MB for preventing malicious scripts from filling a user's hard drive. You can go for IndexedDB which is compatible with all modern browsers. The minimum or soft limit is 5MB- the browser will ask for permission to store the data. Maximum storage is the limit of your hardrive disk, as all of the data is stored locally on your machine disk. Basically if you have 20GB free storage than you can use all of the storage for IndexedDB.
i will be using couchbase as the database for my website. i plan for the website to be international so i will probably have datacenters in the usa, europe and australia to keep latency low. i also want to minimise bandwidth between datacenters so i am planning to fire off parallel updates (ajax) to all datacenters whenever the user stores data.
my question is then: if i insert the same data into all three clusters approximately simultaneously, is couchbase smart enough to recognize that this data is identical and therefore does not need replicating between datacenters?
i watched this video and he explained that the cas value is updated when a document is updated and this is used to determine which documents require replication. if the cas value is updated when any document on the cluster is updated then my guess is that the answer is "no" - as it is very likely that i may be sending only some data to all 3 clusters at once, and any data which is sent to only one cluster will get the cas temporarily out of sync for that cluster. however if the cas value is independent per document then the answer may be "yes". maybe there are some options which can be altered to make the cas value independent per document?
Couchbase does not know anything about the body of the documents that you store. From it's perspective, if you write the same document to 3 clusters (all linked bi-directionally with XDCR) it considers them 3 different document mutations to the document with that ID. Couchbase will perform its normal conflict resolution process to choose which of the 3 is the "winner". This will result in "winning" document being transferred to the other two clusters, despite the fact that it may have the exact same content as the "losing" revisions.
Anytime you write to the same document ID in different clusters, you have to be aware that conflict resolution will choose the winning revision. If you're not careful you can overwrite data you didn't mean to.
Typically a different approach is chosen for your use case. For each user, a "home" cluster is chosen, probably based geography. All operations are tied to this cluster for that user. If that cluster is down, you can switch to another cluster. Using this approach you avoid writing to multiple clusters, and you would only change clusters under well defined conditions.
The CAS value is just an opaque identifier of the revision. In your example above, all 3 document writes would end up with different CAS values (which is one of the reasons Couchbase sees them as different, and has to choose a winner)
The conflict resolution process is document in this section of the manual
What is the difference between these concepts, and when should I use one in particular? Does this listing also contain different names for the same general concept?
HTML5 local storage
HTML5 session storage
HTML5 web storage
HTML5 web database
Cookies
HTML5 web storage is a generic umbrella term for the new client-side data storage options.
Local Storage is persistent and scoped to the domain. At the moment two flavors are usually mentioned:
'default': stores things in name/value pairs
Web SQL (aka Web Database): uses an SQL database
Session Storage is non persistent and scoped only to the current window.
Cookies are the old school way of doing all of the above. Stores name/value pairs per domain.
I would like to add more information:
cookies are able to store only 4k of data
whereas localStorage is able to store 5mb of data (Depending on browsers)
Websites will save cookies in browsers and next time browser will send that cookie along with http request to be used server-side. Cookies are meant for being used with the server.
With localStorage, you can store more data, but it is restricted to the client by default.
Session Storage:Session storage is introduced where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.Session is terminated once we close the window.
Local Storage:Local storage is specific to domain and is introduced to span across multiple windows.There is no time limit as in the case of Cookies,and can store upto 5MB storage such as Users MailBox etc....
AFAIC:
Cookies are 4k per cookie, and local storage is 5k per domain.
Cookies existance time limits and sorage is just client-side protocol- and domain-specific bin for data.
Another big thing to consider if your users are located in Europe, is that Cookies are illegal in Europe. https://www.sitepoint.com/europe-website-cookie-privacy-law/
This is how the system works:
I have a catalog of items. An guest user can choose to add an item from the catalog to what we call the inquiry bin. The system keeps track of the items added to the inquiry bin for that particular session. The user can delete items from the bin.
I was wondering what may be the most optimal way of storing these items. Database? Sessions? or Cookies?
Thanks in advance!
Are these inquiry items required to be available to everyone? Or just the particular user that created them?
If they have to be globally available, then you'd have to stick them in the database, with appropriate flag fields to mark them as temporary and which session created them. If it's per user, then it's best to stick them in the session.
Cookies shouldn't be used for major data storage, even if it's just a few items. The less data the client has, the less chance there is to mess around with the innards of your system by feeding bad data via the cookie. If there's just a session ID, then there's essentially no chance of doing anything, other than guessing someone else's session ID.
Client side cookies have best performance, No round trip to web server is a big win for performance. But Cookie has size limitation. see following link about limitation on IE, Other browser should have similar limitation.
http://support.microsoft.com/kb/306070, cookies are used for small amount day storage, like session key.
Session normally means one of server process, if you use on a web farm, Session can not be shared across multiple web server. If you have a single web server, session should be best way to store information on the server side.
For database, it is most flexible solution, but it has performance hit. for high performance website, proper caching is key to go.