Will PHP ever "grow up" and have threading?
in [General]
|
From: Per Jessen on 24 Mar 2010 07:19 Stuart Dallas wrote: >>> 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! >>=20 >> your metaphor is funny but inaccurate. therefore invalid. >=20 > You say it's inaccurate, therefore invalid, but offer no argument as > to why. You want the tools to change to fit the way you want to work,= > rather than adapting to the tools you have available. I stand by my > metaphor, both the humour and the message. FWIW, I thought your metaphor was spot on. Programming is a craft, craftsmen use tools, whether hammers or PHP. >> work to do, are often better implemented with a non-sql solution tha= t >> can use threading and shared memory support. period. >=20 > I completely agree, but I wouldn't go near PHP for a realtime system > in a million years. It's the wrong tool for the job. +1.=20 --=20 Per Jessen, Z=C3=BCrich (13.2=C2=B0C)
From: Lester Caine on 24 Mar 2010 07:21 Peter Lind wrote: >>> 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? >> 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. No you are not off bat. That was the point I was trying to make but not very well. A database connection will normally handle one query at a time, so they have to be serial anyway unles you can create multiple connections. What I was asking Tommy was how he expected the database to handle 10 queries in parallel. Yes ten cores could possibly parallel up the work, but on the whole, the database end is going to serialise a lot of that work, so what is the real gain? -- 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
From: Rene Veerman on 24 Mar 2010 07:27 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.
From: Per Jessen on 24 Mar 2010 07:28 Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per(a)computer.org> wrote:= >> Tommy Pham wrote: >> >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per(a)computer.org> >>> wrote: >>>> Tommy Pham wrote: >>>> >>>>> What I find funny is that one of opponents of PHP threads earlier= >>>>> mentioned that how silly it would be to be using C in a web app. >>>>> Now I hear people mentioning C when they need "productivity" or >>>>> "speed"... >>>>> >>>> >>>> I think I was the one to mention the latter, but as I started out >>>> saying, and as others have said too, it's about the right tool for= >>>> the right job. =C2=A0When choosing a tool, there are a number of f= actors >>>> to consider - developer productivity, available skills, future >>>> maintenance, performance, scalability, portability, parallelism, >>>> performance etcetera. >>>> >>> >>> Funny you should mention all that. =C2=A0Let's say that you're long= er >>> with that company, either by direct employment or contract >>> consultant. You've implemented C because you need 'thread'. =C2=A0N= ow >>> your replacement comes in and has no clue about C even though your >>> replacement is a PHP guru. =C2=A0How much headache is maintenance g= onna >>> be? =C2=A0Scalability? Portability? wow.... >> >> Who was the idi... who hired someone who wasn't suited for the job? >> Tommy, that's a moot argument. =C2=A0You can't fit a square peg in a= round >> hole. >> >> -- >> Per Jessen, Z=C3=BCrich (12.5=C2=B0C) >> >=20 > Suited for the job? You mean introduce more complexity to a problem > that what could be avoided to begin with if PHP has thread support? > hmmm.... Tommy, it's perfectly simple: in my company we hire people with C skills for C programming jobs. We hire people with database skills to be database administrators. We hire people with Linux skills to work on Linux systems. We explicitly do _not_ hire PHP web-programmers to maintain our C code. And vice versa for that matter. No problem, no complexity.=20 --=20 Per Jessen, Z=C3=BCrich (13.4=C2=B0C)
From: Rene Veerman on 24 Mar 2010 07:31
how about having a threaded php server query 10 mysql servers at the same time? 10 results in .1 seconds! and dont start with 'apache will handle that', there are cases where you're best off doing it in php, so you can gather/calculate relations from the data off 10 different servers. On Wed, Mar 24, 2010 at 1:09 PM, 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. > >> -- >> 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> > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > |