Revisiting taming ruby's memory bloat meta-edition

There are a lot of things that I don't understand. One of these things is how memory management really works. Memory management is hard, and even though I use languages that do garbage collecting by themselves, long running ruby apps seem to run out of memory after n number of days. Even the pro’s find it quite hard. While I previously resetted the failing app every now and then, I was triggered by Mike Perham’s (creator of Sidekiq) post: “Taming Rails memory bloat”.

When you start searching for the memory bloat problem, you'll find several directions. The easiest is changing a global variable which changes the number of “arena’s” where memory allocation takes place (note: I’m in no position to explain all this, please follow the references). The fanciest, however, seems to be changing the memory allocator from glibc's default 'malloc' to jemalloc. See for example [this](https://www.speedshop.co/2017/12/04/malloc…

Ruby on Rails is fast

Of course, this title is obviously too blunt. Still, when I see applications being developed on supposedly fast languages such as Java that perform terribly slow it makes me wonder.

Today I had to fix an issue with the slowness of an overview page inside a product I wrote using Rails. I don't like pagination (it's a workaround), but I wasn't expecting pages with over 700 items. The page with items stored in a traditional database was performing somewhat slow: it took about 6 seconds to load. The fix however took me less than half an hour (including searching the docs) from idea to execution and deployment on production (writing this post took me longer):

  old view code to render the item

Passing the item itself to the cache ensures that the cache gets invalidated when the item is updated. The page load it is still kinda heavy, with 500ms of load time, but this is acceptable for its size.

Features like this make Rails not only a super fast way to realise…

Still waiting for pipe-lining to become mainstream

Sometimes I get a bit upset about a state a project I get to work on is in. Recently I came across a project which frontend served over 30 files that could be reduced easily to about 10. I got upset because to me it is like one of the basic things you have to be aware of as a web developer. I told the others working on the project that is a problem that should be fixed, to optimize speed. But later that day, in bed, I started wondering because the pages were served using HTTPS: was I actually correctin stating it as a problem? Well, currently still yes.

I started wondering because I remembered something about 'pipe-lining'. A year ago I turned on the experimental SPDY protocol a year ago, which supports asynchronous pipe-lining. Pipe-lining allows browsers to request all files in one request, which diminishes the reason why a developer should try to reduce the numbers of file…