Is it slower to retrieve a user's cookie and get its value as a PHP variable, than it is to retrieve a session variable?
A:
I would believe it would be about the same except the session would be coming from disk. Also the session is coming from the cookies anyways.
From a security standpoint, do you really want to be storing information on the client-side? Typically, I would not store things with the client.
Daniel A. White
2010-01-03 03:43:06
+2
A:
No. In pure technical terms, it is likely the opposite, as there would be a bit of minor overhead to initializing a session.
Cookie data comes in as part of the HTTP request no matter what, and PHP reads it into $_COOKIE by default. So it's always going to be there. $_SESSION requires you to call session_start() at some point.
However, the performance difference between the two is going to be ridiculously small and not worth worrying about.
zombat
2010-01-03 03:43:35
Sounds good, I will be using sessions regardless but I would like to add more stuff into my cookies but I had a bad experience one time, it was javascript using the cookie though and not PHP, my php page would load, then JS would read a cookie and order the position of some items on a page based on cookie data and it slowed the page down a lot on page loads
jasondavis
2010-01-03 03:53:02
That's just not true. Cookies incur a performance hit outside of the page lifecycle - they're read before the page is processed and written when the response is sent. Session variables incur a hit within the server, having no affect on the request/response parts of the cycle, only upon page rendering time. These are apples and oranges.
David Lively
2010-01-18 17:54:39
+2
A:
A session is by default already backed by a cookie with the name phpsessionid (so that the server is able to identify the client and associate it with one of the sessions in server's memory), so your concern actually makes no sense.
It's only easier to make use of $_SESSION instead of reinventing it with a "custom cookie".
BalusC
2010-01-03 03:46:09
session variable in PHP is not fancy abstraction over plain cookies.
lubos hasko
2010-01-03 03:49:25
That solely depends on the purpose of the "custom cookie". His question, however, isn't formulated that way.
BalusC
2010-01-03 03:51:25
+7
A:
In general, you should not worry about the retrieval speed of a session variable or a cookie.
You should however be aware of the differences between them:
Sessions are stored on the server, which means clients do not have access to the information you store about them. Session data, being stored on your server, does not need to be transmitted in full with each page; clients just need to send an ID and the data is loaded from the server.
On the other hand, Cookies are stored on the client. They can be made durable for a long time and would allow you to work more smoothly when you have a cluster of web servers. However unlike Sessions, data stored in Cookies is transmitted in full with each page request.
Daniel Vassallo
2010-01-03 03:47:28
+1 for “data stored in Cookies is transmitted in full with each page request”... and potentially every image, script and stylesheet request too. This is why you want to keep the number of size of cookies you set to a minimum. If you have a large amount of data, store it server-side and key it off a much smaller ID cookie.
bobince
2010-01-03 04:07:26
Why not you just store an ID in the cookie and retrieve the relevant information for that ID from the database? Cookies in the first place are majorly used not for performance reasons, but for their persistency and server independency.
Nirmal
2010-01-03 09:13:45
A:
In some browser it is not possible to store cookie ,to avoid this problem you can pass a SID (session id) or some hidden,filled,textbox values , instead of cookies, by using GET and POST methods.
amir beygi
2010-01-03 08:31:02
That's going to be very very cumbersome and tedious job to do. What happens if the user wants to come back to the domain? And what happens if the user modifies the URL in case of GET request?
Nirmal
2010-01-03 09:17:04
If the user changes the sid in the url , it would be like changing the cookie(that is possible)
amir beygi
2010-01-03 10:22:01
A:
While roughly equivalent from the perspective of manipulation in code, cookies and session variables are very different things.
Cookies are stored in the browser, and transmitted to the web server with each request. If you store large cookies or lots of small ones in the user's browser, you increase the size of each request/response, which makes each hit more expensive (bandwidth) and slower (time). Also, anything stored in a cookie is visible to the client, so avoid storing anything sensitive there.
Session variables, on the other hand, have their own sets of issues. Since they're stored within the server context, they don't propagate between clustered servers. If the server/service resets or the user's session times out, whatever was stored in the session[] collection is lost. Storing large data in a session variable incurs a performance penalty on the server, which can get really bad if you have a lot of traffic. Session variables require a cookie, which the server uses to identify a user's session. It is feasible for a user to alter their cookie to gain access to data stored in other sessions, though this would be pretty freakin' difficult to do with any kind of value since session IDs are randomized, nonsensical pseudo IDs.
Ultimately, all of this crap should be stored in a database anyway. Sessions are a lazy convenience that should be avoided when developing any robust application. Cookies should be used minimally - typically, I store a guid in a cookie which helps me identify a user (similiar to a sessionID cookie, but application-specific), but everything else goes in the database. This gives you server-agnostic data availability, secure storage, data lifetime set by your app instead of the server config, good query and report ability, etc.
Databases are easy when done right. There are many, many reasons that any state information you collect should be stored in a database, and no good reason not to.
David Lively
2010-01-18 17:50:23