|
|
Posted by Gary L. Burnore on 01/06/08 18:45
On Sun, 06 Jan 2008 13:39:22 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:
>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?
From: Jerry Stuckle <jstucklex@attglobal.net>
Message-ID: <sOqdne0sTb5GbR3anZ2dnUVZ_sKqnZ2d@comcast.com>
Lines: 29
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 69.140.166.194
X-Trace:
sv3-pJ4CX2te+fkMj1KaLaxCzhe6LQDGnKEI4aebyi1yTFIsUjjcTlgOFgozliD8MkTiY8qZPgi5XbDVMWf!+G8NVqvIB5hPiDvGX5YOb74p+IX9qd1IHEgz8pCbqx6kcYdqU4GFlwAB+yV3gGtZvYPgKog6Qzvi!vUwBZYMwwuKsIKT0VcdavLiHYhjrGFo=
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your
complaint properly
X-Postfilter: 1.3.37
Xref: blackhelicopter.databasix.com comp.lang.php:5007
FFMG 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?
>
> FFMG
>
>
Wish I could, but I haven't seen any sites with such information all
in
one place. Bits and pieces here and there, but that's all.
Maybe someone else has a better answer.
--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
Official .sig, Accept no substitutes. | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
| ÝÛ 0 1 7 2 3 / Ý³Þ 3 7 4 9 3 0 Û³
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
===========================================================================
Navigation:
[Reply to this message]
|