+972 52-548-6969
A question of Scale
time to read 2 min | 256 words
One of my routine set of questions when I am coming to a new codebase is: "What is the expected load on the system?" or "How big do you need this to scale?"
I have several variant of the question, including, "What precentage of your budget is dedicated for scaling scenarios?"
In plenty of cases, the answer that I get is vague. There is not definite scaling requirements, but the client want to be able to scale. Here are a few rule of thumbs that will help you to know if scaling is even an issue at this stage of the game.
- If you can't came up with a number for the scaling scenario, you don't need to scale. A number isn't 10,321 concurrent connected users with a peak of 28,154 users. A number is "ten thousands to fifty thousands requests", "Fifteen million visitors a day", etc. You need to have an overall idea, otherwise, you don't need to scale.
- If you are replacing an old (slow) system, and you don't know the numbers, you don't need to scale.
- If you are planning of scale-as-we-go approach, but you don't have a way to measure usage (and usage is more than just requests per second), than you won't be able to scale.
Designing for scale has a cost associated with it, not a high one, if you are doing things correctly, but it is there. Be aware of unnecessary scaling efforts.
Comments
I went to a good session on scaling web apps at devteach vancouver last year. The biggest take-away that I had from it is that scaling is NOT just about how long the server takes to handle a web request. You need to take into account the client-side compute time, the number of web requests your application makes, your bandwidth, the average size of each web request, how long it takes to go from the client to server (ping), and the number of concurrent requests the browser is able to make (hint: it defaults to 3). In order to measure your usage and figure out how to scale, you need to be able to measure all of these things.
Comment preview