On 24 Mar 2010, at 10:38, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas <stuttle@xxxxxxxxx> wrote: >> On 24 Mar 2010, at 10:24, Tommy Pham wrote: >>> I did give a real life example, ie e-commerce site mentioned earlier. >>> 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. 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... >> >> How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario. > > Looking at my example, not just the rows.... There are other features > that require queries to a DB for simple request of a category by a > shopper, instead of running those queries in series, running them in > parallel would yield better response time. I can see that argument, but your comment above only stated issues of database size, and said nothing about running queries in parallel, hence my confusion. Threading would indeed allow you to run the queries in parallel, but at what cost? Personally I would focus on modifying the database structure and introducing caching to minimise the number of queries being executed. Threading would be my last resort if this was my major bottleneck. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
