On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop <teusjanne...@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.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to