On Wed, Oct 31, 2012 at 9:27 AM, Alex Nikitin <niksoft@xxxxxxxxx> wrote: >> >> 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. > How is it solved when you can't monitor and actively maintain each individual requests within curl_multi? Since nothing is shared, you'll need some place store that information (ie memached or DB). With memached, you're already using extra memory and CPU cycles for that. How is that different than what you describe with extra CPU cycles and RAM? Other than using memcached for something that's not intended by design? If you're using DB, that's even worse because now you're relying on extra network traffic and disk IO (read slower performance). What about synchronizing the information between each calls in the sub-threads? If you got it solved with curl_multi, I'd love to see that pseudo code. I'm sure there are many here that would like to see that too. Anyway, this topic of threading in PHP has already been discussed heatedly. I'm sure it's already been submitted as feature request. As with all feature request, it's up to the dev. :) Cheers, Tommy > 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
