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

> * 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 Jessen, Zürich (7.8°C)

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to