Re: Will PHP ever "grow up" and have threading?

On Wed, Mar 24, 2010 at 11:42 PM, Stuart Dallas <stuttle@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@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.