Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 24 Mar 2010 07:52 again; i have neither the expertise ready, nor the time nor the money atm, to implement it myself. i'm hoping the php-dev team will agree with me that scalability of php driven apps should be put on the agenda. threading and shared memory are only a part of that discussion.. i'm opening a new thread to discuss this wider issue. On Wed, Mar 24, 2010 at 1:44 PM, Daniel Egeberg <degeberg(a)php.net> wrote: > On Wed, Mar 24, 2010 at 12:27, Rene Veerman <rene7705(a)gmail.com> wrote: >> On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas >>> I find it curious and amusing that you think the lack of threading support means PHP is somehow living in the dark ages. But yeah, complaining that the FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, that's the way to go. >>> >> >> a) i'm not the only 1 who wants that feature, or would appreciate it >> when it's made available. >> >> b) to me it's a matter of keeping php attuned with the market trends. >> this thread forces me to reconsider my choice of language, because i >> do code to maybe get as big as facebook one day. >> it really really helps to have my codebase in a simple language like >> php, and yet be able to build blackboxes in that language that do >> threading and use shared memory.. >> imo, it saves significant time (money) and headaches (risk) when >> growing from 1 server to thousands of servers. > > If you believe you have the chance of becoming as big as Facebook and > that you would save loads of money by having PHP support > multi-threading, what's preventing you from hiring people to add that > to PHP? You can complain all you want, but even with the most > compelling reasons in the world it will not be done if there is not > enough manpower to do it. > > I'm not even sure why you are complaining about this on the general > list. Why don't you write an RFC and send it to internals for > discussion? I'm sure someone would be happy to give you write access > to the rfc namespace on the wiki if you sign up for an account there. > > Seeing as it's apparently so crucial to the operation of your > business, I don't think it's unreasonable that you commit some > resources to it. I don't think anyone is *against* that PHP supports > multi-threading. I think people are against having multi-threading if > it will stall other development in the PHP core. It's not like you can > implement it just like that. There is just a limit on how much that > can be done with the resources that are available. > > -- > Daniel Egeberg >
From: Peter Lind on 24 Mar 2010 08:01 On 24 March 2010 12:14, Tommy Pham <tommyhp2(a)gmail.com> wrote: > On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind <peter.e.lind(a)gmail.com> wrote: >> On 24 March 2010 12:04, Tommy Pham <tommyhp2(a)gmail.com> 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 >>>> ----------------------------- >>>> Contact - http://lsces.co.uk/wiki/?page=contact >>>> L.S.Caine Electronic Services - http://lsces.co.uk >>>> EnquirySolve - http://enquirysolve.com/ >>>> Model Engineers Digital Workshop - http://medw.co.uk// >>>> Firebird - http://www.firebirdsql.org/index.php >>>> >>>> -- >>>> PHP General Mailing List (http://www.php.net/) >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> >>> 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? >> >> Hmm, just wondering, but how long do you think it will take your >> high-traffic site to buckle under the load of the database queries you >> want to execute when now you want all of them to execute at the same >> time? Going with the "10 queries of .1 second each" ... how far do you >> think you can scale that before you overload your database server? I'm >> just wondering here, I could be completely off the bat. > > IIRC, one of opponents of PHP thread mention load balancer/cluster or > another opponent mention 'throw money into the hardware problem' Yes. If you can accept that solution for this problem, why not for the other problem? Please keep in mind that I'm not for or against threads in PHP. I think they can solve some problems and I think they'll create a host of others - currently I have no idea if the benefits would outweigh the costs. I just have a huge problem understanding why alternative solutions to problems are thrown out with "No! That won't work" when they haven't been shown to be problematic. So far, we've seen no examples of situations where PHP would be the best choice of language and would need threads to solve the problem at hand. Assuming that you have a right to use a threaded version of PHP amounts to walking into your favourite tool-store and demanding that you get a hammer that doubles as a phone. And when none are available, you start yelling at other customers for suggesting the use of a phone and hammer in combination. >> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> >> >> -- >> <hype> >> WWW: http://plphp.dk / http://plind.dk >> LinkedIn: http://www.linkedin.com/in/plind >> Flickr: http://www.flickr.com/photos/fake51 >> BeWelcome: Fake51 >> Couchsurfing: Fake51 >> </hype> >> > -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype>
From: Robert Cummings on 24 Mar 2010 09:06 Per Jessen wrote: > Rene Veerman wrote: > >> stop bashing the people who DO have a use for threading and other >> advanced concepts eh. > > I'm not bashing anyone. > >> just because you don't have a use for it, it shouldn't be included?! >> kinda arrogant. > > Feel free to think so - I never said I don't have a use for it > (threading), I just said thread-support doesn't belong in PHP. This is a more interesting statement since this thread started with "douche-bag". I disagree with your assertion that it doesn't belong in PHP, I think threading has its merits, but the kinds of problems thrown at this thread so far don't seem particularly solved by threading. 500 requests each with 10 threads hitting the database is 5000 queries. Threading isn't going to make a whole hell of a lot of difference versus 10 serial queries sent by the same 500 web server requests-- multi core system or otherwise. Facebook and other popular sites get along well with PHP. Note that Facebook created a compiler for PHP, they didn't add support for threading. This suggests that threading is not the golden hammer being sought in this thread. However, threading certainly would be great for doing more desktoppy stuff :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Robert Cummings on 24 Mar 2010 09:11 Rene Veerman wrote: > popular : facebook youtube etc I doubt very much you're popular like facebook. Nothing is as popular as facebook. http://www.fastcompany.com/1584920/facebook-now-more-popular-than-google-let-the-ad-wars-begin Unless you're actually a facebook developer... which I doubt. > and you're still trying to impose a toolset on me. i think it's not > strange to ask a programming language support basic hardware > architecture features as they evolve into mainstream. No, you've imposed the toolset and now you want to change the set. Nothing wrong with wanting a new tool in your bag, but you're current arguments aren't really passing muster. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Robert Cummings on 24 Mar 2010 09:13
Rene Veerman wrote: > talk to me about this some other time. > > atm i'm having an argument with per and his kind about their very very > annoying behaviour of determining my toolset for me. > keeping a thread on topic is also ettiquette from the mailinglist rules eh? > > you might wanna consider just how much it pisses me off to have strangers > determining my toolset and/or lifestyle for me. > that's why i got rude. no other reason. Umm... you or your boss/client chose PHP. That means one of those two determined your toolset. Maybe next time you might want to pony up for a requirements analysis to determine if the toolset is right for the job. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP |