

Scalability issues for dummies - abarrera
http://alwaysnewmistakes.wordpress.com/2009/07/20/scalability-issues-what-are-they-and-their-repercussions/

======
patio11
_This is the point where you realize that developers aren’t engineers, but
craftsmen and that fixing these problems isn’t exactly a science but black
voodoo magic._

I have mentioned it three or four times before but I'll say it again: the key
takeaway from the YSlow presentations is that _fixing the frontend is a
science, not black magic_ and that _user-perceptible load times are dominated
by front-end factors_.

Not your database! Not your application logic! Not your web framework! Not
your idiom for string concatenation!

If you have three CSS files, condensing them to 1 CSS file is as close to zero
technical risk as any intervention in the history of engineering, will take
you far under a man-day to implement a process to correct this defect, and
will provide instant, lasting, guaranteed performance gains everywhere you
were using those three files.

If you don't gzip your Javascript, CSS, and HTML yet...

If you have spent weeks thinking about how to use memcached and not so much as
a minute discussing expires headers...

~~~
cperciva
_[U]ser-perceptible load times are dominated by front-end factors. Not your
database! Not your application logic! Not your web framework! Not your idiom
for string concatenation!_

It is true that user-perceptible load times are dominated by front-end
factors. However, whether the user perceives anything at all -- or if,
instead, the web site has collapsed under load -- is dominated by back-end
scalability.

Scalability is far more about _keeping things running_ than it is about
_making things fast_. People should pay attention to both front-end and back-
end issues -- a website which is up but loads very slowly isn't very useful,
but neither is a website which loads very fast but goes offline whenever it
gets a lot of traffic.

~~~
lucifer
"Scalability is far more about keeping things running than it is about making
things fast"

The need to state these facts is further evidence that this is an arts and
crafts industry (and not scientific). Imagine physicist saying "Inertia should
not be confused with momentum".

~~~
patio11
Inertia and momentum are not just different points on the same continuum.
"Keeping things running" and "making things fast" are, at least as the author
is using the term scalability. Look at the graph of response time versus
number of operations included in the article. It says "As the site gets
busier, performance is impacted negatively to the point where it compromises
the user experience". That is virtually the definition of a scalability
problem (more scale = boom!) without ever requiring the system to stop
running.

I suppose you could arbitrarily redefine scalability such that problems caused
by scale which did not cause the server to crash were not scalability
problems, but your redefinition would not contribute to professionalizing the
field of web development.

~~~
smokinn
No, it isn't. People in our industry commonly use the word scalability to
denote metrics such as response time but that's just plain wrong.

You can have a website that takes 3 minutes to load yet still be scalable. As
long as it takes 3 minutes to load when you have a single user, 3 minutes at
1000 users and 3 mintes at 1 million you have a scalable website. Scalability
is all about keeping the same (or at least close) performance as your load
increases.

If you want to know more about scalability I suggest you read Theo
Schlossnagle's excellent Scalable Internet Architectures book.

