On Wed, Mar 24, 2010 at 11:42 PM, Stuart Dallas <stuttle@xxxxxxxxx> wrote: > On 24 Mar 2010, at 20:34, Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
