> 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

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

Reply via email to