5 ms·

I agree on many points like performance and scalability are not the same but his traditional approach to just make a bigger clustered database is not good. It's

by alecco 18y ago

I agree on many points like performance and scalability are not the same but his traditional approach to just make a bigger clustered database is not good. It's like fixing the bottleneck by making a gigantic bottle, it'll work but the cost will be many times over what was really necessary. If a any single component is a critical bottleneck the best is to either replace it or redesign to stop requiring it. Same goes for the more memory approach.

litewulf 18y ago
The day your website starts generating more traffic than one server can handle you need to do something very quickly to make sure it all stays up. So I think its often reasonable to pay the exorbitant prices as a stopgap before you can start doing any of the more complex scalability re-architecturing.
- alecco 18y ago
  That's a very addictive and self-validating reasoning path. Beware.
  - litewulf 18y ago
    Scaling is painful and requires a good deal of upfront work. I can't guarantee that anyone will use stuff that I make, so I'd rather improve performance when I actually need to. Its addictive also to spend all your time thinking about scalability and sharding and clustering options instead of making something people use. In summary: yes, but be pragmatic about these things. If you are the only user, scaling might not be worth it. If you know that people will be using a feature all the time, think about caching from the get-go. Obviously figuring out which of the cases you are in can sometimes be tricky. ;)
    - alecco 18y ago
      Its addictive also to spend all your time thinking about scalability and sharding and clustering options instead of making something people use. I never proposed that. But leaving doors open for possible alternatives and quick fixes doesn't take much time, maybe 5 minutes of thinking. Sane programming methodologies help, like modularization and partitioning your code in different processes. Scalability and rapid development are not always mutually exclusive.

by alecco 18y ago

litewulf 18y ago

The day your website starts generating more traffic than one server can handle you need to do something very quickly to make sure it all stays up. So I think its often reasonable to pay the exorbitant prices as a stopgap before you can start doing any of the more complex scalability re-architecturing.

alecco 18y ago
That's a very addictive and self-validating reasoning path. Beware.
- litewulf 18y ago
  Scaling is painful and requires a good deal of upfront work. I can't guarantee that anyone will use stuff that I make, so I'd rather improve performance when I actually need to. Its addictive also to spend all your time thinking about scalability and sharding and clustering options instead of making something people use. In summary: yes, but be pragmatic about these things. If you are the only user, scaling might not be worth it. If you know that people will be using a feature all the time, think about caching from the get-go. Obviously figuring out which of the cases you are in can sometimes be tricky. ;)
  - alecco 18y ago
    Its addictive also to spend all your time thinking about scalability and sharding and clustering options instead of making something people use. I never proposed that. But leaving doors open for possible alternatives and quick fixes doesn't take much time, maybe 5 minutes of thinking. Sane programming methodologies help, like modularization and partitioning your code in different processes. Scalability and rapid development are not always mutually exclusive.