Hacker News new | comments | show | ask | jobs | submit login

Some great points about the tooling, especially the control server. For 2.3, the control server is going to get some much needed needed love that should hopefully address major issues.

A couple of notes: Puma has a dynamic pool but it's common to see people configure the pool as 16:16 in production, meaning it's staticly configured to 16 threads.

Some people have asked about using Puma to manage multiple apps recently. I'm currently consider what that would look like. If it's done, it would likely be a separate gem rather than being wired directly into Puma as it is now.

On the topic of time limiting requests, this is conscience choice. Aborting a thread or process externally is really problematic and I don't personally think it's something that should be done casually. If a user wants to do time limiting, they can easily use a Rack middleware that uses timeout.rb.

The same goes for OobGC. Performing it in a multithreaded env makes little sense because the only out-of-band is when all threads are idle. I have thought of some ways to implement it in puma, but I see OobGC is a kludge. Better to tune your interpreter to handle your garbage load better (something 1.9/2.0/rubinius/jruby can all do).

Thanks for the great comparison! I look forward to future back and forth and we all work to raise the level of technology used in ruby webservers.

Hey Evan,

I keep reading how Puma is meant for be run multi-threaded on JRuby or Rubinius.

Would it be non-sense to run it in "cluster" mode (multi-process) under MRI 2.0? Similar to how we'd run Unicorn, for example. Any benefits doing that versus just running Unicorn?

EDIT: we have plenty of ram so that's not really a concern

Yeah, you can certainly run puma in the same operational mode as unicorn with clustering. But what I'd suggest is that you do instead is creating 1.5 as many workers has you have cores in your machine and perhaps 8 threads per worker. With that configuration, you'll get much more even performance than unicorn because you won't get as much cpu thrashing from context switches between processes and the threads will allow a high number of concurrent requests to all make progress concurrently.

Hi Evan, thanks for your great work on Puma. Back in the days Mongrel was already multithreaded but it never reached its full potential because multithreading in the Rails world was so messed up back then. I'm glad to see that you've developed it into such a good state. When I checked your code, it was simple, clean and easy to read. Wonderful technology.

Unicorn currently does have better fault-tolerance tools than Puma though, e.g. the 1-minute timeout on that Unicorn has by default. Unicorn also currently has more documentation than Puma. So there is a tradeoff in the choice, and there's still plenty that all the app servers can learn from each other.

8 threads per worker on MRI? Isn't that a recipe for disaster? Or maybe I'm missing something?

Why would that be recipe for disaster? What do you think would happen?

Aren't threads on MRI evil?

No? I don't know what your referencing.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact