Happily upgrading Ruby on Rails at production scale(webuild.envato.com)
webuild.envato.com
Happily upgrading Ruby on Rails at production scale
http://webuild.envato.com/blog/upgrading-ruby-on-rails-at-production-scale/?q
1 comments
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".
So: the downvotes are for calling ~65 req/s "quite a lot for a RoR system".
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)
- 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)
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.
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 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.
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?