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

Reply via email to