Session variables

Question

Hy guys. I'm currently working on a project which uses a lot of data stored in session variables. My question is how reliable is this method and if affects the server performance and memory usage. Basicaly, what you would choose between session variables and cookies.

Answer 1

In general, session variables are going to be a lot more secure in the fact that the user cannot edit them locally on his/her machine.

But the real question begs, what are you looking to store? With a bit more information we might be able to give you a better answer as to where you would want to store it :)

Edit:

If you are looking to store user actions, I might recommend building a UserActions table or something along those lines. A table that contains the following:

id INT (generic ID for the record),
timestamp TIMESTAMP/DATETIME (whatever your DB supports),
userid INT (lookup to the user table),
action VARCHAR (what action you want to record),
etc etc (whatever else you want to store)

Then when a user performs an action you want to record, just log it into the table itself, instead of making it travel along with the user in a session/cookie. Really the page itself doesn't need to know what actions the user has performed in the past, unless its a "multi-step wizard" type application. In that case, it probably would be best to pass them as a session variable.

Then you are pushing the storage into a true storage component (being the database) instead of session/cookie as storage.

I mean we still don't really have an idea of exactly what you are developing, but I hope it helps.

Answer 2

You should only use cookies if you need the data-per-user to persist across sessions. That is to say, if they revisit the site outside of the session expiry time and you need the data there.

Otherwise, if the data is only for their current session, then go ahead and put it in $_SESSION. That what it's there for.

Answer 3

Session data is usually stored in files on the server or in database. So how many data is there depends only from your scripts. If you want to store big binary files in the sessions you will probably reach memory limits quickly.

Storing the data in cookies is not always a good idea. This data is visible to the client, he can easy change it and in some cases that just something you mustn't allow.

Answer 4

Session variables do not require submission by the user, they are simply loaded based on a session key. Memory usage depends on the session implementation since there is the cost of retrieving the session from your database (or file system, or memory, or w/e).

Answer 5

Session variables are generally preferable to cookies. That said, they are usually stored in the /tmp directory on your web server, which is world-readable and world-writable. This could be breeding ground for mischief if you don't control your server or you run in a shared environment. Not storing sensitive information in session variables, and not relying on them for stuff that has to work is a good practice.

Answer 6

it's always a tradeoff between keeping information on the server (more memory used) and pushing some of that data off to the client machine (more bandwidth and less secure). As a rule of thumb, I prefer sessions, they are more secure and easy to manage.

Answer 7

When i wrote this question I was thinking at non-sensitive data and with application for logging user activity on website. I think that, for a busy server, with a large number of users, it's better to use cookies instead, it will unload the server resources(memory, hard-drive I/O). In terms of performance, I think that session variables are a better solution. Anyway, I don't know how better it will scale the SV solution.

Answer 8

Using any session variables - at all - means that your application servers need to maintain session state with appropriate synchronisation.

This has an overhead and may negatively affect the scalability of your application, because every server needs to know about (potentially) every session - which is going to mean a lot of cross-server traffic for session data and synchronisation.

While you only have one server, it's ok.

When you get more and more servers geographically distributed, it gets more and more painful.

There is some overhead for the serialisation / unserialisation of the session, but in practice that's not such a problem as it will be relatively fixed per request, hence scalable to high traffic applications.