500 requests/s with Ruby on Rails 4 on a 5$ / month server

http://blog.wiemann.name/500-requestss-with-ruby-on-rails-4-on-a-5-month-server

by matwiemann • 13 years ago

26 15 13 years ago

blog.wiemann.name

benologist2• 13 years ago

Am I reading the ab output wrong or did you only make 40 requests and 13 of them failed?

Also there's no mention of what your test actually is?

Keats• 13 years ago

Indeed

Complete requests: 40

Failed requests: 13

is far from good

jcampbell12• 13 years ago

And 28 were non 2xx, which is also a failure. Probably db issues since there is no way SQLite can handle 20 concurrent connections.

zapt02• 13 years ago

Yeah spot on, the test is useless due to the small sample size. Rounding errors could give you 5000 requests/second if you're lucky.

jcampbell12• 13 years ago

I came to say the same thing. Probably best to just flag this and move on. The results show most of the requests failed.

timmillwood• 13 years ago

I find a single dyno on Heroku does a good job too and costs $0 / month. So far the most traffic I've handled is 1,708 page views in an hour with Rails 4 (and a lot of action caching).

siong1987• 13 years ago

That's less than 1 request/second. Rails should be fine even without caching.

nwh• 13 years ago

If anybody wants to have a go at trying it themselves, the coupon "SSDTWEET" will give you $10 credit on DigitalOcean.

LogicX• 13 years ago

Discussion from his previous post in the series: https://news.ycombinator.com/item?id=5763282

tlogan• 13 years ago

Cool write up - I never heard about Puma server. I should check it.

BTW, similar result like this can be also achieved with any RoR and jruby 1.7 (for me jruby 1.7 uses much less mem then 1.6). Threads in jruby are quite cheap. And as always database is the bottleneck but jruby is cool because you can embed BerkeleyDB in it (so open temp Berkely DB and cache things like crazy).

viktorsr• 13 years ago

Last time I benchmarked Puma on MRI 1.9 and 2.0 it was quite fast for most requests, but some requests took more than 20 seconds to complete. The bottom line being that it would be nice to see full ab output.

acanby• 13 years ago

What is the best way to establish optimal pool size? The article seems to gloss over this and instead mentions 'you need to set pool: 25', but I doubt this is a one size fits all solution.

Anyone have any experience profiling these sorts of things that can share some info?

trustfundbaby• 13 years ago

You probably want to find out max_connections for your server.

Then figure out how many other connections you'll need outside your server (rails console, cron jobs, commandline) subtract that and you have your number.

I like to have about 10 spare connections.

Running

select name, setting from pg_settings where name = 'max_connections';

in postgres. I see I have 100 max connections.

So that minus 10 gives me a pool size of 90.

500 requests/s with Ruby on Rails 4 on a 5$ / month server

Related Stories