Eric Wong wrote:
> The Rack response body only needs to respond to #each.
> There should be no reason to build giant response
> documents in memory before sending them to a client.
>
> unicorn can't do the following for you automatically since
> we don't know how/if a Rack app will reus
I agree with most of what you've written. I drew my conclusions a while
ago and switched to using Erlang (not Elixir!) for all my backend jobs
in the past couple of years. In a way it is a more constraint /
restricted environment. There are less libraries and frameworks
available and the langua
Sam Saffron wrote:
> As to who is at fault here, it is a little bit of "everyone" in a big bucket.
I agree. At least everyone who was blindly upgrading hardware :)
But yeah, memory usage really is a whack-a-mole affair and
programmers need to constantly watch out for this.
> - The new GC is fa
As to who is at fault here, it is a little bit of "everyone" in a big bucket.
- The new GC is far more memory hungry than 1.9 line, even with
`RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5` it is still a lot more space
than it used to
- Ruby have been very slow at dealing with the "elephant in the room
Came across this in my feeds today:
https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/
... Yeah, they cite 0.5 GB of memory usage per unicorn worker.
I guess this is typical nowadays, but damn, it sucks :<
This is not the future I had in mind or ever wanted unicorn to
