11–20 of 47 posts
Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite naive and I'm working on part 2 of the post. http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...
What was naive about [your deployment section], and what needs updating?
I appreciate the compare and contrast.
Earlier quoted context omitted.
What was naive about [your deployment section], and what needs updating?
I think that he meant the deployment section in his post was naive, not yours :). I appreciate the compare and contrast.
Perhaps he meant putting Puma directly on port 80. Although I usually wouldn't do that, I am not entirely sure whether one shouldn't do that. For example Unicorn is multi-proces single-threaded so it should never be used without a buffering web server, but Puma is different. We'll need the Puma author to make a statement about this.
I'm glad the comparison was useful to you. :)
https://github.com/jrochkind/fake_work_app/blob/master/READM...
For some reason it didn't get much HN traction. But either it inspired these recent HN posts involving puma, or it's just a coincidence -- either way I'm glad to see puma getting more attention.
I think multi-threaded request dispatch (from either puma or passenger enterprise) are often the best way to maximize throughput in a web server with I/O-bound work, as the Java community has been doing for a while. Any implementation details are just minor tweaks compared to just doing multi-threaded concurrent request dispatch in the first place -- so it's no surprise to see Passenger Enterprise and puma performing similarly.
i agree with the Phusion essay, that Passenger currently has more robust admin/management/supervision features than puma. I hope puma continues to evolve, inspired by passenger
Although these features are not trivial to implement well -- I am very impresed by passenger's feature set, and very robust and reliable performance.
But if you want a free/open-source solution, or a solution that it makes sense to run on heroku -- puma is a (and the only) solid concurrent-request-dispatch solution already.
Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite naive and I'm working on part 2 of the post. http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...
What was naive about [your deployment section], and what needs updating?
For more scalable architectures I prefer putting multiple of these app instances behind a Load Balancer such as Nginx reverse proxy. That is part 2 of my post :)
I'm running Puma in production for a simple project which we have behind a Nginx load balancer.
I posted a showdown of various open source servers that can be run on heroku a few days ago, including puma, which some people interested in this may be interested in: https://github.com/jrochkind/fake_work_app/blob/master/READM... For some reason it didn't get much HN traction. But either it inspired these recent HN posts involving puma, or it's just a coincidence -- either way I'm glad to see puma getting more atte…
Just to understand what's going on in this article. The people at Phusion Passenger are comparing Puma and their offer, only to come to the conclusion that if you've got money you should go for their paying offer and if you don't then it's a tie? Not that they're not to be trusted and can't be unbiased in their judgment, but I'd put more trust in a more independent study,
Just to understand what's going on in this article. The people at Phusion Passenger are comparing Puma and their offer, only to come to the conclusion that if you've got money you should go for their paying offer and if you don't then it's a tie? Not that they're not to be trusted and can't be unbiased in their judgment, but I'd put more trust in a more independent study,
It certainly would have been more useful if it had a disclaimer at the beginning indicating that it was written by a Passenger developer. It's OK to have biases as long as you're up-front about them.
The "License and price" section at the beginning is also worded in such a way that it should be clear that the text came from the Phusion Passenger authors.
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 requ…
I think the problem is a mix of language features and culture. Ruby does not have a history good thread-safe practices, and the language has some extremely convenient features which are death for thread-safety (eg. class instance variables). Combine that with prolific meta-programming and a lack of static analysis tools, and it can become very very difficult to be certain that a given application is thread safe. As long as all developers are well-versed and keep thread-safety front and center from the beginning of application developer then I agree it's not hard per se, but in practice that is so rarely the case that if I knew I needed heavy multi-threading for memory efficiency and CPU utilization I might disqualify Ruby on cultural reasons alone (and I say this as a full-time rubyist who knows no language better).
I posted a showdown of various open source servers that can be run on heroku a few days ago, including puma, which some people interested in this may be interested in: https://github.com/jrochkind/fake_work_app/blob/master/READM... For some reason it didn't get much HN traction. But either it inspired these recent HN posts involving puma, or it's just a coincidence -- either way I'm glad to see puma getting more atte…
Thank you for that benchmark (even though it didn't cover Phusion Passenger Enterprise ;) It looks very thorough.
There are two reasons I did not include Passenger Enterprise in my benchmarks:
1. As far as I know there is no way to run it on heroku. And I was intentionally benchmarking on heroku.
2. I wasn't going to pay for it just for the purpose of running benchmarks on it.
Earlier quoted context omitted.
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 requ…
> Maybe I'm just too familiar with Ruby and multithreading, but I don't understand why people have trouble with multithreaded Ruby. [...] In my opinion, the situation is not much different in Python, Java or C++. I think the problem is a mix of language features and culture. Ruby does not have a history good thread-safe practices, and the language has some extremely convenient features which are death for thread-safe…
A web application doesn't usually share much in-memory state _between requests_ -- especially if we're talking about app-specific code and not framework code. If it does (modify class variables or other global state, etc) -- you've got to eliminate that or make it threadsafe, but that's not _that_ hard to identify. A web application is very rarely going to be doing class-modifying meta-programming _as part of request handling_ (as opposed to on boot, where it won't be a problem).
Your actual app-specific code in a web application is highly likely to be MT-request-dispatch safe already, and if not is not too hard to get it there -- and worth the effort because of the extreme throughput increases you can get with an MT-request-dispatch app server.
Now, what can definitely be trickier is framework and gem code. ActiveRecord, historically, has had quite a few problems with thread-safety under MT-request-dispatch, off and on (the database connections themselves are the shared state it's tricky to deal with, among other things). But it's gotten a LOT better and should be fairly robust now.
I know what you mean about 'cultural reasons', but I think the ruby culture has been gradually changing for a while (jruby has a lot to do with it), and some of us hope is becoming more MT-friendly.
But I'm not saying it's trivial or guaranteed problem free, but the potential gains are worth it.
(I do run a rails app that uses multiple threads and ActiveRecord.)