> > > That's all understood but there are times when that one request from > the visitor requires many sub-requests like connection to DB and > making SOAP calls. I would say it's more than just "there are times", that's how a typical script lives, it imports libraries, queries the database, and talks to other systems. > Sure, it can much faster do you think the response > time for the visitor when the sub requests are done in child threads? > I am not so sure of that. Let's make it a mental exercise really quickly. So let's say we have a website, lets say that we want to query the database and make 2 soap calls at the same time, so for every request we spawn 3 threads to do this. Now, ofcourse for every single request, if they were not concurrent, we would run faster, but what happens when we add a little load to this, say 300 requests per second (and i have built wordpress instances that do 360 on a small ec2 instance). You have say 4 cores @ 1 thread/core, so your web server has 4 threads that are continuously running + 1 for dispatch, and then you have 900 threads that you now have to spawn, process, transfer execution to other threads (context switch in and out, maybe a few time) and terminate per second. The problem is that modern CPUs are not very good at doing this, you are context switching between threads, you are context switching between cores, because your network stack runs on a different core or for any other reason, etc, which is very expensive computationally, on top of which you have to spawn new threads and then kill them. And on a say 4 requests per second system, you may win a few miliseconds on parallelizing your data aggregation, but any real load will see that benefit turn in a negative direction. Curl multi is not necessarily a hack, in context of soap, i can build my soap queries, which is always a serial process anyways, and then use curl multi to run the soap requests in parallel, so there, one part already solved. Database is even easier, since you are usually using a persistent connection, you are already relying on the mysql driver to thread your calls while maintaining a single instance of your connection (eliminating the need for three way hand shakes every time you want to talk to your database, which saves you at least 3 round trips, plus auth (which is 3 more round trips and crypto on both sides)), so even there this problem is already solved for you. And if you are saying that you can run multiple parallel queries for the same PHP process, you really need to fix your database and queries first :) Then shouldn't that be fixed in PHP at the core rather than a hack after? Nope, no need to needlessly complicate PHP especially if there is no need or performance gain in doing it. There are plenty of other areas where PHP can be fixed where it does matter, i mean have a look at a month of PHP bugs if you want to get depressed :) -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray
