Will PHP ever "grow up" and have threading?
in [General]
|
From: Robert Cummings on 24 Mar 2010 09:38 Rene Veerman wrote: > I subscribe to this list to share tips on software designs. > > Getting and keeping your respect i'm not even interested in. > > I'm interested in the quality of your tips on problems i post, as tips can > lead faster to products, leads to money, leads to my personal freedom and > options in life. > Respect cannot be used to buy bread and butter. Then you haven't heard about how much value goodwill can add when selling a company :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Robert Cummings on 24 Mar 2010 09:40 Per Jessen wrote: > Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stuttle(a)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
From: Robert Cummings on 24 Mar 2010 09:46 Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine <lester(a)lsces.co.uk> wrote: >> Tommy Pham wrote: >>>> 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? >> Any you have a database that can actually handle that? >> If the database is taking 0.1 seconds per query, and you have 10 queries, >> then getting the data is going to take 1 second to generate. If you want >> some slow query to be started, and come back for the data later, then I >> thought we already had that? But again this is part of the database driver >> anyway. No need to add threading to PHP to get the database connection to >> pull data in the most efficient way. And one does not write the driver in >> PHP? We are using C there already? >> >> -- >> Lester Caine - G8HFL >> ----------------------------- > > Exactly my point. 10 queries taking .1 second each running in serial > is 1 second total. How long would it take to run all those same > queries simultaneously??? What's so difficult about the concept of > serial vs parallel? You seem to think that those 10 queries are happening in isolation. What about the other 100 concurrent users all smacking the db server with 10 queries. The db server is just going to queue them and serially process them as each of it's own processing threads become free. In high concurrency situations threading isn't going to make much difference, in fact it's very likely to decrease performance because now you've added the overhead of thread concurrency handling in PHP when the db server is already handling this issue between the multiple web server requests. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Robert Cummings on 24 Mar 2010 09:51 Rene Veerman wrote: > well i have this very strong gut feeling that at least some php apps > stand to gain so much efficiency per box with threading and shared > memory that they'll save not only their operators a lot of headaches, > but also significant money and energy. that in turn benefits those > outside the company using php. Sometimes when I have a gut feeling, it's indigestion >:D Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: "Bob McConnell" on 24 Mar 2010 10:03
From: larry at garfieldtech dot com > On 3/23/10 6:04 PM, Tommy Pham wrote: >> If throwing hardware at it won't work because of the above mentioned, >> then you would change the design right? How long would that take? >> What if PHP has threads, how long would it take you implement threads >> with minor changes versus and overhaul of application design, coding, >> QA, etc... In summary, you're saying that PHP can not grow/evolve with >> business right? If the company started small and want to use >> available open source solutions, then grow quickly because of their >> unique and quality products and services, and become enterprise level >> with-in a few years, what then? Slow down business growth just so >> that IT can migrate everything to another language? Of all the >> enterprise applications I've seen, they used threads. > > But let's consider what adding threads to PHP would take. That would > mean making PHP a shared-memory architecture, so that different requests > now operated in the same memory space. That means RAM-based > persistence. That means needing to write thread-safe PHP libraries. > (Not the ones in C; I mean the millions of lines of code of PHP already > out there.) > > In short, adding threading support to PHP means PHP is no longer PHP. > It's Java with dollarsigns. It's a complete and total rewrite of the > entire language runtime and environment, and all of the code build atop it. > > The idea that you could "just add threads" to PHP and make it > "enterprise-ready" is so naive it's mind boggling. This pretty much describes the path the Perl community took several years back. While they didn't end up looking like Java, they still actively discourage the use of threads in Perl because nobody has a good handle on which portions of CPAN are actually thread safe. It will likely take them several more years before they find and fix all of the libraries and modules that aren't. Bob McConnell |