What are the major gotchas and tricks when running Rails on a small slice (256MB)? What is the best server setup for cramped quarters? Passenger, Nginx, Mongrel? What is the best background task processor in this kind of environment? What do you need to watch out for? I'd love to hear the stories of people who have done this and bumped into some of the virtual walls.
I'm running Passenger on a 256mb slicehost, no problems. Much, much, much easier to set up than any other alternative. For background stuff I use Starling and Workling and Ryan Bates has an excellent screencast on how to use both together.
Nginx proxying for a couple of mongrels. Updating gems can cause you to run out of memory, but this can be solved by downloading and compiling rubygems from source. You will have no problem using cron for background tasks as it is very lightweight.
On my 256 slice I run nginx in front of a pair of thin servers. Whatever you decide to go with make sure you're using god or monit to keep your stack in check.
I suggest Passenger for it's simplicity and smallish footprint. I have that on my VPS with several domains (256MB VPS on RailsPlayground) and no problems so far. Also, the Starling/Workling combination works pretty well or you could even just use the spawn plugin if your site isn't huge (it's dead simple).
Related
I've been using Ruby Enterprise Edition and Passenger (for Apache, since I run Apache anyway for other things) for some time, but I'm wondering if there's a new trend about what to use on servers nowadays.
For example I've heard about Thin, Unicorn... I also know that 1.9.2 is faster than REE, but I wonder about RAM consumption. I'd rather have it consume less RAM even at the expense of some speed.
Thanks for all advice.
If you want minimal memory you should try Thin.
It does not have master worker as Unicorn or Passenger, thus uses less memory.
Suppose you have a very small app that needs to run on a small VM, then you can use 1 thin worker + nginx. I ran several rails 3.2 apps using Thin+nginx+postgres on 256MB VMs without swapping.
Unicorn is faster but it needs a master worker. It's good if you want to run on Heroku, you can set it 2 or 3 workers and be within the 512MB limit.
If your app is very big and you have too many long running requests, I would check out jRuby and Thinidad/Torquebox.
I converted a few apps from MRI+Sidekiq to jruby+Trinidad+Trinidad_Scheduler. I get about 100-200 req/sec using a pool of 50 threads in a trinidad server!
What I like about jRuby is that you can combine everything on one Rails Server. You can put together on the same JavaVM the cache_store with EHcache, Scheduling, Background processing and real multithreading.
You don't need to run redis, memcached, resque or sidekiq separately.
Im not saying they are not good, I love sidekiq and resque, but you can decrease your complexity by combining everything on one process and have high concurrency.
A more advanced and Enterprise solution is Torquebox, it has support for clustering and is super scalable. But I've had problems with my app crashing on torquebox, so i'm sticking to Trinidad for now.
The disadvantages of jRuby? MEmory! A Trinidad server will use minimum 512MB, up to 2-3GB ram.
Also, for Single Thread server, a single request from a rails app running Ruby-1.9.3 is about twice as fast as the same request on jRuby.
Another option is Puma, you can get full multithreading on MRI with puma. I myself could not get it stable enough on my apps.
So, it all depends on your requirements, memory usage, full threading and concurrency.
Apart from Passenger, have a look at Unicorn, Trinidad, Puma and Torquebox. Those seems to be the top rails servers right now.
There is an great book with an introduction of converting your Rails app to jRuby and deploy your app using several methods such as trinidad.
http://pragprog.com/book/jkdepj/deploying-with-jruby
The Torquebox Documentation is amazingly good. It's very detailed and explains really good how to use all Torquebox features.
http://torquebox.org/documentation/
I Hope that sharing my experience has helped.
Passenger is still extremely strong, especially being REE will naturally support 1.9 in the near future. The fact that your application can crash, however it won't affect anything else on your machine is an amazing feature to have. Deploying code is extremely easy because the server will continue to accept connections, which means less frustration/stress for you.
However, in terms of comparisons:
Here is a great resource is check out various comparisons(including memory consumption) with all the new servers.
It compares Thin, Unicorn, Passenger, TorqueBox, Glassfish, and Trinidad:
http://torquebox.org/news/2011/03/14/benchmarking-torquebox-round2/
Mike Lewis' link does a good job of comparing those different ruby servers. My personal experience has been with nginx/REE/Passenger and its been good. I haven't tried the others, so I can't comment on that.
However, I can speak on RAM usage. Your biggest savings of RAM will come from using 32-bit servers. In my experience (3x 3GB app servers), 64-bit REE/passenger processes took up to 2x as much RAM as their 32-bit counterparts. We saw a significant performance increase moving from 64 to 32 bit servers, everything else staying the same. Unless your application requires 64-bit, I would suggest running your application servers (not database) in 32-bit.
Passenger is still a very good choice to use so you are not behind the times or anything. It is also actively supported and has a very good development team that contributes a lot to the community. We have been using Unicorn and it has been very good. Our favorite functionality is to be able to upgrade apps/ruby/nginx without dropping a connection.
This is probably the silliest question today but...
The Rails team & many others recommend using passenger instead of a mongrel cluster, but I cannot find a clear list of exact benefits / advantages of this or what the potential pitfall are. Just wondering if anyone can help explain this?
Also is passenger its own server or does it use mongrel under the hood?
Thanks!
Before Passenger, Mongrel was the way to go, but a Mongrel cluster can be a nuisance to keep properly tuned. As your application grows in complexity, the memory footprint of each Mongrel instance will expand, and this can eat into available disk cache and degrade performance, so you'll have to pay close attention to the memory allocation balance on your deployments. From time to time you'll have to tweak it to add or remove Mongrels.
The other downside is you'll need to manage these Mongrel processes using some kind of launcher like monit and these can be fussy and difficult. Mongrel does not come with its own process manager.
Another serious problem is that each Mongrel is locked to a particular application and shifting loads between one app and another is very difficult to manage.
Mongrel is also dependent on an external load-balancer that you must configure yourself.
Passenger will handle launching all the Rails engine processes and will do its best to allocate memory efficiently. If you have a number of sites with conflicting priorities, Passenger will do a good job of launching servers on demand, and pruning them off when they're not used.
Passenger is also very quick to relaunch all instances of an application by looking for the tmp/restart.txt trigger file. You don't have to kill any processes or wait for a restart.
Under the hood, Passenger uses its own launcher and dispatch system. Although functionally it is similar to Mongrel, there are a number of significant performance improvements that Phusion has introduced that make Passenger significantly more memory-efficient than Mongrel.
Passenger is a complete package that just works and is surprisingly easy to manage. Mongrel is only a very basic web server.
I'm trying to run a Ruby on Rails project (redmine) on a VPS. It's working, but it takes quite a bit of RAM. The rails application has very light usage compared to the rest of the VPS. I have lighttpd running on the server as well.
I'm new to Ruby and know there are several ways to launch a webapp in Ruby. I'm currently just using webrick (and am okay with launching it by hand). Is there another way to launch a webapp that is more memory efficient?
Rails really just takes a shitload of memory, it's a damned big app. One of the things you can do is try to get Ruby Enterprise Edition installed but if you're on a VPS there's probably not much chance of that. But perhaps the best option is to drop the app on heroku and not worry about it anymore. You'll have other difficulties like setting up email to contend with but otherwise Heroku is the best thing that ever happened to rails (I think at least. Maybe Merb though :P)
If you're new to Rails, configurations, and even Linux - your best bet is Apache/Nginx + Phusion Passenger + REE. If your VPS is something you control such as Slicehost, Webbynode, Linode, or similar - then that'll be the easier route.
Slicehost articles should help you out a lot by walking you through each step of configuring your VPS. And the steps even work on other VPS hosting companies, just match up the Linux distro.
If you're really green to RoR and setting up VPSes's-es (?) and unless you need more than a 512MB slice - I agree with Chuck, start with Heroku until you hit about 3-4 dynos. And since the Redmine demo is on Heroku - you know it works!
I have a Ruby on Rails application that will be a CMS in way which means it's mostly DB intensive. I expect it to have decent amount of traffic so before designing I'm choosing what servers to use. Most important for me is performance.
I heard good things about Nginx and many developers in the Rails community recommends it my only concern about it was that its version is 0.8 which is Beta I believe so I was concerned about potential problems. What is your say?
Also, I want to decide between using Mongrel cluster or Phusion Passenger. What do you think?
I'm planning to user Ruby 1.9 as it has better performance that Ruby 1.8 and I will be using VPS to host my website.
My main things is performance even if it takes longer to setup one over the other.
Your opinion is highly appreciated.
Thanks,
Tam
I'd second for Passenger + Nginx. Very low memory and it's not too difficult to setup. What type of server are your deploying too? Specs? OS? I'd take that into consideration as well considering your available hardware. If you've got enough memory already, then it shouldn't be an issue whether its Passenger or Apache, just optimize and cache your app efficiently.
Two comments:
You can deploy any rails app to any of your mentioned servers, so no need to decide this once and for all now.
IMO mongrel clusters are no longer worth the trouble. Go for passenger on whatever server makes you happy.
Id recommend passenger nginx, the configs are nice and tidy plus the memory footprint is really low compared to passenger apache.
I read from some books that Phusion Passenger is the answer to easy Ruby on Rails deployment. But my friend said that first there was Apache + bunch of Mongrels, and then lighttpd, and then nginx, and now Passenger, and it seems endless...
he also said he uses dreamhost which uses Passenger, and sometimes he sees his request not being processed.
So I wonder if Passenger is the final answer to RoR deployment? do you use it and used the "ab" command to test if the site is doing quite well?
short answer: yes.
long answer: yeeeeeeeeeeeeeeesssssssssssssssss.
In all seriousness, Phusion Passenger and Ruby Enterprise Edition have taken out pretty much all of the pain of moving a Rails app into production. Previous approaches, including running a suite of Mongrels, required lots of setup surrounding starting, stopping, and recycling listener processes that Passenger handles transparently, or via simple Apache (or nginx) configuration options. And REE's complementary garbage collector means that forking off a new listener uses MUCH less memory, and is faster to boot (in Passenger's "smart" spawning mode).
Edit: #srboisvert makes a very good point; Passenger isn't the final answer to RoR deployment, but for now it's my favorite by far. One day, after a lot of hard engineering problems are solved, mainstream Ruby will probably move from hosting RoR using a multi-process model to a single-process model, which would make management even easier than with Passenger.
It's the best solution so far. I started deploying with FCGI and it was a pain. Then came mongrel and it was better. Then came mod_rails and it was WAY better.
Also a lot of large cool application are migrating to mod_rails including some by 37signals, so you know that's good.
I'll just end with a quote from DHH:
The one-piece solution with Phusion
Passenger
Once you've completed the incredibly
simple installation, you get an Apache
that acts as both web server, load
balancer, application server and
process watcher. You simply drop in
your application and touch
tmp/restart.txt when you want to
bounce it and bam, you're up and
running.
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!
In conclusion, Rails is no longer hard
to deploy. Phusion Passenger has made
it ridiculously easy.
(via)
Yes, it is the easiest, fastest and most efficient solution.
After a lot of problems with gems like soap4r etc. had been resolved in recent releases, Passenger is the answer to deployment questions now.
We're running Apache/mod_rails in a balanced environment with HAProxy in front of 2 servers. It's much more reliable than our previous setup using Mongrel/Aapache.
It's very easy to take control over
the amount of Passenger processes running in Apache
the amount of Passenger processes running per application
and all that without the pain of tweaking a number of config files like mod_proxy, Apache.
setting up a virtual host and adding 3 lines to your Apache config is basically enough to get it running
Matt
Final Answer? Nothing is ever the final answer.
I'd say Passenger is the current answer though.
Yes. I've been running Nginx/Passenger in front of Apache for whatever still needs PHP since they released 2.2.0 a few weeks back. Especially with Ruby Enterprise Edition, it approaches what I would call "perfect".
I guess that now people will stick to mod_rails for many years. The module is really good. Configuration is dead simple. It will be hard to replace it with some better solution. Similar to mod_php. The only key component which is missing: Windows port.
In some situations (enterprise, etc) the JVM can also be a good option.