3 ms·

You can achieve decentralization with a handful of nodes, and you can manage them using simple techniques without inviting the whole large-scale cluster schedul

You can achieve decentralization with a handful of nodes, and you can manage them using simple techniques without inviting the whole large-scale cluster scheduler problem. What I'm talking about is like 3,000 nodes to serve 15,000 QPS. That seems like a lot of QPS, and so it makes intuitive sense to people that they'd need a big distributed system for it, unless they have a sense of how fast computers actually are.

H8crilA 6y ago
As this post shows - it really depends on what you're doing :). There are services that can handle 100k QPS on a single machine, no problemo. There are services that can handle as little as 10 QPS per machine. Those are rather extreme cases. A classic example of a "cheap" service is something like Stack Overflow [1] or Wikipedia: serving content that is mostly static; you just gotta configure your caches well. A classic example of an "expensive" service: a search engine, where so many queries cannot be cached (too rare), or are even completely unique (never seen before [2]). [1] https://stackexchange.com/performance https://stackexchange.com/performance [2] https://www.seroundtable.com/google-15-percent-queries-25730.html https://www.seroundtable.com/google-15-percent-queries-25730...
- closeparen 6y ago
  Right - "those are rather extreme cases." So if you're looking at 5 QPS / node, you should be raising your eyebrows, not automatically reaching for an autoscaling group.
  - deleted 6y ago
    [deleted]
- mdoms 6y ago
  Stack Overflow caches almost nothing. In fact they have just removed most of their remaining caching[1] with no performance hit. Because, surprise, pulling data from a DB and rendering HTML from it is fast, if you're careful about how you do it. The problem with many developers today is that they don't take this level of care. [1] https://twitter.com/Nick_Craver/status/1280494336673751044?s=19 https://twitter.com/Nick_Craver/status/1280494336673751044?s...

H8crilA 6y ago

As this post shows - it really depends on what you're doing :). There are services that can handle 100k QPS on a single machine, no problemo. There are services that can handle as little as 10 QPS per machine. Those are rather extreme cases. A classic example of a "cheap" service is something like Stack Overflow [1] or Wikipedia: serving content that is mostly static; you just gotta configure your caches well. A classic example of an "expensive" service: a search engine, where so many queries cannot be cached (too rare), or are even completely unique (never seen before [2]). [1] https://stackexchange.com/performance https://stackexchange.com/performance [2] https://www.seroundtable.com/google-15-percent-queries-25730.html https://www.seroundtable.com/google-15-percent-queries-25730...

closeparen 6y ago
Right - "those are rather extreme cases." So if you're looking at 5 QPS / node, you should be raising your eyebrows, not automatically reaching for an autoscaling group.
- deleted 6y ago
  [deleted]
mdoms 6y ago
Stack Overflow caches almost nothing. In fact they have just removed most of their remaining caching[1] with no performance hit. Because, surprise, pulling data from a DB and rendering HTML from it is fast, if you're careful about how you do it. The problem with many developers today is that they don't take this level of care. [1] https://twitter.com/Nick_Craver/status/1280494336673751044?s=19 https://twitter.com/Nick_Craver/status/1280494336673751044?s...