Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling Rails and Postgres to millions of users at Microsoft

stepchange.work

Post reply on HN
Print view View original

41–50 of 96 posts

Re: Scaling Rails and Postgres to millions of users at Microsoft

#41

Post by danmaz74 »

petcat wrote: post #28
benwilber0 wrote: post #27

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…

"without blowing $250,000/month on their AWS bill". The point is that you don't need AWS for this! You can use Docker to configure much, much cheaper/faster physical servers from Hetzner or similar with super-simple automated failover, and you absolutely don't need an expensive dedicated OPS team for that for this kind of simple deployments, as I read so often here on HN.

You might get surprised as how far you can go with the KISS approach with modern hardware and open source tools.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#42

Post by danmaz74 »

datadeft wrote: post #33

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…

"For millions of users the CPU cost difference probably justifies the rewrite cost." This is only true if you have expensive computations done in Ruby or Python or similar, which is very rarely the case.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#43

Post by hamandcheese »

ainiriand wrote: post #35
datadeft wrote: post #33

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…

You really do not know what you are talking about, it is not about the language, like it was repeated in this forum many many times already. We serve an application in PHP to thousands of users per second in less than 100ms constantly.

Sometimes it is the language. Or at least the ecosystem and libraries available.

My go-to example is graphql-ruby, which really chokes serializing complex object graphs (or did, it's been a while now since I've had to use it). It is pretty easy to consume 100s of ms purely on compute to serialize a complex graphql response.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#45

Post by nov21b »

ainiriand wrote: post #36
petcat wrote: post #28

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…

We use 5 ec2 instances to serve around 32 million requests per day on PHP, all under 100ms. It is not the language.

The language/runtime certainly has an impact. But indeed, in reality there is no way to compare these scaling claims. For all we know people are talking about serving a http-level cache without even hitting the runtime.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#46

Post by whakim »

pajeets wrote: post #7

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…

Yes, scaling vertically is much easier than scaling horizontally and dealing with replicas, caching, etc. But that certainly has limits and shouldn’t be taken as gospel, and is also way more expensive when you’re starting to deal with terabytes of RAM.

I also find it very difficult to trust your advice when you’re telling folks to stick Postgres on a VPS - for almost any real organization using a managed database will pay for itself many times over, especially at the start.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#47

Post by brightball »

danmaz74 wrote: post #38
pajeets wrote: post #7

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…

Having at least 2 web servers and a read-only DB replica for redundancy/high availability is very easy and much safer. Yes, setting up a single-server is faster, but if your DB server dies - and at some point it will happen - you'll not just save a lot of downtime, but also a lot of stress and additional work.

Read replicas come with their own complexity as you have to account for the lag time on the replica for UX. This leads to a lot of unexpected quirks if it’s not planned for.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#48

Post by danmaz74 »

brightball wrote: post #47
danmaz74 wrote: post #38

Earlier quoted context omitted.

Having at least 2 web servers and a read-only DB replica for redundancy/high availability is very easy and much safer. Yes, setting up a single-server is faster, but if your DB server dies - and at some point it will happen - you'll not just save a lot of downtime, but also a lot of stress and additional work.

Read replicas come with their own complexity as you have to account for the lag time on the replica for UX. This leads to a lot of unexpected quirks if it’s not planned for.

That's true, but you can use your replica only for non-realtime reporting, or even just as a hot standby.

Edit: Careful for the non-realtime reporting though if you want to run very slow queries - those will pause replication and can be a PITA.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#49

Post by cqqxo4zV46cp »

brightball wrote: post #47
danmaz74 wrote: post #38

Earlier quoted context omitted.

Having at least 2 web servers and a read-only DB replica for redundancy/high availability is very easy and much safer. Yes, setting up a single-server is faster, but if your DB server dies - and at some point it will happen - you'll not just save a lot of downtime, but also a lot of stress and additional work.

Read replicas come with their own complexity as you have to account for the lag time on the replica for UX. This leads to a lot of unexpected quirks if it’s not planned for.

A hot standby / failover still meets this definition. That’s how I interpreted what was being described.

Re: Scaling Rails and Postgres to millions of users at Microsoft

#50

Post by rubyfan »

15 years ago I worked on a couple of really high profile rails sites. We had millions of users with Rails and a single mysql instance (+memcached and nginx). Back then ruby was a bit slower than it is today but I’m certain some of the challenges you face at that scale are things people still do today…

1. try to make most things static-ish reads and cache generic stuff, e.g. most things became non-user specific HTML that got cached as SSI via nginx or memcached

2. move dynamic content to services to load after static-ish main content, e.g. comments, likes, etc. would be loaded via JSON after the page load

3. Move write operations to microservices, i.e. creating new content and changes to DB become mostly deferrable background operations

I guess the strategy was to do as much serving of content without dipping into ruby layer except for write or infrequent reads that would update cache.

Post reply on HN