You could experiment with memory_get_usage() to monitor how memory is being handled in response to certain declarations. For instance, I worked up the following:

echo memory_get_usage(); // 84944
$var = "foo";
echo memory_get_usage(); // 85072
unset($var);
echo memory_get_usage(); // 85096

Comparing to storing in $_SESSION:

echo memory_get_usage(); // 85416
$_SESSION[ var ] = "foo";
echo memory_get_usage(); // 85568
unset($_SESSION[ var ]);
echo memory_get_usage(); // 85584

If the variable just a $variable, then yes, the 100 variables will be multiplied by 100 users. Even when we re counting session storage, during the time the request is running, these variables are also stored in memory, in $_SESSION.

However, I doubt you really need to be concerned, the amount of space taken up by a few variables is rarely an issue; many large PHP applications will load thousands of variables for each request, and then clean them out at the end of the request. The PHP footprint is not terribly large, and memory control is more up to your deployment method of PHP (mod_php vs CGI/FastCGI) than anything to do with any applications you run.

To be more specific, whether your machine can handle 100 simultaneous requests is mostly unrelated to your PHP script, as the PHP interpreter generally takes up a lot more memory than the scripts it runs. If, however, each of those scripts is loading a very large file into a string (or a large database result set, or the like) then it is possible that your script s memory use is a concern. For the general case however, it s something that comes down to the webserver s setup.

Only code pages are implicitly shared between processes. Data is separate for processes and combined for threads unless this is explicitly overridden via e.g. SysV shared memory.