Are There Limits for Session Variables

Are there limits for session variables?

As @Thariama said, there's no limit on the number of variables; also, there's no limit on the amount of data you can store in a session (I've seen sessions tens of MB in size).

As the size of a session gets larger, you'll run into various quirks though: PHP 5 deserializes the whole session into memory at session_start() (using the default session handler - you can make you own solution, of course); with a 20 MB session and 50 concurrent users, your scripts start to be severely limited by disk access speeds (a.k.a. "script startup is slow as molasses" - the sessions alone would be hogging a GB of RAM); in the end, we dedicated a box to keep as many sessions as possible in its RAM, and the frontend boxes accessed them over NFS (although it helped in our case, this may be overkill for you).

Note that for many concurrent users and session storage on disk, the number of session temporary files may cause problems with filesystem limits (e.g. how many files can be in one directory before you run into problems with stat() performance), or other limits (we once found the hard way that a box was configured to only allow 4096 open files at the same time). None of this is really session-specific, but can be triggered by session handling.

Maximum size of a PHP session

You can store as much data as you like within in sessions. All sessions are stored on the server. The only limits you can reach is the maximum memory a script can consume at one time, which by default is 128MB.

(Similar answers: Ideal PHP Session Size? - some useful comments)

Is there any limit on numbers to define sessions

No there is no limit to store the number of variables. Also, there's no limit on the amount of data you can store in a session.

session variables: setting a limit, and how it impacts performance?

It really depends on how the session variables are being handled, i.e if the session variables are eventually being pushed down to the browser as a base64 encoded cookie or set of cookies, then each cookie does have a maximum limit (4kb is the standard, I believe) and there are limits to a maximum number of cookies from a single domain (each browser has its own specification)

However, if you are using the server to manage all state, then the size of the session cookies is really dependent on the memory you have allotted to the web process. Additionally, its not simply about how much can the server handle, but at what point will the server show a degradation in performance given that disk paging will be used as an alternative, when the alloted memory to the process is full.

So, your own suggestion of stress testing the web app is a good one, but given that expect to only see 20 concurrent users and with 8GB on the machine, I wouldn't be worried about this problem.

How many session variables per user is considered too much? - PHP

4 variables per user is nothing, but my suggestion would be on a different level: Focus on what's causing actual bottlenecks in your web site. This issue is probably not relevant right now, and is really easy to switch from in the future if this what slows you down. (And it won't)

I bet you have much more important stuff to work on than worry about another variable, and when you get to that amount of active users, your whole structure will probably change, including servers and solutions. Good luck!

What can be the maximum size for the $_SESSION?

If you have to do this task in stages (and there's a couple of suggestions here to improve the way you do things in a single pass), don't hold the csv file in $_SESSION... that's pointless overhead, because you already have the csv file on disk anyway, and it's just adding a lot of serialization/unserialization overhead to the process as the session data is written.

You're processing the CSV records one at a time, so keep a count of how many you've successfully processed in $_SESSION. If the script times out or barfs, then restart and read how many you've already processed so you know where in the file to restart.

What is the maximum size a session variable can hold?

Try to change requestLengthDiskThreshold to this:

<system.web>
    <httpRuntime executionTimeout="90" 
                 maxRequestLength="20000" 
                 useFullyQualifiedRedirectUrl="false" 
                 requestLengthDiskThreshold="8192"/>
</system.web>

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

---

Related Topics