On Sat, Nov 16, 2013 at 8:26 AM, Alex Kocharin <[email protected]> wrote:
> > 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. :) > The Cluster module is still at stability level 1, in the docs. And the pm2 bug I mentioned that pointed me to the unstable branch was a little unsettling. > 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. > Submitting a patch to node core is incredibly daunting to me (I'm an experienced web dev, but know basically no C), so I'd really like to see the cluster module become more stable first. > >> 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. > I did misread the docs, and missed that Standalone mode is free. However, it doesn't actually feel very standalone, shipping with nginx compiled inside it -- it's the same clunky situation as non-Standalone mode! You've just made it easier to forget that the problem is there. Looking closer, I see Passenger continues to impose requirements on my app's structure (app.js, a public dir, a tmp dir). Those kinds of requirements, that either straitjacket you or force you to manage vestigial filesystem cruft, were very nice to leave behind when I moved from Passenger to Unicorn in my Ruby apps years ago, and in leaving Capistrano behind for Fabric. > 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. >> > I think Phusion really needs to re-think its approach with the Node community. After evaluating Phusion, forever, and pm2, I'm leaning more strongly towards forever or pm2 simply because they do less work, are more cleanly decoupled, and I can understand their entire role more clearly. So right now, I've got my app <http://isitchristmas.com/> deployed using forever. It's not as flexible as pm2, but some of pm2's power is clearly relying on non-stable code in Node core. It feels to me like the Node community has still not settled on some simple, stable best practices for deploying web apps. There are a few good starts that accomplish most of what people want, but there are rough edges everywhere. Maybe this is because Node came about when PaaS-es were already well established, and so services like Heroku and Nodejitsu have lowered the pressure for the community to produce these solutions and to have large numbers of people depend on them every day. -- Eric > -- > -- > 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. > -- konklone.com | @konklone <https://twitter.com/konklone> -- -- 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.
