Re: Will PHP ever "grow up" and have threading?

Per Jessen wrote:

Tommy Pham wrote:

On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stuttle@gmail.com> wrote:

Give us a real example of why you think it should be supported and I guarantee we can come up with a way to get you what you want without requiring massive changes to the core of your chosen tool. And if we can't then you may actually convince us that threading would be a valuable feature to have available.

I did give a real life example, ie e-commerce site mentioned earlier.

How many _concurrent_ users do you expect - which order of magnitude: 10,100,1000,10000?

Amazon has the similar features of my example except they have about 30 million products without (i18n). Their I18n is different web server & db & site layout which is completely different from my example.

Understood.

Setting I18n aside, having the same features as my example with about 30 million products to response in about 3 seconds is very good. Even though my example only have about 750,000 products, the translations for the requested languages makes it into 750,000 * 6 = 4,500,000 rows of product descriptions. This is e-commerce site not a data warehouse/mining. What would happen then if the site has over 20,000,000 product skus with similar language translations for the descriptions? 20,000,000 * 6 = ... big number to me...

Thinking out loud - maybe it would make sense to have a separate database instance/machine per language? That would enable to you to start them all on one machine, but shift to another once the load increases. (not dynamically, but with time). If that's not a feasible option, maybe a mysql cluster or a very large database server?

Stick it in the same machine, use replication. Force specific language read queries to specific machines so that the database server cache is primed for that language. This way you're still only maintaining one database. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP