Happily upgrading Ruby on Rails at production scale

webuild.envato.com

42 points·sebastianmck··5 comments

Open articleView on HN

"8000 requests per minute" sounds quite a lot for a RoR system.

Would you mind to elaborate on

- how many of those requests are responded from cache

- the underlaying deployment architecture (type & number of servers and/or VMs)

- and you average server response time (uncached)

Thanks

EDIT: Why the downvote?

I guess its the "quite a lot for a RoR system" part of your comment that some people may see as kind of offending, regarding Rails.

Because he talks about a system, not a single app instance (you cannot upgrade that incrementally). And 8000 req/m isn't _that_ fancy for 2 app servers for ordinary loads - thats 133 req/s which would be ~65 req/s per server.

So: the downvotes are for calling ~65 req/s "quite a lot for a RoR system".

Does it really suck so badly?

I mean, 8000 requests per minute on a quad-core systems is 33 request/second per core, or 100 million CPU cycles per request on a 3.3GHz CPU.

That seems enough for the web server to take a vacation in the middle of responding.

I'm a dev that works at Envato on the marketplace sites discussed in the link. Some quick answers:

- None of those requests are served from cache. That's the number hitting the Rails stack and being served dynamically (there are some cached pages on top of that. not sure of the number of RPM off hand)

- Deployed on nginx/unicorn running on linux servers. I think we've got 17 web servers at the moment. Not sure of the specs sorry.

- average server response time is 155ms (again, not using caching)

Reply on news.ycombinator.com