On Wed, 2010-03-24 at 03:38 -0700, 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: > >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stuttle@xxxxxxxxx> wrote: > >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote: > >>> > >>>> unless the actual php development team would like to weigh in on this > >>>> matter of course. > >>>> > >>>> yes, i do consider it that important. > >>>> > >>>> these nay-sayers usually also lobby the dev-team to such extent that > >>>> these features would actually not make it into php. > >>> > >>> Frankly I don't give a crap whether threading is supported in PHP, it does everything I need it to do. If I need threading I use a language that supports it, like Python or C++. > >>> > >>> I love the way you call us nay-sayers like it's supposed to be an insult. I follow the KISS principle to the nth, and as such threading in PHP doesn't make a lot of sense to me. I'm yet to come across a problem I couldn't solve with pure PHP, but when the need arises I have no issue mixing in a little C++, Python, Ruby, or whatever, to meet my performance and scalability goals. I go to the mountain, I don't sit there complaining that the mountain ain't moving in my direction! > >>> > >>> My opinion, and that of most others who've weighed in, is that you're almost certainly looking at the problem from the wrong angle. What you haven't done is explicitly explain why you want threading to be supported. 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. > >> 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. > > > > Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here. > > Yes, it does. As mentioned several times, instead of running the > queries in series, run them in parallel. If each of the queries takes > about .05 to .15 seconds. How long would it take to run them in > serial? How long do you it take to run them in parallel? > > > > > -Stuart > > > > -- > > http://stut.net/ > The database is still a bottleneck. Now instead of processing one query at a time for a PHP script, it's processing 3 because you want them processed in parallel. Now the database is struggling with 3 times the work to complete in the same amount of time. Threading hasn't helped that much here, you've just moved the problem to an area which is already generally considered the bottleneck in most applications. Thanks, Ash http://www.ashleysheridan.co.uk
