10 ms·

The next time someone bitches to me about scaling, I'm going to point them to this article. It's a perfect example of why designing to scale from the beginning

The next time someone bitches to me about scaling, I'm going to point them to this article. It's a perfect example of why designing to scale from the beginning is usually bullshit. It's only worth scaling once you know you have something worth it. Why design all sorts of crazy cache schemes, redundant load balancers, and master-slave databases when your actual product is crap? All you end up doing is slowing yourself down. Get some validation first that anyone is going to swallow your idea. Sure, he had some late nights and some angry emails, but that's because he was dealing with the growing pains of being a success. Better that than the loneliness and depression of working endlessly and never getting anything out the door.

mojombo 18y ago
I've found that it's best to find some sort of sweet spot. Not so simple that later scaling requires a huge rewrite, but not so complex that you're spending valuable time up front to scale something that may never need it. I now try to code the first version as a simple version of the later version. Think ahead, but build for the present.
- drusenko 18y ago
  keeping scaling in mind helps a lot, but the real problems you'll run into then are the ones you're not aware of... like a 32,000 directory limit on linux. as your application grows, you just get blindsided at random, and need to put out fires constantly. and that's where experience with scaling comes in handy. if you don't have it, the next best thing you can do is to have a knowledgeable friend, read up on best practices, and deal with fires quickly.
  - nostrademons 18y ago
    You can also setup a script to load up a million fake users onto a spare box and then mimic some typical activity. This'll catch a lot of the unforseen problems that'll show up: it'd catch that 32k directory limit, it caught the >1000 files/directory slowdown when I tried it, and it'll catch most database indexing or join problems. And if your test computer is much slower than the computer driving the requests, you can catch CPU or I/O bottlenecks in the webserver stack. I use P2/200 Mhz that's 10 years old for this and ping it from my parent's desktop that they bought last year. There're still unforseen problems - there always are - but you can flush out some of the more obvious issues. And the testing can run concurrently with some of the last minute design tweaks, so it doesn't cost all that much in development time. Or do it after you launch when you've got a spare moment; very few websites get big immediately.
richcollins 18y ago
They aren't mutually exclusive. A good, simple design will allow you to move faster and scale better.
- smhinsey 18y ago
  It's my belief that the "how" is as important as the "what" when it comes to your business. If you don't put the same quality of thought into how you execute on your solution, your value proposition is that much harder to emphasize.
axod 18y ago
I think it's a balance. You have to design with scaling in mind, and pick tools that allow you to potentially scale later on. If possible you don't want to have to rewrite you app several times from scratch as you scale. But I agree. The hardest bit is making something people will use, and come back and use again, and again.
alex_c 18y ago
I agree with you, but on the other hand, it's worth keeping the 90/10 rule in mind: if you can get 90% more performance up front with only 10% more effort, go for it. Caching images instead of generating them on the fly is pretty low hanging fruit. (yes, I made up a 90/10 rule just to make my argument sound better).
- jwilliams 18y ago
  > if you can get 90% more performance up front with only 10% more effort, go for it. Scale is only loosely related to performance. You can have an application that performs pretty badly, but scales. This is much better than an application that performs well, but won't scale. Performance tends to degrade slowly, while scale is usually a hard limit (you've reached "n" users? server crashes). Hitting an issue of scale is usually a fairly traumatic thing for a service. I'd agree with the original comment that when you're starting you don't need fancy caching schemes, load balancers or replicated databases. Equally you don't want to build something that is incompatible with these in the future. It's a terrible pain and is probably indicative of a bad design... As the other reply said quite well: A good, simple design will allow you to move faster and scale better.. I'm a big fan of "optimise last", but I think this is often interpreted as "put together badly and fix later"... It should really be "quantify what you optimise".
deleted 18y ago
[deleted]

mojombo 18y ago

I've found that it's best to find some sort of sweet spot. Not so simple that later scaling requires a huge rewrite, but not so complex that you're spending valuable time up front to scale something that may never need it. I now try to code the first version as a simple version of the later version. Think ahead, but build for the present.

drusenko 18y ago
keeping scaling in mind helps a lot, but the real problems you'll run into then are the ones you're not aware of... like a 32,000 directory limit on linux. as your application grows, you just get blindsided at random, and need to put out fires constantly. and that's where experience with scaling comes in handy. if you don't have it, the next best thing you can do is to have a knowledgeable friend, read up on best practices, and deal with fires quickly.
- nostrademons 18y ago
  You can also setup a script to load up a million fake users onto a spare box and then mimic some typical activity. This'll catch a lot of the unforseen problems that'll show up: it'd catch that 32k directory limit, it caught the >1000 files/directory slowdown when I tried it, and it'll catch most database indexing or join problems. And if your test computer is much slower than the computer driving the requests, you can catch CPU or I/O bottlenecks in the webserver stack. I use P2/200 Mhz that's 10 years old for this and ping it from my parent's desktop that they bought last year. There're still unforseen problems - there always are - but you can flush out some of the more obvious issues. And the testing can run concurrently with some of the last minute design tweaks, so it doesn't cost all that much in development time. Or do it after you launch when you've got a spare moment; very few websites get big immediately.

richcollins 18y ago

They aren't mutually exclusive. A good, simple design will allow you to move faster and scale better.

smhinsey 18y ago
It's my belief that the "how" is as important as the "what" when it comes to your business. If you don't put the same quality of thought into how you execute on your solution, your value proposition is that much harder to emphasize.

axod 18y ago

I think it's a balance. You have to design with scaling in mind, and pick tools that allow you to potentially scale later on. If possible you don't want to have to rewrite you app several times from scratch as you scale. But I agree. The hardest bit is making something people will use, and come back and use again, and again.

alex_c 18y ago

I agree with you, but on the other hand, it's worth keeping the 90/10 rule in mind: if you can get 90% more performance up front with only 10% more effort, go for it. Caching images instead of generating them on the fly is pretty low hanging fruit. (yes, I made up a 90/10 rule just to make my argument sound better).

jwilliams 18y ago
> if you can get 90% more performance up front with only 10% more effort, go for it. Scale is only loosely related to performance. You can have an application that performs pretty badly, but scales. This is much better than an application that performs well, but won't scale. Performance tends to degrade slowly, while scale is usually a hard limit (you've reached "n" users? server crashes). Hitting an issue of scale is usually a fairly traumatic thing for a service. I'd agree with the original comment that when you're starting you don't need fancy caching schemes, load balancers or replicated databases. Equally you don't want to build something that is incompatible with these in the future. It's a terrible pain and is probably indicative of a bad design... As the other reply said quite well: A good, simple design will allow you to move faster and scale better.. I'm a big fan of "optimise last", but I think this is often interpreted as "put together badly and fix later"... It should really be "quantify what you optimise".

deleted 18y ago

[deleted]