7 ms·
> (you are using Unicorn, right? You should be!) No, you should be using Puma.[0] Unicorn is a work of art and it is incredibly simple, but with that comes a l
by rubiquity 13y ago
> (you are using Unicorn, right? You should be!)
No, you should be using Puma.[0] Unicorn is a work of art and it is incredibly simple, but with that comes a lot of waste. Puma won't fix this problem as it lies in MRI, but you will be able to run way less processes so total memory consumption won't be such an issue.
Ruby 2.1 comes with an asterisk. It's a lot faster but you should take some time to tune the GC to your application's needs. Aman Gupta[1] has some excellent posts on his blog about how to do this. On Rails apps that I have upgraded from 2.0 to 2.1 we have seen around 25% (and up to as high as 50% in some places) decrease in response times. The GC oddities will all certainly get better in Ruby 2.2 (and maybe even in minor releases of 2.1 but I doubt it).
0 - http://puma.io http://puma.io
1 - http://tmm1.net http://tmm1.net
- nnq 13y agoWhy not Passenger?
- rubiquity 13y agoI think Passenger only offers multi-threading in the enterprise edition.
- FooBarWidget 13y agoYes. But support for Aman Gupta's improved out-of-band garbage collector, is in the open source version. The Enterprise version also happens to support out-of-band garbage collection even for multithreaded apps, which as far as I know is not supported by Puma (yet?)
- midas007 13y agoNew passenger is a great btw, what mongrel 2 wanted to be.
- midas007 13y agoPuma offers both multi-threading and multi-process in clustered mode to take advantage of multiple cores. Here's our config/puma.rb that we used with Rails 4.1beta and 2.1.1: https://gist.github.com/9838767 https://gist.github.com/9838767
- otterley 13y ago"Unicorn is a work of art and it is incredibly simple, but with that comes a lot of waste." What "waste" are you talking about? It's a multiprocess Rack-compliant webserver, and not much else.
- FooBarWidget 13y agoBeing multi-process is the "waste". Each process has its own heap, its own copy of the AST and bytecode, etc. Even with preforking and copy-on-write, the overhead introduced by processes is still significantly bigger than running many threads within 1 process. Of course, this doesn't have to be a problem for everyone. Whether threads are advantageous depends a lot on the workload.
- deleted 13y ago[deleted]
- otterley 13y agoI think a little extra memory in exchange for a whole lot of safety and code simplicity is a fair tradeoff. If you don't have enough memory to spawn a few hundred subprocesses I'd suggest you tackle that first.
- steveklabnik 13y agoThank you. "Threads are always better than processes, lololol" really gets under my skin. There are pros and cons to each approach.
- ikawe 13y agoThe first step of scaling an app is not to make sure you have a server with at least 43GB of RAM. If we say a typical Rails process is 150MB, then consider several hundred of them... 150MB * 300 = 43GB So, while your point is valid, in that there is value in safety and code simplicity, we're not talking just "a little" memory. Consider your use case, that's all.
- 13y ago