Puma vs Phusion Passenger

I don't understand how people are using multithreaded ruby. Are these people doing something clever that I am not aware of? Or is it just insane amounts of testing?

http://stackoverflow.com/questions/15184338/how-to-know-what...

Web stuff tends to be embarrassingly parallel: http://en.wikipedia.org/wiki/Embarrassingly_parallel. Which means that it's extremely easy to make a framework that's reentrant: http://en.wikipedia.org/wiki/Reentrancy_(computing). Reentrancy gives you thread-safety by default.

Yeah, Ruby core data structures are not thread-safe. But that doesn't matter. You're not supposed to a lot of any data structures between requests anyway. Of the few that are shared (e.g. the Rails cache object), they are explicitly engineered to be thread-safe.

There's also the story that Ruby cannot use multi-core. That's partially correct: on the MRI implementation, it doesn't matter how many threads you have, only one can be active at a time. However what you can have is multiple processes, each with multiple threads. Each process can use a different core. Furthermore, the JRuby and Rubinius implementations can handle multi-core with multithreading just fine. Both Phusion Passenger and Puma support JRuby and Rubinius.

Maybe I'm just too familiar with Ruby and multithreading, but I don't understand why people have trouble with multithreaded Ruby. In my eyes it's pretty easy. If you have a library that's not thread-safe, then just don't share that library's objects between threads, or ensure that you grab a lock before using that object, and you'll be fine. In my opinion, the situation is not much different in Python, Java or C++.

A new section has just been added which compares memory usage.

The advantages depends on the workload. For a lot of applications, i.e. applications with CPU-bound, fast-running requests, multi-process behind a buffering web server (Phusion Passenger default style, Unicorn style) is fine and works great. Don't move away from that. When it comes to this kind of workload, both Phusion Passenger (open source and Enterprise alike) and Unicorn work better than Puma. While Puma can be configured to use 1 thread, Phusion Passenger still has better management tools and fault-tolerance features than Puma, while Unicorn also has better fault-tolerance features than Puma.

For applications that utilize more blocking I/O though, e.g. applications that perform a lot of HTTP calls, you need a multithreaded or an evented app server, as well as an app written to support that concurrency style. Otherwise you will run out of concurrency very soon, and your app will spend a lot of time waiting on I/O instead of doing useful work.

That is not the conclusion. As you can see in the comparison, the pros and cons between Phusion Passenger open source and Puma are different. Depending on your needs, either Puma is better, or Phusion Passenger open source is better. That is not the same as a tie.

But we are claiming that the Enterprise version is better than the both of them, with that one exception as documented on the page.

However this should not be interpreted as us abandoning the open source version in favor of the Enterprise version. We are continuously developing the open source version as well. Since the launch of Phusion Passenger Enterprise, the open source version has gained quite some improvements as well.

EDIT: after re-reading the conclusion, I see that it is kind of useless. Other than promoting Enterprise, it didn't say anything substantial. I've reworded the conclusion so that it's hopefully more useful for those who are not interested in Enterprise.