On Tue, Mar 23, 2010 at 6:57 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote: > >> Let's go back to my 1st e-commerce example. The manufacturers list is >> about 3,700. The categories is about about 2,400. The products list >> is right now at 500,000 and expected to be around 750,000. The site >> is only in English. The store owner wants to expand and be I18n: >> Chinese, French, German, Korean, Spanish. You see how big and complex >> that database gets? The store owners want to have this happens when a >> customer clicks on a category: >> >> * show all subcategories for that category, if any >> * show all products for that category, if any, >> * show all manufacturers, used as filtering, for that category and >> subcategories >> * show price range filter for that category >> * show features & specifications filter for that category >> * show 10 top sellers for that category and related subcategories >> * the shopper can then select/deselect any of those filters and >> ability to sort by manufacturers, prices, user rating, popularity >> (purchased quantity) >> * have the ability to switch to another language translation on the fly >> * from the moment the shopper click on a link, the response time (when >> web browser saids "Done" in the status bar) is 5 seconds or less. >> Preferably 2-3 seconds. Will be using stopwatch for the timer. >> >> Now show me a website that meets those requirements and uses PHP, I'll >> be glad to support your argument about PHP w/o threads :) BTW, this >> is not even enterprise requirement. I may have another possible >> project where # products is over 10 million easily. With similar >> requirements when the user click on category. Do you think this site, >> which currently isn't, can run on PHP? > > That strikes me as a pretty stiff target, no matter how you look at it. > You effectively want 6 major queries at once, plus response in under 3 > seconds on a 750000 row product table. I'm not sure I could produce that > kind of performance in C at the command line. (I'm sure some smart guy > on the list will say he can do it in 2 seconds flat over a 10 Base 2 > network with teletypes and acoustic modems.) > > Which brings me to my question. Why do people expect console-level > performance from a web browser? It's kind of rhetorical, since people > want everything they can get and more all the time. But if performance > came up as a customer question for me, I'd make it clear that they're > not going to get console-level performance from a web browser, unless > they want to spend a whole lot more money. Neither the world wide web > nor browser software were ever designed primarily with speed in mind. > The internet is not your local 64-bit 10 gigabyte memory loaded machine. > > Paul > > -- > Paul M. Foster > The response time, max 5 seconds, will be tested on local gigabit LAN to ensure the adequate response (optimized DB & code & proper hardware) without worrying about users' connection limit and site's upload bandwidth limit (which can easily rectify). Then thereafter will be doing stress test of about 10 concurrent users. As for the major queries, that's where threads come in, IMO, because those queries depend on 1 primary parameter (category ID) and 1 secondary parameter (language ID). This particular site starts with 500 products about 15 categories, without many of those mentioned filters, later grew to its current state. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
