Per Jessen wrote:
Tommy Pham wrote:
On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stut...@gmail.com>
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:
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
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
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
Application and Templating Framework for PHP
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php