Will PHP ever "grow up" and have threading?
in [General]
|
From: Peter Lind on 24 Mar 2010 07:04 On 24 March 2010 11:53, Tommy Pham <tommyhp2(a)gmail.com> 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.  When choosing a tool, there are a number of factors >>>> to consider - developer productivity, available skills, future >>>> maintenance, performance, scalability, portability, parallelism, >>>> performance etcetera. >>>> >>> >>> Funny you should mention all that.  Let's say that you're longer with >>> that company, either by direct employment or contract consultant. >>> You've implemented C because you need 'thread'.  Now your replacement >>> comes in and has no clue about C even though your replacement is a PHP >>> guru.  How much headache is maintenance gonna be?  Scalability? >>> Portability? wow.... >> >> Who was the idi... who hired someone who wasn't suited for the job? >> Tommy, that's a moot argument.  You can't fit a square peg in a round >> hole. >> >> >> >> -- >> Per Jessen, Zürich (12.5°C) >> >> > > 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.... Except, you already introduced complexity into the problem. You see, working with threads is another requirement, whether it be done in PHP or not. Hence, hiring the right guy is independent of whether you have threads in PHP or not - your problem is no less nor no more complex whether you do threading inside or outside PHP. You just assume that adding thread support to PHP will solve the problem, but there's no actual basis to believe this. > -- > 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>
From: Peter Lind on 24 Mar 2010 07:09 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>
From: Rene Veerman on 24 Mar 2010 07:13 yea right.. i really want to keep my code base in 1 language, because that simplifies everything later on imo. you people, who are against the evolotion of php towards cloud computing, would force me to do mixed-languages projects or even rewrite large sections of my codebase if as i want, i keep my codebase in 1 language. maybe now you understand why i'm so pissed off with you know-it-alls. On Wed, Mar 24, 2010 at 1:04 PM, Peter Lind <peter.e.lind(a)gmail.com> wrote: > On 24 March 2010 11:53, Tommy Pham <tommyhp2(a)gmail.com> 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. When choosing a tool, there are a number of factors >>>>> to consider - developer productivity, available skills, future >>>>> maintenance, performance, scalability, portability, parallelism, >>>>> performance etcetera. >>>>> >>>> >>>> Funny you should mention all that. Let's say that you're longer with >>>> that company, either by direct employment or contract consultant. >>>> You've implemented C because you need 'thread'. Now your replacement >>>> comes in and has no clue about C even though your replacement is a PHP >>>> guru. How much headache is maintenance gonna be? Scalability? >>>> Portability? wow.... >>> >>> Who was the idi... who hired someone who wasn't suited for the job? >>> Tommy, that's a moot argument. You can't fit a square peg in a round >>> hole. >>> >>> >>> >>> -- >>> Per Jessen, Zürich (12.5°C) >>> >>> >> >> 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.... > > Except, you already introduced complexity into the problem. You see, > working with threads is another requirement, whether it be done in PHP > or not. Hence, hiring the right guy is independent of whether you have > threads in PHP or not - your problem is no less nor no more complex > whether you do threading inside or outside PHP. You just assume that > adding thread support to PHP will solve the problem, but there's no > actual basis to believe this. > > >> -- >> 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 > >
From: Tommy Pham on 24 Mar 2010 07:14 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' > >> -- >> 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> >
From: Stuart Dallas on 24 Mar 2010 07:15
On 24 Mar 2010, at 10:48, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:39 AM, Stuart Dallas <stuttle(a)gmail.com> wrote: >> >> On 24 Mar 2010, at 10:34, Rene Veerman wrote: >> >>> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham <tommyhp2(a)gmail.com> wrote: >>>> >>>> Funny you should mention all that. Let's say that you're longer with >>>> that company, either by direct employment or contract consultant. >>>> You've implemented C because you need 'thread'. Now your replacement >>>> comes in and has no clue about C even though your replacement is a PHP >>>> guru. How much headache is maintenance gonna be? Scalability? >>>> Portability? wow.... >>>> >>> Thanks for posting this before i had to. >>> >>> +1, +1, +1... >> >> You realise, of course, that the same argument applies to using advanced features of PHP, such as threading should it ever be supported. >> >> -Stuart >> > > Thanks for supporting PHP thread. Thus, it would be a lot easier for > any PHP guru to scale, make it portable, or integrate into other PHP > apps without having to juggle C, Ruby, Python... and whatever else is > out there... I don't believe I did support PHP threading. My point was that using advanced features like threading will limit your employee choices in exactly the same way as having a multi-language environment. -Stuart -- http://stut.net/ |