Every time a PHP script/page that uses sessions is accessed, the session data has to be read. By default, that data is stored on disk as files (you can override that and use a database, for example)

So, basically, for every page load some amount of session data has to be read (and, very likely, written) by PHP. The more data you store in a session, the bigger the session files get.

If you only store a few variables, there is no problem. But if you start storing something like huge arrays, you ll run into problems if your hit rate increases.

--

If you want to "keep code simpler" by storing as much data as possible in a session, you might create more problems instead. For example - should you want to enable API access in the future, you ll possibly have to remove a lot of session data storage/retrieval code and replace it with other methods.

--

Might be unrelated to your problem:

If you want to store some sort of global application state in a session so you don t have to recalculate it, you should use some other caching methods instead of sessions.

There wouldnt be a performance issue. You can store objects and variables, in the session, and it wouldnt make much of a degrade of performance.

Actually, it sounds like you re going to end up saving yourself a bit, performance wise. If these values are simple strings or numbers, or even small arrays or objects, this will be your better option. If you are saving an array with thousands of key => value pairs, however, then it might be better to re-run the query, depending on whether you will need it in given circumstances.

Just remember, that each time you refresh, you will be firing the constructor of each object stored in the session variable. Big objects = heavy payload.

Its not as much of a performance question than it is practicality. Its obvious to me by reading your question that you would not contemplate storing huge arrays in a session.

The issue becomes practical when some action by another user needs to influence values stored in a current session, i.e. an array of bools that shows what a user can and can not access. Having those cached in a session makes revoking permissions impractical.

There s no reason to avoid storing strings and values that are considered to be immutable, or which can easily be re-set by an action of the current user (i.e. changing their user name).