11–16 of 16 posts
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).
Earlier quoted context omitted.
Indeed Complete requests: 40 Failed requests: 13 is far from good
And 28 were non 2xx, which is also a failure. Probably db issues since there is no way SQLite can handle 20 concurrent connections.
Anyone have any experience profiling these sorts of things that can share some info?
Earlier quoted context omitted.
And 28 were non 2xx, which is also a failure. Probably db issues since there is no way SQLite can handle 20 concurrent connections.
I corrected the blog post with a correct sample size. Thanks for the feedback!
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?
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.