The linked url [0] is also a great visualization with a bit more data than the twitter image.
Stack Overflow is a cacheless, 9-server on-prem monolith
81–90 of 120 posts
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#82That defies the laws of physics. How can they be web scale without cloud and microservices?
I want to upvote you, but you forgot MongoDB, which is the most fundamental law of web scale.
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#83The best cache is the one built into the database. People seem to forget that the major rdbmses have sophisticated cache strategies of their own and that handing them more RAM (and ensuring they are configured to use it for query or other cache) is usually a good first strategy before trying to second guess and reinvent the cache outside the db. Thread says SO allocates 1.5TB RAM to SQL Server. Sounds wise.
It's all about the load though. SO is probably 95% Read-Only which makes sense for removing the cache layer. If you had a more writes, then they would need an external cache to offset the read load.
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#84The linked url [0] is also a great visualization with a bit more data than the twitter image. [0] https://stackexchange.com/performance
Only 450 peak reqs/s? Doesn't that seem low?
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#85The folks over at SO picked a stack (C#, SQL Server, IIS), and optimized the heck out of it to keep this "simplicity". Much of SO is custom built from the ground up to push performance and stay within the purity of the canonical .net stack.
It isn't clear to me this is a model that would work elsewhere, or should be held up as something to be replicated.
Did they save time? Did they save money? Did this help make SO a wildly successful company? Did it allow them to deliver features to customers faster?
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#86The main takeaway is that the questions searched for are so widely distributed that there is no need for a cache layer - they are nothing but long tail. At that point there is no 'cloud' design that can help. Its either one database (or maybe just shard everything onto thousands of distributed nodes) But the point I am trying to make is that kubernetes and microservices etc are based on idea of winners - power laws.…
I mean, kubernetes or microservices don’t care how the data reads are distributed, right? That problem is a database-level thing whereas k8s is infrastructure, you can run any kind of database with any kind of sharding you want on it. I feel like it might be more accurate to say something like “the value of caching is based on the idea of winners” for example
Yes. I think basically I would not have done it like that but they did, it's wildly successful so fair play - it's taste that makes the difference
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#87I don't think its that much more complicated than Wikimedia, which does 5x the traffic: https://meta.wikimedia.org/wiki/Wikimedia_servers
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#88Earlier quoted context omitted.
Right - Marc Gravell and Tim Craver, who worked on the core architecture of Stack Overflow, were both so obsessive about extracting performance from .net web applications that when they couldn’t do any more from the outside, they both quit and went to work for Microsoft on performance improvements in the framework itself. I feel like it’s similar to how people point to Craigslist as evidence that you can still build…
Except that servers are literally 50-100x more powerful than they were when these sites were built. You just don't need legendary talent anymore to accomplish pretty reasonable scaling with a simple low server count architecture.
It's true! Hardware is powerful enough nowadays to run all those needless microservices and containers. ;-)
Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#89Re: Stack Overflow is a cacheless, 9-server on-prem monolith
#90Even though I love their simplicity as an example of how to be pragmatic and not over-engineer, do remember that they’ve tuned their code to the point that they built an ORM that is one of the fastest in the NET world. I used it and it was awesomely lightweight. It’s as much an example of how far world class talent can go, as it is about doing more with less.
You can also see this the other way around — it's a testament to how slow some other stuff is.
Which, to be clear, is not intended to be a negative statement about that "other stuff". It really depends. Some is. But I've also seen things just done poorly by applying tools wrong, e.g. ORM misuse leading to thousands of queries that should have been one OUTER JOIN.
But I don't think you need engineers of their unique calibre to get most of what they got. It's probably an exponential thing, if you have some merely good engineers you could maybe achieve 80% of their performance. The last 20% are just much more costly.