Session Variables: How much data is too much?

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/sessionc:/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...

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.

Some of the other answers assume you mean using PHP sessions to cache data. This is a good solution to store ephemeral data that you need to be available from one request to the next.

But I wonder if you mean using MySQL user-defined variables. You can store long strings of data in these variables, and they occupy RAM in the scope of your database thread on the MySQL server. But these user variables do not stay in memory after your session closes. They are not a good way to store data from one request to the next.

The only reason to store large amounts of data in user variables is that you need to use them in subsequent SQL queries during the same db session (which means during the same PHP request), and you're hoping to avoid transferring that string from the db server to your app. Otherwise, you might as well fetch the result and store it in a PHP variable.

Another solution for storing ephemeral data is to use memcached. You can store data directly, or you can use memcached as a backing store for your PHP session.