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(), "
";'
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...