my entire server hangs!
While the first script is running, if i load another script, it will just say “Waiting for server.name…” and only execute after the first script is done.
I tried googling, and one of the solutions is to increase my MAXCLIENTS in my httpd.conf.
However,
a) There is no such line in my HTTPD.conf
b) adding such a line prevents my apache from starting up.
While the 10 sec script is running, loading a STATIC file (for example, a small jpg) is fine. However, running another small PHP script (hello-world.php), will only execute once the first script is done…
Browsers do have some max connections settings. I would be suprised if one of them was set to only a single connection though. In FF you can check this by typing about:config into the address bar. Look at the network.http* settings.
I would imagine that theres probably some apache setting, or module that might try to limit connections per client as well.
Mark, crmalibu, thanks so much for your responses. I realize that this is a browser caused problem.
Yes, I checked out FF and as per crmalibu’s reply, there are a multitude of network.httpmaxconnections type settings, typically in the range of 8-15.
This would explain how FF allows me to run simultaenously:
single instance of the script
multiple other static image requests
However, FF still only allows only ONE instance of a PHP script to be loaded at anytime.
Should it not be 8? (assuming max connections per server is 8)?
In order to solve the concurrency issue, php obtains an exclusive lock on the session file(one file per session id) when you call session_start() and doesn’t release the lock until session_write_close() is called. php automatically calls session_write_close() when your script exits if you haven’t already closed any open session.
since session_start() needs to obtain an exclusive lock before doing any reading or writing, it will just sit there and wait*, blocking further script execution until it gets its lock.
So it’s not really anything specific to session.auto_start, because you will experience the same behavior when manually calling session_start(). auto_start just calls session_start() for you.
*I’ve come across systems where php won’t wait for a lock, instead it just immediately fails and loads an empty session array, which of course it will try to save when session_write_close() gets called, which generally means you lose all your session vars. I don’t know if this was a bug that was fixed, it was quite a while ago.
That’s what I thought would be the cause. It makes sense though – you don’t want two scripts making changes to a session at the same time or else you could end up with the bug you described happening.
That is very interesting behaviour. I wasn’t aware of that, thanks for sharing crmalibu. I’ve always been a fan of using file-based sessions just for simplicity, but this seems like it would be a good reason to move session handling to a database for a read-heavy site that stores a lot of session information.
Usually, you wan’t/need this behavior. Otherwise you may end up with corrupted/stale/out of state session data. If you need concurrent reads for performance(doubtful, how often do you need thier browser to load two pages which both use sessions simultaneously?) then you can just take care to call session_write_close() manually in those specific scripts as soon as you’re done modifying session variables if there’s still quite a bit more script execution time to be done.
You’re free to start>save, restart>save the same session multiple times per script.
session_start();
// do stuff, read vars etc...
session_write_close();
// do something that takes a long time....
session_start();
// now update sesson vars with the result
This way you aren’t locking out other scripts from reading the session data while you perform some lengthy task(for example, any kind of network IO can potentially take a long time, same with downloads etc…). Of course, if the other scripts that could be running at this moment might need the combined result of the first and second update to the variables though, you wouldn’t want to do this, you need them to wait. An example could be if you serve large downloads from a php script, and use session variables to control access to these files. If it takes 5 minutes to download the file, and you don’t close the session before you start dumping the data to them, then they won’t be able load any other pages which use sessions for 5 minutes, the pages will just hang. So you would start the session>read the vars to authenticate them>close the session>output data. Then if you need to update a session var again, for example to keep track of thier filenames downloaded this visit, you can just start the session again after the data has finished being output so you can update vars.
You almost always wan’t this locking behavior. Without it, or if you program without considering the implications of not having it, you’re more likely to introduce those kinda subtle bugs that your users complain about that you just can’t ever seem to reproduce.
