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? No, not really. So you want to add five languages - if your application is just half-way prepared for multiple languages, that's no big deal (apart from pure translation effort), and a database with only 5 million rows is also no big deal. If that is causing you a performance problem, it is definitely solveable by 1) hardware and 2) database optimization. > * 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. Yes, 3 seconds used to be the maximum response time for an inter-active application. The web might have moved the goal posts a bit :-) > 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 :) Tommy, you neglected to say anything about the number of concurrent users, but if you have e.g. 10.000, you will need enough hardware to run the webserver and the database. A webserver for serving 10.000 concurrent clients I would run on multiple boxes with an LVS load distribution mechanism in front. The 5 million row database is storage-wise not a lot, but running 10.000 concurrent queries will be a significant challenge. MySql cluster comes to mind. Apart from that, apache and mysql will do all the threading you need. /Per -- Per Jessen, Zürich (7.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
