为什么要用 Mongrel2?

我感到困惑的是,Mongrel2服务/提供的目的是什么,而 译自: 美国《科学》杂志网站(http://nginx.org)还没有做到。

(是的,我读过 手动操作,但我必须是一个太菜鸟,以了解它是如何从根本上不同于 nginx)

我目前的 web 应用堆栈是:
- 网络伺服器
- 编程语言
- FastCGI + LuaJIT: 连接 nginx 到 Lua
数据库

11012 次浏览

If you could only name one thing then it would be that Mongrel2 is build around ZeroMQ which means that scaling your web server has never been easier.

If a request comes in, Mongrel2 receives it (nothing unusual here, same as for NginX and any other httpd). Next thing that happens is that Mongrel2 distributes the task of compiling a response to n (ZeroMQ-enabled) backends, waits for them to do the work, receives results, compiles the response and sends it off to the client.

Now, the magic is with the fact that n can be any number and, that each of n can be written in any language as supported by ZeroMQ (20 or so) plus, all goes across the network so each n can be a dedicated box, possibly in another datacenter.

In other words: with NginX and all the rest you have to do scalability in your logic tier, Mongrel2 allows you to start (from a request/response cycle point of view) this right where the request hits your infrastructure, at the httpd rather than letting complexity penetrate down to your logic tier which blows complexity upwards by at least one order of magnitude imo.

You should look at the strengths of each and decide to use either or both depending on your use cases..

While, it seems that nginx does everything that mongrel2 provides in the surface, you'll find there are major differences in focus between the two.

Nginx shines as a front-end webserver, that can proxy requests to your backend webservers/appservers and also serve static content.

Mongrel2 is a slight change in the stack. As mentioned, it's power comes from it's use of zeromq as the transport layer between it and the backend appservers. It can serve dynamic request urls (app requests) and direct the compute portion of the task out to different backends using zeromq.. mongrel2 allows you to serve not just http, websockets etc, but other protocols (if you're inclined to do so) all from the same server. the user would never know that portions of the app are being served from different backends.

If your requirements for the functionality of your webapp keeps changing or you want to add things like streaming, the ability to code in different languages in the back end etc, then I would definitely look at mongrel2. Or even have a hybrid where you use nginx/haproxy/varnish for static files and caching, and everything else is directed to mongrel2.