Apache/2.2.6 (Win32) and multithreading on dual core PC

On executing two very simple ajax POST requests (successivly), the Ap开发者_开发百科ache server seems to always respond in the same order as they were requested, although the second request takes significant less amount of time to process than the first request.

The time it takes the server to process Request1 is 30 seconds. The time it takes the server to process Request2 is 10 seconds.

        var deferred1 = dojo.xhrPost(xhrArgs1);
        var deferred2 = dojo.xhrPost(xhrArgs2); 

I expect Apache to achieve some "parallelization" on my dual core machine, which is obviously not happening.

When I execute each request at the same time in a separate broswer then works ok, the Request2 is returned first.

Facts:

1. httpd.conf has: ThreadsPerChild 50, MaxRequestsPerChild 50
2. PHP version : 5.2.5
3. Apache's access log states that both client requests are received at about the same time, which is as expected.
4. The Php code on the server side is something as simple as sleep(30)/sleep(10)

Any idea about why I don't get the "parallelization" when run from the same browser?

Thanks

---

When your two requests are sent from the same browser, they both share the same session.

When sessions are stored in files (that's the default), there is a locking mecanism that's used, to ensure that two scripts will not use the same session at the same time -- allowing that could result in the session data of the first script being overwriten by the second one.

That's why your second script doesn't start before the first one is finished : it's waiting for the lock (created by the first script) on the session data to be released.

For more informations, take a look at the manual page of session_write_close() -- which might be a solution to your problem : close the session before the sleep() (quoting) :

Session data is usually stored after your script terminated without the need to call session_write_close(), but as session data is locked to prevent concurrent writes only one script may operate on a session at any time.
When using framesets together with sessions you will experience the frames loading one by one due to this locking.
You can reduce the time needed to load all the frames by ending the session as soon as all changes to session variables are done.

---

Browsers typically have a limit of two connections to the same site (although you may increase that limit in some browsers). Some browsers will keep one connection for downloading things like images etc. and another connection for XHR. Which means that your two XHR calls actually goes out in the same connection, one after the other.

Your browser will return immediately after each XHR call because they are async, but internally it may just batch up the requests.

When you run on two different browsers, obviously they each have the two connections, so the two XHR requests go out in different connections. No problem here.

Now it depends on the browser. If the browser allows you to occupy both connections with XHR calls, then you can get up to two requests running simultaneously. Then it will be up to the server which one to do first.

In any rate, if you try with three (or any number >2) XHR requests simultaneously, you will not get more than 2 executed on the server at the same time on modern browsers.