Is there a "best" rails server to use for development (mongral, webrick, etc..)? Or does it not really matter?
Short answer: develop on what you will deploy on.
Long answer: good Rails containers, like Unicorn, Thin, etc, really don't impact your development much but will impact production. And, each has just enough configuration related quirks that interact with your code and choice of gems that just diving in and working in that environment can save a lot of time, even if using continuous integration, but especially if not.
The "best" in my opinion is Passenger in conjunction with your choice of Apache or nginx, whichever you're familiar with. It's perhaps the only game in town when it comes to getting an application running quickly and reliably. The Phusion team has invested a lot of time and effort into building a complete package for a scalable deployment platform.
Mongrel is only designed to be part of your stack and requires a number of supporting pieces to work properly. It also has to be managed with a separate process launcher and that can be frustrating and can cause serious issues if done wrong. Mongrel2 is a better platform but will need some time to be properly assimilated by the Rails community.
Webrick was never intended as a production web server. It is only a toy server for testing. It is painfully slow and can only service one request at a time.
See my answer here Recommendations (and Differences) between different Ruby on Rails Production Web Servers
Related
I find it easy to find resources on amazon/online to learn new frameworks/programming languages. However, when it comes to web app deployment, I find it really hard to find a single resource that explains all. Most of them just tell you what to do without explaining 'why'.
I just did my second rails app deployment with unicorn and nginx. Although I 'kind of' know what is going on when reading the tutorial, I would like to know more about the 'how' and 'why' of the steps that were given.
In short, I would like to read books/articles/tutorials (hopefully all-in-one) about best practices for web app deployment, and how to scale/load-balance your app when it gets more traffic (and hopefully it the tutorial uses NGINX/unicorn setup).
Well, deployment and scaling are completely orthogonal topics, so I don't think you'll find an article/tutorial that covers both.
As for deployment, you better automate your work. When you deploy to 100+ servers, the last thing you want to do is to do it manually (fetch from git, migrate db, restart servers, etc).
Capistrano - very well known and adopted tool for deploying Rails.
Vlad - another tool that gains more attention lately.
Chef - very powerful tool for server management. Several top Russian sites use it.
I've been playing around with Rails (version 3) for a few months now and I understand the framework fairly well. However, I have yet to develop a large website which offers lots of database access and user interaction.
I'm fairly skeptical of the following:
The Speed and Scalability of Ruby (I've heard that its up to 10 times slower than most other server-side languages).
The extra background processing that Rails as a framework (multiple levels of abstration).
The lack of enterprise-level web apps that run on Rails (the only ones that I can think of Groupon, Github and Hulu).
The complexity of the environment (nginx > mongrel > rails > ruby > website).
The behind-the-scenes SQL operations (I know that these can be optimized, but I'm sure that I'll miss some).
For these reasons, I'm unsure whether to continue using Rails or to switch to something that is built ontop a more performant language .. say Java Spring.
Please advise :)
There are tons of large sites and infrastructures in production that use Rails. This question has also been asked to death over the years of Rails being actively used for all manner of web apps, large and small.
Short version is that it is not the fastest language around but despite that scales fine if you know what you are doing. And you should have enough money to hire people that know what they are doing if you actually have any problems of scale.
Scaling any webapp is hard, use the language/framework you know. Programmer happiness is king.
You can get good performance with Ruby. Easy:
require 'inline'
inline :C do |builder|
builder.c <<-C_CODE
void run() {
// Write your entire application in C here
}
C_CODE
end
run
Problem solved ;)
Not the speed and scaling discussion again?
In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.
While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.
The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.
Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?
If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.
And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.
Is it true that with passenger (mod_rails), the deployment of Rails is fairly simple? But how about how practical it is, considering it in the competitive software field? Is it true that if deploying Python or PHP framework based website, it can cost just a fraction of a Rails deployment? I am sure there will be a time when Rails deployment is very comparable to other frameworks, but I'd like to get some idea in the highly competitive software field, how competitive Rails is, compared to Python or PHP based frameworks, supporting similar concurrent user requests.
Naturally using something like PHP will require less setup, because apache/{insert_web_server_here} doesn't have to hook into a middleware just to run the application. All it needs is to load php module and it's off and running.
However, I wouldn't let that scare you away from deploying Rails applications. Passenger really makes it easy, as it literally walks you step by step via the command line, and tells you what to put in certain Apache config files etc.
Another advantage of using Passenger is that it uses REE(Ruby Enterprise Edition) in that it is significantly faster than MRI due to their enhanced garbage collection solution etc.
I have 4 servers behind a load balancer and a staging server, a db server, and a utility server for a web application that hosts a number of web sites.
Should I make the jump to Chef to manage these servers or should I just maintain them manually? The servers were built using sprinkle but at that time there were only two. Now that there are four maintenance is becoming more of an issue.
I'd like to hear experiences and the pros and cons of chef and other chef-like tools.
Thanks!
We moved to Chef, and we now have a 1 minute redeployment for our app. So it certainly pays off.
However it took a long time (a few months) to get to the point where we were happy with the chef deployment strategy. With hindsight we would have had several spare boxes around to try out a 'from scratch' deployment. I certainly wouldn't advise trying chef in a production environment without an exact mirror of the setup and lots and lots of tests, nor would I advise using chef on a setup that hasn't been 'cheffed' from scratch.
Having said that, Chef is far better than the other options we looked at and now that we are out the other side it's a breeze deploying a new version of the app on multiple servers. In future I'll be using it for any staging or production environment I have.
In summary, yes, but only if your client/employer is aware that it may take some time before they see the benefits, which will be considerable.
Chef has a steep learning curve, so it will take a while - at least a few weeks - to become familiar with how to use it.
But once you pick up the basics, it is a very handy system, and can simplify any number of tasks - even for the smallest of infrastructures.
A few notes for when you start.
You will be setting up and tearing down cloud servers dozens of times, just to get the hang of it. Experiment.
The standard opscode cookbooks (github.com/opscode/cookbooks) are very useful. But you will need to extend/customize many of them for your particular case. And you will need to search the 'net for cookbooks that are missing from the opscode/cookbooks repository.
Read the opscode cookbooks, and read the 37signals cookbooks too.
The application and database cookbooks are geared towards standard Rails apps with MySQL and Memcached. To the extent that this describes you, you are way in luck.
I've used straight Mongrel, I've used Mongrel clusters behind Apache, I've looked at Thin, and I'm becoming very intrigued by Passenger. I've looked at Nginx, too. I've looked at MRI, Ruby Enterprise Edition, Rubinius, and JRuby. There are a lot of options, each claiming to be the new holy grail.
What is the best option out there for a brand new, fully up-to-date deployment? The only assumptions are this:
The app is Rails 2.2 based. (I know 2.2 isn't fully released yet, but neither is this deployment.)
The server is Linux-based. Probably Ubuntu Hardy, but really, whatever works best in this case.
Rails will need to be fully functional and probably talk to a MySQL database.
Everything else is negotiable.
Given these especially broad constraints, which combination of software will yield the best result, in terms of concurrency and low overhead?
I'm leaning toward Apache with the "worker" mpm and Passenger + Ruby Enterprise Edition, simply because it offers immediate stability and simplicity of setup and maintenance.
Am I likely to be particularly better off with another option?
I switched from Mongrel Cluster to Passenger two weeks ago (Debian Linux Server). I didn't look back for a second. Passenger is probably the easiest way to get your new server up and running. Performance and reliability are reasonable too.
Personally, I like to spend my time working on exciting new Rails projects rather than dealing with deployment issues - Passenger enables me to do exactly that. However, Mongrel or something else may still be preferable if you have some kind special requirements (doesn't apply for most products).
This morning, DHH talks about this very topic on his own blog:
But somehow the message of Passenger has been a little slow to sink in. There's already a ton of big sites running off it. Including Shopify, MTV, Geni, Yammer, and we'll be moving over first Ta-da List shortly, then hopefully the rest of the 37signals suite quickly thereafter.
So while there are still reasons to run your own custom multi-tier setup of manually configured pieces, just like there are people shying away from mod_php for their particulars, I think we've finally settled on a default answer. Something that doesn't require you to really think about the first deployment of your Rails application. Something that just works out of the box. Even if that box is a shared host!
http://www.loudthinking.com/posts/30-myth-1-rails-is-hard-to-deploy
Tobias Lütke on the topic of switching Shopify (million requests/day) to Passenger:
All this means that the total amount of memory that is used by Shopify during normal operations went from average of 9GB to an average of 5GB. We evenly distributed the savings amongst more Shopify processes and more memcached space which moved our average response time from 210ms to 130ms while traffic grew 30% in the last few months.
In conclusion: I cannot see any reason to choose a different deployment strategy at this point. Its simple, complete, fast and well documented.
http://blog.leetsoft.com/2008/11/15/passenger
We've been using the old standard nginx -> mongrel stack for the last 18 months, and although it was not trivial to set up the first time around, it's proven flexible, and has dealt with some very high traffic sites for us. Nginx in particular has been absolutely rock solid and fast, and if you can get your app page-caching you can deal with a lot of requests.
Stuck mongrels have been an issue, so we use monit to kill them when they misbehave. Again, it was not totally trivial to set up, but we've used the same process on many many sites at this point.
We haven't played with passenger yet, so perhaps it's easier and more stable, I'll defer to the other responders on that one, all I can say is that there's no reason at all you can't build a solid stack with nginx and mongrel.
We have switched fron NginX+Mongrel to Passenger.
I fully believe that Passenger is going to be the new standard for rails, despite NginX and Mongrel cluster being endorsed by some very smart people. Recent advances in Passenger have really propelled it forward.
Our current configuration is something like this:
Web servers
Ubuntu 8.04 LTS
Phusion Passenger on Apache2
MRI Ruby 1.8.6 and friends (form apt)
Ruby Gems 1.3.0 (Installed from source)
Database servers
Centos 5
MySQL Cluster (we just switched to this, but it is promising)
Having standardized on the exact linux distro we've been able to write Capitrano recipes to help deployment (slight variations in configuration have been the source of MANY service outages) and otherwise simplify our lives.
Have a look at Litespeed. You can get a free version that runs on 1 cpu or pay to get multi cpu. It is a bit expensive but is rock solid and handles rails brilliantly (i.e. uses less memory and is less of an overhead to monitor and setup). I run a massive amount of apps on it and it doesn't miss a beat.
We also switched from Mongrel to mod_passenger and found stability greatly improved with this effort required to setup and maintain. Good choice.
Another bit of gold:
Josh Peek's Slicehost gem is full of Capistrano recipes that are much simpler and much more organized than Deprec. Nothing in there is especially Slicehost-specific, either.
I'm hosting my new apps with Apache2 and Passenger on Ubuntu Hardy. Seems like the easiest and best option for most scenarios. I have just joined Slicehost.com for that purpose. They seem to get good reviews and have the most competitive prices of first class hosts.
I can't really endorse them yet because I'm a new client but the set of guides and range of support options is impressive.
What you are not mentioning is how large and popular your app is/will be. This criteria could affect the decision process.
Capistrano + Deprec for actually setting up my stack on Ubuntu and physically managing the deployment.
Nginx proxying to Mongrel clusers for the server architecture. It isn't the newest, bleeding edge technique but it works well, it is getting well-documented, and it is very, very high performance even when working on small VPSes. Assuming you haven't borked the application you can Slashdot a 128 MB Slicehost VPS and it just keeps coming back for more.
Having said that: there were a lot of gotchas the first time around, until I figured out how Nginx actually worked. After that its amazing -- like a little Apachelet with a slight Russian accent.