Additional server optimizations?

[noahgibbs]

This issue depends on #9.

One interesting thing about building server-optimized Ruby is that standard CRuby very clearly is not optimized for the server case.

Are you considering changing the default value of environment variables to something more reasonable for a decent-sized server host (and by extension, less reasonable on a Raspberry Pi or similar?)

Off the top of my head, some great candidates would include RUBY_GC_HEAP_INIT_SLOTS, RUBY_GC_MALLOC_LIMIT, RUBY_GC_OLDMALLOC_LIMIT and RUBY_GLOBAL_METHOD_CACHE_SIZE. I'm sure there are others, though. Some of them only help startup time (e.g. RUBY_GC_HEAP_INIT_SLOTS) but some of them make a difference for Ruby's entire runtime (e.g. RUBY_GLOBAL_METHOD_CACHE_SIZE.)

And hey, even startup time is good.

[noahgibbs]

And I don't know how much you've played with JIT, but the current JIT defaults are not at all server-optimized. I doubt that's mature enough to tune yet in released 2.6, but it's worth keeping an eye on for the future.

[jamatthews]

Definitely would be good to increase the global method cache size! You’ve got a bunch of benchmarks supporting this app even for smaller Rails apps, right?

[noahgibbs]

I've mostly tested it with Discourse, which is fairly big. But Discourse also gains by at least a 4x increase in the cache size, and probably an 8x+ increase (http://engineering.appfolio.com/appfolio-engineering/2018/7/18/rubys-global-method-cache). So yeah, even a mid-size Rails app is big enough that the global method cache should really be bigger.

Doubling it (4096) would be kind of ridiculously obvious - barely any extra memory, noticeable speedup. But for most cases 4x would be extremely supportable and 8x not a bad idea.

Eyeballing the "cache_entry" structure in vm_method.c, it looks like 5 8-byte values (for a normal 64-bit Ruby architecture), which I think should stay 40 bytes even with alignment. So by default it should use 81,920 bytes, and if you 8x'd it, you'd get 655,360 bytes, or 640kb even. On a server, that seems like a very reasonable per-process overhead.

Edit to add: the reason I'm only talking about how many times to double it is that the Ruby source requires that it be a power of 2. So you could quadruple and get 320kb used, but you couldn't choose to use 480kb because then the number of cache entries wouldn't be a power of 2.

[schneems]

I like setting RUBY_GC_HEAP_GROWTH_FACTOR to something low, it increases the number of malloc calls but brings down the overall memory use substantially in some apps.

https://devcenter.heroku.com/articles/ruby-memory-use#gc-tuning

In my experience the cost of a slower ramp up time is not noticeable on a real world application.

[noahgibbs]

That makes some sense. I found that setting slots and malloc limit directly to final values were a big deal - I built a simple little tool for doing so (https://github.com/noahgibbs/env_mem). But yeah, guessing wrong can definitely waste memory in some cases.

[FooBarWidget]

Yes tuning such settings would be very interesting. I have no idea what values to set them to so I would like to receive advice on that matter.

[noahgibbs]

That makes sense. Things like initial slots could be doubled as a good starting point. As Schneems points out, growth factor is more mixed, so there are more interesting tradeoffs there.

[FooBarWidget]

All agreed. Before starting work on this however, I think we need fullstaq-ruby/umbrella#9 so that we don't work blindly.