On Tue, Mar 23, 2010 at 9:49 PM, Larry Garfield <la...@garfieldtech.com> wrote: > On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: >> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop <teusjanne...@gmail.com> > wrote: >> > When looking at PHP as used in enterprise class applications, we can see >> > the following happening. Let imagine that we have a site that gets a >> > 1000 requests per second. That seems to be a good candidate for >> > threading so as to be able to handle the 1000 requests per second. The >> > site runs PHP and Apache. Well, what happens? Each request coming in is >> > handed of to a separate instance of Apache. Thus the site would be able >> > to process many requests simultaneously. It looks as if parallel >> > computing is taking place here, which looks much like threading. Even >> > though PHP itself does not know about threads, and does not need to, I >> > think, the whole process of handling the 1000 requests per second uses >> > parallel computing. There are no performance bottle-necks here. Teus. >> >> # of requests / second can be solved by load balancers/clusters. What >> about the multiple answers for a simple request per user as in my >> example? How you would solve that if not by threading? Amazon has >> about 30 million products and they have filters similar to what I >> mentioned. But when clicking on one of the I18n site at the bottom, >> you're taken to another server, which looks like it uses a different >> DB back end (I could be wrong) and you don't get instant translation >> of the category you're looking at. Their response time is about 3 >> seconds on my 10mbs (not cable) download. As for what programming >> language they use... > > Honestly, how WOULD you solve that with threading? You describe a page that > needs to be generated that has a half-dozen queries against the database > ranging from simple to moderately complex, some of which are site-generic and > some are user-specific. > > How does one solve that with threading? > > 1) Run the site-generic queries once and cache them in memory and let other > threads just use that query result. You can do that without threads. Just > render that part of the page and cache that string to disk, to the database, > or to memcache. If the memecache server is on the same box then it should be > identical to the threading version, performance-wise. (Give or take VM > considerations.) > > 2) Push the user-specific DB queries to separate threads so they can run in > parallel. All that does is push the hard work off onto the DB server, which > is > still running the same number of queries. And PHP can't respond until all of > the queries finish anyway, and the DB server will respond no faster, so you're > really gaining nothing. > > You keep saying "how would you solve this without threads?" as if they're some > magical speed fairy dust. Given the scenario you describe, I don't even see > how threads would buy you anything at all. > > Where threads would be useful is for lots of very small writes on rapidly > changing data. I would never want to write, say, the World of Warcraft > servers without threading and a persistent runtime, but then I wouldn't want > to write them in PHP to begin with. > > Insert that old saying about hammers and nails here. > > --Larry Garfield >
The difference is doing all those queries in serial operations (one after another) versus parallel operations (threads). Instead of waiting, for example, about .05 to .25 sec for each of those queries, the total wait time would be diminishes since each thread would execute a query. Either way, the DB is still doing the required total work. Difference is serial & parallel operations as I iterated several times. Being running in parallel, the web browser will be getting the required info faster since PHP is able to get all the info faster. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
