Mongrel VS. Webrick

Mongrel vs. WEBrick

For your local development, they'll both work. Mongrel is faster, more efficient, and stable. Some people (myself included) use it to host their production sites, even. Certainly okay for local development.

If you're on non-Windows, I'd suggest looking at Phusion Passenger. You can support multiple apps on your localhost without having to do a 'ruby script/server' every time you want to run something.

When running Phusion Passenger, you'll have to tail the log file yourself. mongrel will display the log in the console window, so to get that functionality you'll have to tail -f log/development.log with Passenger.

Why does Rails ship with both? History. Webrick is written in ruby, so it was the early favorite. Mongrel came along and was better, but webrick support wasn't dropped.

If you don't want to install Phusion Passenger, use mongrel. It's the default and it works.

EDIT 2009-08: I've also had good luck with thin, a drop-in replacement for mongrel. For development, it's not that big of a deal, but it'd be something to check out for production.

Difference between Nginx and Mongrel?

Both are web servers, but they do not share the same focus :

Mongrel is basically a ruby application server that presents an HTTP Interface. It does one thing, taking a request, passing it to your ruby code and serves the answer back in http. It does not handle concurrency, or any performance related feature. One mongrel means there is one ruby process that will handle requests.
Nginx is a fully featured web server, aimed at performances. It can deliver high performance on static files and can't handle Ruby, Python or any other language in a direct manner. It relies on FastGCI or proxying to other application servers to do that.

To be clear, your rails app by itself isn't directly usable, it needs what you can call a container (I suggest you read some about http://rack.github.com/), in this case Mongrel. When you run rails console, it's usually webrick, the most basic web "app" server we have in Ruby (it's part of the standard library).

Then why do we use Nginx in front ? Let's consider we use only Mongrel : we fire a mongrel instance, listening on the port 80. If your requests takes for example 500 ms to complete, you can handle 2 clients per second any nothing more. But wait that's clearly not enough. Let's fire another mongrel instance. But we can't have it listen on the port 80 since it's already used by the first instance and there's nothing we can do about it.

So we need something in front that can handle multiple Mongrel instances, by still listening the port 80. You throw in a Nginx server, that will (proxy) dispatch the requests to your many mongrel instances and you can now add more instances to serve more clients simultaneously.

Back to answering your question, having NGinx communicating to a rails server, means firing one or many Mongrel (or Thin / Unicorn, whatever server is available) and informing NGinx it has to pass the requests to them. It's a popular pattern to host rails services next to using Passenger, which basically provides a way for Apache workers to handle ruby code.

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.

Unicode routes.rb and Passenger vs. Mongrel/WEBrick Options

This is a known passenger issue.

To work around it, you need to use the following:

match "記事" => "articles#index"
match "記事/:id" => "articles#show"
resources :articles, :path => Rack::Utils.escape("記事")

This will ensure articles_path will generate the escaped routes, while still responding to the unescaped passenger ones.

Equivalent of Mongrel/Webrick for PHP Development?

You could take a look at lighttpd - that's quick & easy to install and configure with PHP.

Making Mongrel/WEBRick serve static assets with future expires header

you can try something like this :

   def get(path)
     @headers['Content-Type'] = MIME_TYPES[path[/\.\w+$/, 0]] || "text/plain"
     unless path.include? ".." # prevent directory traversal attacks
       @headers['X-Sendfile'] = "#{PATH}/static/#{path}"
     else
       @status = 403 # "403 - Invalid path"
     end
   end

Webrick as production server vs. Thin or Unicorn?

A couple important reasons

it's written in Ruby (see http://github.com/ruby/ruby/tree/trunk/lib/webrick)
Edited it doesn't have many features that a production website usually needs, like multiple workers (in particular, pre-forking, life cycle management, asynchronous handling, etc), redirects, rewriting, etc

When I mention redirects/rewrites, I'm referring to the fact that using Webrick, you have to handle rewrites at a different layer (Rack, Sinatra, Rails, custom Webrick code, etc). This requires you to spin up extra ruby "handlers" to perform your rewrite code. For a low traffic site, this may be fine as you may have pre-warmed processes doing nothing already. However, for a higher traffic site, this is extra load on the server for something that the front end servers (Apache, Nginx, etc) can handle without spinning up Ruby*, and probably orders of magnitude faster.

* for example, if you are running behind a load balancer, you could route all rewrite traffic to a server that does not have ruby installed, and let your main servers only manage the primary traffic. This rewrite traffic may be due to site changes for SEO, or something similar. Another case would be a site that has multiple components, and maybe one section is Rails, another is PHP, and rewrites are needed for both (i.e. rewrite old PHP paths to Rails)

Mongrel VS. Webrick