3 ms·

> A serious problem with this approach is scaling. Stack overflow runs off one SqlServer. Do you think your app is going beyond that? If yes, maybe this approa

> A serious problem with this approach is scaling. Stack overflow runs off one SqlServer. Do you think your app is going beyond that? If yes, maybe this approach will not work for you. If no, you are in the 99,99999% of all other sites/apps that are not as big as SO, FB or google and you can use this simple way to make your site or app.

superuser2 11y ago
StackOverflow's database doesn't need to work that hard because the vast majority of traffic is read requests for public, essentially static webpages that get re-rendered and updated a handful of times in their lifecycle. I'd guess 90% or more could be served by a reverse proxy without ever touching SQL Server or even the app tier. It would be easy to exceed its DB load with an application that serves unique content to each user, is write-heavy, etc.
- y0ghur7_xxx 11y ago
  > It would be easy to exceed its DB load with an application that serves unique content to each user, is write-heavy, etc. Just curious: did YOU ever reach that point? I mean where a well optimized db engine reached it's limit? Can I ask you on what website?
straws 11y ago
I think the original comment was talking about the need to scale out application servers to take on additional load. Each application sever still communicates with (usually) the one database. Normally people talk about that as a way to increase the throughput of requests that your site can respond to, but it has another benefit: more time spent performing data validation, string munging, date checking, etc adds up to less time spent in the database on the same thing. Stack Overflow may run off of one relational database, but it solves the scaling problem through liberal application-level caching and reverse-proxy caching, all using about a dozen servers that connect to the one database.

3 ms·

> A serious problem with this approach is scaling. Stack overflow runs off one SqlServer. Do you think your app is going beyond that? If yes, maybe this approa

by y0ghur7_xxx 11y ago

superuser2 11y ago
StackOverflow's database doesn't need to work that hard because the vast majority of traffic is read requests for public, essentially static webpages that get re-rendered and updated a handful of times in their lifecycle. I'd guess 90% or more could be served by a reverse proxy without ever touching SQL Server or even the app tier. It would be easy to exceed its DB load with an application that serves unique content to each user, is write-heavy, etc.
- y0ghur7_xxx 11y ago
  > It would be easy to exceed its DB load with an application that serves unique content to each user, is write-heavy, etc. Just curious: did YOU ever reach that point? I mean where a well optimized db engine reached it's limit? Can I ask you on what website?
straws 11y ago
I think the original comment was talking about the need to scale out application servers to take on additional load. Each application sever still communicates with (usually) the one database. Normally people talk about that as a way to increase the throughput of requests that your site can respond to, but it has another benefit: more time spent performing data validation, string munging, date checking, etc adds up to less time spent in the database on the same thing. Stack Overflow may run off of one relational database, but it solves the scaling problem through liberal application-level caching and reverse-proxy caching, all using about a dozen servers that connect to the one database.