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