On 24 Mar 2010, at 19:42, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran@xxxxxxxxxx> wrote: >> On Wednesday 24 March 2010 03:17:56 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 Cache it in something like memcached - I doubt these change very often. >>> * show all products for that category, if any, Cache it in something like memcached, and update that cache when products change. >>> * show all manufacturers, used as filtering, for that category and >>> subcategories Cache it. >>> * show price range filter for that category No need to cache this. >>> * show features & specifications filter for that category Cache it. >>> * show 10 top sellers for that category and related subcategories Generate offline and cache it. >>> * the shopper can then select/deselect any of those filters and >>> ability to sort by manufacturers, prices, user rating, popularity >>> (purchased quantity) Use something like Sphinx to handle searching the data. It's far quicker for doing filtering like this than SQL. >>> * have the ability to switch to another language translation on the fly Doing this would simply change a prefix to the cache keys. >>> * 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. I run a site that does very similar operations to this and response times average around 0.1s with the cache on, and 3-5ss with it off. Oh, and using a stopwatch doesn't take into account network latency or external dependencies. If you want an accurate timings you need to add that functionality into the code. >>> 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? You want an example? Facebook! -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
