|
|
Posted by Jerry Stuckle on 01/06/08 18:39
faulkes wrote:
> On Jan 6, 1:45 am, FFMG <FFMG.32r...@no-mx.httppoint.com> wrote:
>> Jerry Stuckle;111941 Wrote:
>>
>>
>>
>>> You should ALWAYS write the site to scale. It's not any harder. And
>>> even if it is just an "administrative back end", are you SURE there
>>> will
>>> never be two administrators changing at the same time?
>>> Such "assumptions" are traps waiting to spring.
>> Can you suggest some links/tutorial on scaling a site?
>>
>
> Note: skip to the bottom for some useful links.
>
> Scalability isn't addressable in a single point, you first have to
> determine
> the what and why you need to scale. It's really easy to say "You
> should always
> write your code to scale" and of course, those people should be shot.
Nope, you should write your code to scale. But scalability varies.
> It isn't
> useful and doesn't tell you anything and if there is one thing I've
> learned, when
> an application goes from development to the users, they will
> invariabley find a
> way to make it die().
>
That's because there is no one part of scalability. In any one
application there may be one or dozens of different things you can do
for scalability. And he asked for a site which has info. As I said - I
don't know of a single site.
And programs won't fail if they've been properly designed and tested.
I'm not saying they're going to be perfect. There's no such thing.
However, a proper development process will keep them from dying.
> So, where does that leave us? There was an old addage about
> scalability, which was
> if you are building an app you expect to support 100 users, design it
> to support
> 1000 users, if you are building it to support 1000 users, design it to
> support
> 10,000 users, etc.. etc..
>
Exactly.
> You can design an app perfectly to support 1 million users but if you
> only have
> a dialup connection, it won't do you much good. Scalability covers
> everything
> not only from the code perspective but down to your network
> perspective (lb's,
> reverse caching, memcache, redundant bandwidth, redundant servers,
> etc)
>
But the app is the hardest to change. It's much easier to change from a
dialup connection to a T-3, for instance.
> Start with the IBM series of articles (note, I do not work for IBM):
>
> http://www.ibm.com/developerworks/linux/library/l-tune-lamp-1/#resources
> http://www.ibm.com/developerworks/linux/library/l-tune-lamp-2.html?ca=dgr-lnxw01LAMPTuningP2
> http://www.ibm.com/developerworks/opensource/library/os-php-fastapps2/
>
> Those should cover your basics of the single server and php, google
> the rest out
> for load balancing, caching, etc.
>
Those are good for what they say. But they're by no means complete.
There is a lot more to scaling, even on a single server.
So your answer is telling him to google? Gee, can't you do better than
that?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|