Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
If I have mutliple, and at the same time, Ajax javascript queries on domain/somefile.php,
where somefile.php must get response from curl request (curl_exec) to domain/somehandler and return them
how is handled parallelism by Apache2?, Is it really slower than if I was doing the Ajax queries directly on domain/somehandler?
thx for explanations
how is handled parallelism by Apache2?– In terms of Apache there is no real problem, unless you have configured it really badly so that it does not have enough processes/threads to handle the load. It’s more about hardware resources and network bandwidth than anything else. The thing to watch out for here is nothing to do with Apache and is actually related to PHP sessions which I will explain below, but first…Is it really slower than if I was doing the Ajax queries directly on domain/somehandler?– Yes, inevitably. This is because you have immediately doubled the number of HTTP requests required to complete the transaction. You have also increased the amount of bandwidth and overall CPU time required. Whether it will be noticably slower and whether it will cause you a problem depends on a thousand factors about exactly what you are doing, how you set up your cURL script, how fast the network link is between the two back end servers, etc, etc, etc…The answer to the question that comes up here again and again relating to concurrency issues with PHP driven applications is related to Sessions. Many sites use sessions to track user data, login status, all sorts of information and there is nothing wrong with that per-se (although they should be avoided if at all possible and are completely incompatible with REST), but it can cause concurrency problems if they are not handled correctly.
The reason for this is that PHP stores the data for a session in a file in the local file system of the server. While a session is open, the file is locked to prevent corruption of the session through concurrent writes. This means that a second request that attempts to utilise the session file will “block” (i.e. wait) until the first has released it’s lock on the session file.
Most of the time people do not notice this, the most common thing I have seen here is people who are attempting to serve a file download through a PHP-based servlet script, and they leave the session file open while the file is sent. This causes the user to be unable to load any pages from the site while they download the file.
The problem can be easily avoided by calling
session_write_close()as soon as you have finished with the session data.…although of course if you’re not using sessions, none of this will affect you anyway.