3 ms·

Scalability issues for dummies

13 points by abarrera 17y ago

patio11 17y ago
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...
- abarrera 17y ago
  I'm very aware of this, but that's not the problem I'm talking about. The Twitter Fail whale doesn't happens because of front-end problems, nor Facebook's slowness, nor the cpu overload you see on your thumbnail processing machines, nor the mem crashes you experience when memcache servers run out of memory... I do agree with you that a lot of what users experience as slowness IS front-end stuff. BUT there is also a lot of issues with the backend not working as expected. Lets say, front-end optimization is like shooting the low hanging fruit :) Nevertheless you're right I should have commented it somewhere.
- cperciva 17y ago
  [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 17y ago
    "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 17y ago
      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.
      - lucifer 17y ago
        I don't think 'response-time' and 'scalability' are merely differentiated degrees of a given scalar, either. Scalability is a multi-dimensional measure, which incorporates 'response-time'. "professionalizing the field of web development" I think this touches on a key differentiator of our chosen profession. Nearly every other (industrial) professional field (with the exception of Architecture, which shares many of the characteristics of Software "engineering" in sharing a hazy boundary between 'art' and 'science') has a tiered body of workers that rests on a fairly commoditized implementation base. (Consider your precious laptop. Put together by workers with high-school education.) I don't see how we can "professionalize" [software] development (in terms of actual producers of ubiquitous software artifacts) unless we have programs writing programs.
      - smokinn 17y ago
        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.
- robryan 17y ago
  It really depends, if the author was worrying about .1 of a second processing time on the back end for each script load you are exactly right. If the server is crashing or only intermittently serving pages because of load there is nothing front end optimization can do about it. I guess sometimes you also have to weigh up just adding some extra hardware to smooth a transition to a new back end, or even to buy some more time with the existing one.
  - abarrera 17y ago
    I'm the author and I was talking more about not being able to load parts of the web due to timeouts with the backend. I run a very cpu hungry site and some parts took a lot to get computed and served. So again, I'm sorry for the confusion but I was talking about backend derived problems, not front-end although as I said previously, I'm well aware of them too :) But those don't take forever to fix, backend (usually) does

13 points by abarrera 17y ago

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...

abarrera 17y ago
I'm very aware of this, but that's not the problem I'm talking about. The Twitter Fail whale doesn't happens because of front-end problems, nor Facebook's slowness, nor the cpu overload you see on your thumbnail processing machines, nor the mem crashes you experience when memcache servers run out of memory... I do agree with you that a lot of what users experience as slowness IS front-end stuff. BUT there is also a lot of issues with the backend not working as expected. Lets say, front-end optimization is like shooting the low hanging fruit :) Nevertheless you're right I should have commented it somewhere.
cperciva 17y ago
[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 17y ago
  "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 17y ago
    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.
    - lucifer 17y ago
      I don't think 'response-time' and 'scalability' are merely differentiated degrees of a given scalar, either. Scalability is a multi-dimensional measure, which incorporates 'response-time'. "professionalizing the field of web development" I think this touches on a key differentiator of our chosen profession. Nearly every other (industrial) professional field (with the exception of Architecture, which shares many of the characteristics of Software "engineering" in sharing a hazy boundary between 'art' and 'science') has a tiered body of workers that rests on a fairly commoditized implementation base. (Consider your precious laptop. Put together by workers with high-school education.) I don't see how we can "professionalize" [software] development (in terms of actual producers of ubiquitous software artifacts) unless we have programs writing programs.
    - smokinn 17y ago
      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.
robryan 17y ago
It really depends, if the author was worrying about .1 of a second processing time on the back end for each script load you are exactly right. If the server is crashing or only intermittently serving pages because of load there is nothing front end optimization can do about it. I guess sometimes you also have to weigh up just adding some extra hardware to smooth a transition to a new back end, or even to buy some more time with the existing one.
- abarrera 17y ago
  I'm the author and I was talking more about not being able to load parts of the web due to timeouts with the backend. I run a very cpu hungry site and some parts took a lot to get computed and served. So again, I'm sorry for the confusion but I was talking about backend derived problems, not front-end although as I said previously, I'm well aware of them too :) But those don't take forever to fix, backend (usually) does