Simultaneous Requests to PHP Script

If the PHP Engine is already in the middle of executing a script on the server what would happen to other simultaneous browser requests to the same script?

• Will the requests be queued?
• Will they be ignored?
• Will each request have its own script instance?
• Any other possibility?

The server, depending on its configuration, can generally serve hundreds of requests at the same time -- if using Apache, the MaxClients configuration option is the one saying :

> The MaxClients directive sets the > limit on the number of simultaneous > requests that will be served.
Any > connection attempts over the > MaxClients limit will normally be > queued, up to a number based on the > ListenBacklog directive.
Once a child > process is freed at the end of a > different request, the connection will > then be serviced.

The fact that two clients request the same page is not a problem.

So :

> Will the requests be queued?

No ; except if :

• there is some lock somewhere -- which can happen, for instance, if the two requests come from the same client, and you are using file-based sessions in PHP : while a script is being executed, the session is "locked", which means the server/client will have to wait until the first request is finished (and the file unlocked) to be able to use the file to open the session for the second user.
• the requests come from the same client AND the same browser; most browsers will queue the requests in this case, even when there is nothing server-side producing this behaviour.
• there are more than MaxClients currently active processes -- see the quote from Apache's manual just before.

> Will they be ignored?

No : this would mean only one user can use a website at the same time ; this would not be quite nice, would it ?

If it was the case, I could not post this answer, if you where hitting F5 at the same moment to see if someone answered !
(Well, SO is not in PHP, but the principles are the same)

> Any other possibility?

Yes ^^

edit after you edited the OP and the comment :

> Will each request have its own script > instance?

There is no such thing as "script instance" : put simply, what's happening where a request to a script is made is :

• the webserver forks another process to handle the request (often, for performance reasons, those forks are made in advance, but this changes nothing)
• the process reads the PHP script from disk
  • several processes can do this at the same time : there is no locking on file reading
  • the file is loaded into memory ; in a distinct memory block for each process
• the PHP file in memory is "compiled" to opcodes -- still in memory
• those opcodes are executed -- still from the block of memory that belongs to the process answering your request

Really, you can have two users sending a request to the same PHP script (or to distinct PHP scripts that all include the same PHP file) ; that's definitly not a problem, or none of the website I ever worked on would work !

If 2 clients calls the server at the same time, the server is most probably able to reply both clients almost simultaneously. The clients here I define them to the browser level.

Meaning to say that on the same machine, if you're using 2 browsers to load the same website/page at the same time, both should be loaded at the same time.

however since we're talking about PHP, you need to take special notes about sessions. If your pages use sessions, the server only serve one page at a time. This is because session file will be locked, until a script exits.

Look at this example. The 2 files are loaded from the same session aka same browser same user.

      scripta.php requested                 scripta.php served
------+---+---------------------------------+------------------------>
          scripta.php started

               scriptb.php requested           scriptb.php started
---------------+-------------------------------+-----------------+--->
                                                                 scriptb.php served.

Notice that scriptb.php is only started after scripta.php is served. this is because when scripta.php started, the session file is locked to other scripts so that scripta.php can write to the session file. When scripta.php completes, the session file is unlocked and thus other scripts are able to use it. Thus scriptb.php will wait until the session file is freed then it will lock the session file and use it.

This process will keep repeating to prevent multiple scripts writing to the same session file causing delays. Thus it is recommended to call session_write_close() when you are no longer using the session, especially on a website using many iframes or AJAX.

Just ran into this myself. Basically you need to call session_write_close() to prevent single user locking. Make sure once you call session_write_close() you don't try and modify any session variables though. Once you call it, treat sessions as read-only from then on.

Unless you are running a very non-standard setup your web server (Apache, IIS, nginx, etc.) will have multiple processes that run PHP separately for each request that comes into the server. Simultaneous requests will be serviced simultaneously.