Why Do We Need Nginx with Thin on Production Setup

Why do we need nginx with thin on production setup?

As stated by Michael nginx balances thin (whatever that means). But another reason to use nginx in front of any ruby server is to serve static files (if you use page caching, they also can be served by nginx), which means requests wont even touch your ruby app, and increase a lot your performance. Also nginx although it seems to be the popular choice on the ruby/rails community, there are other alternatives like apache.

Is it necessary to use Nginx when deploy a Rails API ONLY app?

See basically, Unicorn or thin are all single threaded servers. Which in a way means they handle single requests at a time, using defering and other techniques.

For a production setup you would generally run many instances of unicorn or thin ( depending on your load etc ), you would need to load balance b/w those rails application server instances, thats why you need Nginx or something similar on top.

Why do I need Nginx with Puma?

Nginx is a web server and puma is an application server.
Both have their advantages, and you need both.

Some examples:

• Static redirects- you could setup your nginx to redirect all http traffic to the same url with https. This way such trivial requests will never hit your app server.

• Multipart upload- Nginx is better suited to handle multipart uploads. Nginx will combine all the requests and send it as a single file to puma.

• Serving static assets- It is recommended to serve static assets (those in /public/ endpoint in rails) via a webserver without loading your app server.

• There are some basic DDoS protections built-in in nginx.

Thin + Nginx Production ready combination for RubyOnRails Application

If you have a single server I think that the main key is, apart from everything already mentioned, is don't skimp on the specs of it. Trying to get too much to run on too little is just a recipe for disaster.

It is also a good idea to get monit or God monitoring your thin instances, I started out with God, but it leaked memory pretty bad on Ruby 1.8.6 so I stop using it in favour of monit. Monit is written in C I believe and has a tiny memory footprint so I'd recommend that one.

If all that seems like a bit much to keep nginx and thin playing nicely you may want to look into an all in one solution like Passenger or LiteSpeed. I have very little experience with these so can offer no substancial advice for them.

Is it bad/pointless to setup a Nginx/Unicorn/Rails local dev environment if I want faster speed?

A big reason that Rails is slower in the development environment is that it reloads all your models, controllers, etc on every request. Everything is pre-loaded on production. That being said, webrick is very slow and I find that using thin in development is much faster.

To use thin, simple add it to your Gemfile:

group :development do
  gem 'thin'
end

When you fire up the server it should tell you it is using thin. If it doesn't you may have to specify it manually:

rails server thin

How do I configure nginx correctly to work with my Sinatra app running on thin?

You have to tell nginx to proxy requests to your Sinatra application. The minimum required to accomplish that is to specify a proxy_pass directive in the location block like this:

location / {
  proxy_pass http://localhost:4567;
}
        

The Nginx Reverse Proxy docs have more information on other proxy settings you might want to include.

Nginx + Thin config on Windows for Rails app

You are correct that you must start thin up on a new port due to the fact that nginx is already running on that port. It is generally best to start a server that is not the one that users should directly access on the loopback interface so that users can't access it, therefore the command to start up thin should be something like:

rails server thin -b 127.0.0.1 -p 3000 -e production

After doing that, you should change your upstream block to be:

upstream mywebapp_thin {
  server 127.0.0.1:3000;
}

That said, if you do not have multiple upstreams, you gain nothing by using the upstream module. You should just proxy_pass directly to your upstream. As it is, 0.0.0.0 is not a valid IP address, so that is likely why you are unable to access anything.

I also notice that you do not have www.mywebserver.com or webserver.com in the server_name directive, not sure if you left that out on purpose.

What does the error log say when you make a request? If these changes don't fix your problems, you'll probably need to post the error log as well as your full config.

On a side note, if you are deploying on Windows, you might consider using JRuby and using trinidad as a server instead of thin, or using warbler to package your app so that it can be deployed on your Java application server of choice. This doesn't change anything with your nginx configuration, though.

Rails production server (thin): pages occasionally load slower

The following document describes about how to deploy rails application in windows. I haven't done this personally but, believe the latest versions should allow that. Please check the below link to see how it can be done

http://weblog.rubyonrails.org/2006/5/11/deploying-rails-on-windows-servers/

Which one of these is a better option to use alongside latest rails application? Mongrel, Thin, WEBrick and Passenger

Dipak already answered half of your question but let me clarify on things a little bit. (I am one of the Phusion Passenger authors.)

• WEBrick is a toy web server. Nobody uses it in anything but development because it performs poorly and is said to leak memory.
• You said Thin worked well. Have you already set it up in a reverse proxy configuration? Because that's what people do in production scenarios. It is not safe to expose Thin (or Mongrel, or Unicorn) directly to the Internet.
• You may be interested in reading Ruby on Rails server options and the Phusion Passenger architectural overview for more etailed explanations.

When it comes to scalability, there's not much difference. They all perform very similar in production, they all scale in about the same way, and any problems you encounter will most likely to be caused by your app or by Rails. Well, except for WEBrick, which you really shouldn't use in production. You may see difference in hello world benchmarks, but that will be all. In production use most of the time will be spent in the app so any minor speed differences visible in hello world benchmarks will become completely invisible.

There are some subtleties to be aware of though.

• Phusion Passenger provides a feature called global queuing. It solves a specific problem, explained in detail in the manual. By default Nginx and Apache proxies requests in a round-robin manner so they suffer from this problem, while Phusion Passenger does not. There are ways to get around this when not using Phusion Passenger but they require specific configuration or the installation of additional web server modules.

• The I/O model may or may not be important depending on the nature of your application. Mongrel, Thin, Unicorn, they are all multi-process single-threaded. This works great for traditional web apps which looks up stuff in the local database and renders something, but sucks majorly for apps which perform a lot of HTTP API calls or otherwise have to wait a lot on I/O. Why Rails 4 Live Streaming is a Big Deal explains this in detail.

  Phusion Passenger is also multi-process single-threaded, but Phusion Passenger Enterprise supports multithreading. Phusion Passenger Enterprise is a commercial variant of the open source Phusion Passenger, with a variety of features useful for large-scale production environments.

• In large production environments, some features become important, e.g. rolling restarts, not showing anything wrong when a deployment failed, etc. Mongrel, Thin, Unicorn, Phusion Passenger, they all expose these features to some degree, but some require more admin effort than others. For example to implement rolling restarts in Mongrel and Thin, you need quite a lot of steps in your deployment scripts. Unicorn doesn't require as many steps, but still significantly. This is where Phusion Passenger Enterprise shines: it takes all these features and turn them into a single config option. Turn the option on and the software takes care of the rest.

So, pick whatever option you think is best for your scenario.

---

Related Topics