Re: Will PHP ever "grow up" and have threading?

On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop <teusjannette@gmail.com> wrote: > On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: >> # 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... >> > > Well, the multiple answers for a simple request per user as in your > example, seem to be a lot of information to display all on one page, and > present all that information to the user in one request. I would > probably resolve it, IMHO, by using pagers. That is, only part of the Pagers are needed when there's a lot of products to display. But using the filters and show them is different. Look at Amazon (not endorsing it). Click any category. You'll see what I mean by the filters (manufacturers, price range, subcategories, etc) and the display requirements (specials, bestsellers) as I mentioned. They also have other things, like shoppers' discussions, on that page too. Think about how many queries they have to run for all that info to show based on a simple request of a 'category'. Then time the response time. > information is shown to the user at one time, and the user can page > through that information so as to get to other bits of information. If > only part is shown, then the database query becomes so much faster > (hopefully), and PHP still can do all of it in one thread. > > A PHP application, by the nature of PHP, consists of small page requests > to be done at one time, rather than move a lot of information around per > request. Thinking the PHP-way requires some study because, as said, the > information is presented or moved about in small chunks. Desktop > applications, and probably Java web applications (I have no experience > with Java but have read up on it a little) work differently. A > successful PHP application is redesigned from the ground up, rather than > remorphing a Java or other desktop application in PHP without changing > the design principles. > > The key to makign your eCommerce application snappy, is, I think, not > threading, but optimization of database queries. And another key is that > less information presented to the user is usually clearer to the user, > and thus they feel better at the site, and would return sooner to buy > something. The real head-ache here and the difficult part is: How to > design a clear and clean interface for the user. It's not threading. > > Teus. >