Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 25 Mar 2010 01:54 On Thu, Mar 25, 2010 at 6:13 AM, Hans Åhlin <ahlin.hans(a)kronan-net.com> wrote: >I admit that if there were native support for threading I > would use it. But I don´t want the support for threading if it > slowdown the performance. hmm i bet you can use any feature of php to slow things down.. i think what's been proven by the pro-camp by now is that at least some application designs would benefit from threading and shared memory. imo there's no way to tell up front if threading will be detrimental or benefitial to all projects built with php. itsa case-by-case thing... aint it?
From: Rene Veerman on 25 Mar 2010 02:11 On Wed, Mar 24, 2010 at 11:42 PM, Stuart Dallas <stuttle(a)gmail.com> wrote: > On 24 Mar 2010, at 20:34, Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan <ash(a)ashleysheridan.co..uk> wrote: >> On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: >> Do you have any proof of this 'market trend'? I suggested a vote, but you 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly know as much as you do. >> >> >> yes, twitter. facebook. the fact that a graphics upgrade would likely increase business for the first ones on that popularity level to implement it.. >> that's the proof i have for the market trend. > > Again, improving the graphical content of a website has absolutely no effect on the performance of PHP. The additional time the page takes to load is all about network latency and how well you've arranged your static file serving. right now my cms is 2D, and indeed most of the graphics are static then. but i have plans to lift it into 3D, with "rooms" interacting via avatars, and then the graphics-selection and avatar-behavior (animations) selections alone i suspect will put much extra stress on the servers. especially if i have to use sql servers to handle the datastreams. > >> oh, and the fact "cloud computing" is becoming more and more of a buzzword in the industry. > > Cloud computing really doesn't mean what you think it means. its a flexible term eh.. others' definitions are clearly not always aligned with yours. > >>> I wouldn't say I belonged to any particular camp at the start of this thread, but now, having read what my betters have said, I'm inclined to agree that threading isn't the magic wand that you seem to think it is. I personally see one of the largest sites in the world running on PHP without needing threading and without insulting half the list to attempt to get it. >> >> you haven't offered me any description at all of how i'd solve the large-scale realtime-web-app with existing techniques. > > By "realtime-web-app" you mean something like Facebook? They use a combination of PHP, Memcached (and lots of it), MySQL and lots of other layers in-between to do what they do, and threaded PHP is not one of them. > i suppose facebook and twitter are the earliest examples of a near-realtime-web. i think the dataflows of the future realtimewebs (in the next 3 to 10 years) will increase quite a bit in size and speed of updates. >> and if i explain why i'd need the features we've discussed, you dismiss it by accepting a generalized "that can be solved with more sql servers" answer that is admitted to increase costs in every department, including energy consumption. on a non-linear scale btw. > > What I'm getting here is that you want everything without paying for it. When it comes to scalability it's cheaper to achieve it by adding servers than it is to squeeze every last drop of performance out of a single box. The cost in development time alone to implement effective threading strategies would far outstrip the cost of adding a couple of servers and ensuring that your app is scalable. i have this strong gut-feeling that adding more hardware when it's not needed leads to waste on a non-linear scale. in particular using sql servers to handle datastreams seems not wise to me. i'd like to use sql only for permanent storage. > > What you seem to be ignoring is the fact that these issues have been solved already, and the techniques that exist are more than adequate to build systems that scale as well as Facebook. What will it take to get you to accept that the way you want to skin the cat is exceedingly messy? yea, the current facebook and twitter. but i'm thinking 3 to 10 years ahead, and want threading and shared mem support in php to save on all my costs, energy consumption, and risks. i also think the wastefulness of letting the 'alternative' paradigm of 'more sql servers' is on a non-linear scale.
From: =?UTF-8?Q?Hans_=C3=85hlin?= on 25 Mar 2010 04:08 MvH / Hans à hlin Tel: +46761488019 http://www.kronan-net.com/ irc://irc.freenode.net:6667 - TheCoin 2010/3/25 Rene Veerman <rene7705(a)gmail.com>: > On Thu, Mar 25, 2010 at 6:13 AM, Hans à hlin <ahlin.hans(a)kronan-net.com> wrote: >>I admit that if there were native support for threading I >> would use it. But I don´t want the support for threading if it >> slowdown the performance. > > hmm i bet you can use any feature of php to slow things down.. > > i think what's been proven by the pro-camp by now is that at least > some application designs would benefit from threading and shared > memory. > > imo there's no way to tell up front if threading will be detrimental > or benefitial to all projects built with php. > itsa case-by-case thing... aint it? > The problem as I understand it, is that the whole language would be affected, and project that doesn't use shared memory and/or threading is going to be affected negatively. But if there is some way to implement threading and shared memory without the side effects and keeping the security that php provide to day, and with the resources that the project have. Then i'm totally for it.
From: Per Jessen on 25 Mar 2010 04:09 Tommy Pham wrote: > I think you're missing my point. Given your current hardware, > software, product list, etc... how long does it take to run your > queries in series? If you were able to run them in parallel and > deliver faster response time to the users, would you implement PHP > thread, if it's available? I mentioned it yesterday, but perhaps you overlooked it - the mysqlnd driver supports asynchronous queries. If you really have an issue with= the elapse time of sequential, but independent database queries, executing them asynchronously is the obvious solution. (apart from tuning the database, but I'm assuming you've already been there). --=20 Per Jessen, Z=C3=BCrich (11.9=C2=B0C)
From: Per Jessen on 25 Mar 2010 04:31
Tommy Pham wrote: > As such, let's dissect what you mentioned: >=20 > 1) PHP with internal thread support > 2) PHP with external C/C++ thread support That's not quite what I mentioned, but I'll accept it for the sake of argument.=20 > * Performance - having external thread support, now you have to call > an extension (more memory usage and CPU cycles).=20 Tommy, you are already using millions of more cycles by running PHP instead of C. It's a reasonable trade-off of course, but "using more cycles" is not a valid counter-argument.=20 > If you happen to have a C/C++ guru who can then code that thread > support into PHP extension, wouldn't it still perform better at the > core vs as an extension because it's not talking to a 'middle man'?=20= It's another trade-off Tommy - you run two separate processes, talking to each other over TCP (for instance) to gain 1) performance and 2) flexibility/scalability. You gain performance by having processes that= can be independently scheduled by the OS, and you gain flexibility by being able to move a process to another box (for scalability). You pay for that with a few thousand cycles. When you decide to use a database= (e.g. mysql) you also make a trade-off - well-managed data, a structured query-language and some overhead vs. doing it all in your own code.=20 > * Portability - if you're currently running PHP on Windows, but manag= e > to convince management to switch to *BSD/Linux, then you'd have to > rewrite that external thread support.=20 If portability is a concern, I'd make sure my threaded backend would ru= n on all the platforms I could envision. Portability is merely one of many factors that affect choice of programming language.=20 > * Managability - should your need to upgrade PHP for either bug fix, > new features you'd want to implement to add more functionality to you= r > site, will that then break your custom external solution? How much > more manageable is it if it's done under 1 language versus 2+? I said it yesterday already - having a single implementation language I= S a positive, but it may not always be possible due to requirements.=20 --=20 Per Jessen, Z=C3=BCrich (12.3=C2=B0C) |