Session Variables: How much data is too much?

Question

I've only seen examples of session variables being used to store small amounts of data, like a single user id. I'm wondering if it would be more efficient to instead hold more frequently accessed data in the session variables to avoid querying the database.

For instance, I made a user class that gathers regularly requested data for that user upon construction (their user id, username, email, password and arrays of site specific data) and I hold this instance as a session variable. After the user's initial log in, the database rarely has to be queried to get information about the user because it's already in memory.

Am I actually being more efficient at all, or am I just bogging down the system with memory usage?

Side note - I actually find it easier to grab data from the session instead of having to worry about optimising my queries and stuff, so I really hope I'm not being an idiot.

Answer 1

It all depends on server resources, and on simultaneous users of your website / app.

You can do a rough calculation, by estimating the average session memory each user will need, multiplying it by the average number of simultaneous visitors, and comparing this to the memory you have available for PHP in the server.

This calculation will help you estimate how much is too much in your scenario, in a very rough, but helpful way.

EDIT: by memory I mean RAM and/or disk space, depending on your setup.

Answer 2

Firstly, PHP sessions aren't stored in memory by default, they are stored on disk, so every block/session you write to is going to occupy disk space and not memory (until you use PHP to read the session data).

Yes, you're potentially being more efficient, but not if you want to scale and here's why:

Storing data in sessions

It's perfectly acceptable to store some data in sessions. Theoretically, there is no limit (although I've never tried to break it or even push it, just move to a more efficient solution). You will however, be limited by disk space and PHP memory_limit().

Often, data stored in sessions includes things like:

• Usernames
• Hashes
• Registration dates
• Other variables (user group ids/keys etc)
• Flash messages
• (NOT passwords!)

However, there is a tradeoff. If your traffic (and usage) increases and you're storing a lot of data in $_SESSION, you will very likely start to see problems, both in terms of disk and memory usage.

I don't think there is any issue with what you're suggesting, but beyond the items you've listed and where the examples above overlap, care is required.

If you want to scale (horizontally) and retain disk-based sessions then you have options (sticky sessions or storage area network are a couple) as the disk on one server doesn't store the same sessions as a disk on another server.

Session data location

You can find the location where PHP stores session data by calling: session_save_path()

or on the CLI:

php -r 'echo session_save_path(), "\n";' 

You've not mentioned your OS, but common locations for the session files (across different OS types) are:

/tmp  /var/lib/php5/ /var/lib/php/session c:/wamp/tmp 

Sessions stored on disk usually have filenames that look like this using ls -al:

-rw-------  1 www www      0 2013-07-09 20:12 sess_bdsdjedmvtas5njhr5530b8rq6 

It's worth noting that there are often garbage-collection processes that clean out dead sessions after specific periods. It does vary by OS, but they are usually present with various LAMP-based installs.

Other session storage options/approaches

In your database
Session data is often stored in a DB instead of on local disk and this works well for both micro, small and (depending on how it's done) medium sites with a reasonable level of traffic.

Like any other solution it has it's pro's and con's (like being able to ban/kick out a user by running a query rather than deleting a session file from /tmp)

In memory
for larger, (higher traffic) sites and particularly where the volume of concurrent users is high, memory is quicker to read/write to for very frequently accessed variables or data instead of adding undue load to your DB. It can and should still be written to the DB (See write-through caching), but also be held in memory for efficient access.

One technique of particular merit is memory caching. A widely used example PHP-compatible open-source solution is Memcached, which can be used on one server or many [distributed]. I've seen this used by small firms as well as large and you only have to look at who uses it/contributes...