On Saturday, November 16, 2013 4:15:39 PM UTC+4, Hongli Lai wrote: > With "the Unicorn model" I believe you are referring to the supervising, > preforking server model, in which there is a master process that sets up > the server socket, and then forks off multiple worker processes that each > one listen on that server socket. The kernel then load balances requests > between the worker processes. This single server socket is then attached to > Nginx in the form of a reverse proxy. In a proper implementation of this > model, a crashing worker process will be automatically restarted. > Sounds much like built-in cluster module. In fact, it sounds exactly like built-in cluster module. Thanks, I understand now what it means. :)
> First off, full disclosure: I am one of the Phusion Passenger authors. > This "Unicorn model" is almost exactly what Phusion Passenger implements. > It supervises all your processes. It restarts them when they crash. > pm2. forever+cluster. Nothing new here. It allows you to scale the number of processes up and down with ease. It > provides I/O security by buffering your requests and responses. > I fail to see where security is added. Only thing buffering does is that it adds memory consumption, not security. How's Passenger any different compared to using 'cluster', pm2 etc and then > attaching the result to an Nginx reverse proxy? Well, Passenger drastically > reduces deployment complexity, and adds important production features that > you can't easily get by just attaching Node to Nginx: > If you want to reduce deployment complexity, you can just bind your node app to 80th port. Nginx is there to increase flexibility, add failovers and all that stuff. All this complexity nginx adds is necessary, and you can't really reduce it without losing flexibility. It's not apache, it's not haproxy, nginx config is already as simple as it can possibly be. > > - Using Passenger is much easier. If you do it yourself, you’ll have > to write reverse proxy rules, write init scripts, etc. The result probably > does not even handle corner cases properly, like race conditions, stale > PID > files, etc. Passenger takes care of all this for you and handles virtually > all the corner cases. This reduces the number of moving parts and reduces > complexity. > > I believe pm2 does all that. Not quite sure because I prefer to write reverse proxy rules and init scripts by hand to get a better understanding of the system. So, nothing really new here. > - Passenger integrates much deeper into Nginx than a straight reverse > proxy does, and as such can leverage Nginx features much better. For > example, the load balancing and response buffering in Phusion Passenger is > much better than the one you get with manual reverse proxying. > > 1) Load balancing is done using 'cluster' module. It is as good as it could possibly be. If it's not, I'm sure node core team will accept a patch. 2) Best buffering is non-existent buffering. Reverse proxy shouldn't even do that except for a very good reason. > > - By using Nginx’s proxy module, it’s very hard to see what’s going on > with the system right now. Are all connections ok? Are all processes ok? > Phusion Passenger provides simple and powerful administration tools that > can help you with that. > > It has nothing to do with nginx proxy module. Both forever and pm2 allow to monitor processes, and pm2 has a nice json api on top of that to develop custom admin tools. > Passenger is proven technology: it's already being used by the likes of > New York Times, Pixar, AirBnB, Apple, American Express, Juniper, etc as > well as over 350.000 > websites<http://trends.builtwith.com/Web-Server/Phusion-Passenger> > . > Over 350000 Ruby websites, right? Because I don't remember it being used in any more or less widely known node.js applications. > > I see that there are some misunderstandings about Passenger. It is not > true that Passenger requires Nginx recompilation. The fact is: > > - Passenger provides a Standalone > mode<http://www.modrails.com/documentation/Users%20guide%20Standalone.html>. > You configure Passenger through command line options. Passenger Standalone > is powered by an internal Nginx core and you get all the Passenger > features. This Nginx core is fully internal and is precompiled -- you > don't > have to recompile your existing Nginx! Because it's powered by this Nginx > core, you can choose to directly expose it to port 80, and it's > immediately > production ready. You can also attach it to an existing Nginx using a > reverse proxy if you want to integrate it into your current infrastructure. > > Wait, wait... Are you distributing your own patched nginx version? It doesn't sound simple at all. But I admit, a suggestion about using "nginx -> passenger -> node.js" is kinda funny. I guess 3 servers instead of 2 really reduce complexity. > - Passenger provides an *optional* Nginx integration > mode<http://www.modrails.com/documentation/Users%20guide%20Nginx.html> which > allows Passenger to start together with Nginx, and which allows you to > configure Passenger inside the Nginx config file. It's all about ease and > reducing complexity: instead of having to think and deal with yet another > software component, you just deal with Nginx and treat it as if it can > manage Node. If you want to use this mode (which you don't have to), then > Passenger must be compiled into Nginx. But even then, you don't have to do > that yourself! We provide Debian and Ubuntu packages, so it's just an > apt-get upgrade away. > > So, it doesn't exist in a standard debian repository like nginx or node.js does? Oh well... > - All of the above are available in the open source version. > > Which means that there is a non-opensource version somewhere. Which means an opensource version probably have some limitations, and if I run into it, I will be forced to buy enterprise version. Oh well... > > As one of its authors, I take pride in writing excellent documentation and > making Passenger ease and stable. I guarantee that it's fit for production. > If you're not satisfied with it, you get your money back, literally. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
