31–40 of 96 posts
Earlier quoted context omitted.
was it? i read it was a huge ram server
https://stackexchange.com/performance
Earlier quoted context omitted.
For real. Show me a company that has scaled RoR or Django to 1 million concurrent users without blowing $250,000/month on their AWS bill. I've worked at unicorn companies trying to do exactly that. Their baseline was 800 instances of the Rails app...lol. I'm not going to name-names (you've heard of them) ... but this is a company that had to invent an entirely new and novel deployment process in order to get new code…
I've scaled a single rails server to 50k concurrent, and so if Rails is the theoretical bottleneck there, and we base it off scaling my meager efforts, that's only 20 servers for 1 mil concurrent, or around $1000/mo at the price point I was paying (heroku). Rails these days isn't the top of the speed meters but it's not that slow either.
I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably Rust as well nowadays).
For millions of users the CPU cost difference probably justifies the rewrite cost.
Earlier quoted context omitted.
They are excellent! Another great example is the Django project, which I always point to for how to write and structure great technical documentation. Working with Django/Postgres is such a nice combo and the standards of documentation and community are a huge part of that.
Interestingly I have had almost the exact opposite experience being very frustrated with the Django docs. To be fair, it could be because I'm frustrated with Django's design decisions having come from Rails. When learning Django a few years ago, I still carry a deep loathing against polymorphism (generic relations[0]), and model validations (full clean[1]), You know what - it's design decisions... [0] https://docs.dj…
Scaling a non-scalabe by default framework that should have been few services written in a performance first language at a billion+ USD company. I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably R…
Postgres can scale to millions of users, but Rails definitely can't. Unless you're prepared to spend a ton of money.
For real. Show me a company that has scaled RoR or Django to 1 million concurrent users without blowing $250,000/month on their AWS bill. I've worked at unicorn companies trying to do exactly that. Their baseline was 800 instances of the Rails app...lol. I'm not going to name-names (you've heard of them) ... but this is a company that had to invent an entirely new and novel deployment process in order to get new code…
Postgres can scale to millions of users, but Rails definitely can't. Unless you're prepared to spend a ton of money.
For real. Show me a company that has scaled RoR or Django to 1 million concurrent users without blowing $250,000/month on their AWS bill. I've worked at unicorn companies trying to do exactly that. Their baseline was 800 instances of the Rails app...lol. I'm not going to name-names (you've heard of them) ... but this is a company that had to invent an entirely new and novel deployment process in order to get new code…
Postgres can be scaled vertically like Stackoverflow did. With cache on edge for popular reads if you absolutely must (but you most likely dont). No need to microservice or sync read replicas even (unless you are making a game). No load balancers. Just up the RAM and CPU up to TB levels for heavy real world apps (99% of you wont ever run into this issue) Seriously its so create scalable backend services with postgres…
[1] High Performance PostgreSQL for Rails Reliable, Scalable, Maintainable Database Applications by Andrew Atkinson:
https://pragprog.com/titles/aapsql/high-performance-postgres...
Earlier quoted context omitted.
Stack overflow absolutely had load balancers, and 9 web servers, and Redis caches. They also use 4 SQL servers, so not entirely vertical either. And they were only serving 500 requests a second on average (peak was probably higher).
was it? i read it was a huge ram server
https://nickcraver.com/blog/2016/02/03/stack-overflow-a-tech...
I get what you're saying, they didn't do dynamic and "wild" horizontal scaling, they focused more on having an optimal architecture with beefy "vertically scaled" servers.
Very much something we should focus on. These days horizontal scaling, microservices, kubernetes, and just generally "throwing compute" at the problem is the lazy answer to scaling issues.