On Wed, Feb 15, 2012 at 4:48 PM, Dean Landolt <[email protected]> wrote:
> On Wed, Feb 15, 2012 at 3:27 PM, Matt <[email protected]> wrote: > >> On Wed, Feb 15, 2012 at 3:03 PM, Dean Landolt <[email protected]>wrote: >> >>> On Wed, Feb 15, 2012 at 12:35 PM, Matt <[email protected]> wrote: >>> >>>> On Wed, Feb 15, 2012 at 12:01 PM, Chris Scribner <[email protected]>wrote: >>>> >>>>> On the topic of "why use node to service static files"... >>>>> >>>>> Because if you don't need to understand, configure, and maintain an >>>>> extra piece of software in your stack, things get simpler. >>>>> >>>> >>>> On a very basic level yes, but there are more advantages to using a >>>> front-end nginx server than there are this one downside of "it's another >>>> piece of software". >>>> >>> >>> That's a value judgement that you can't possibly make for other people. >>> Nor are you in any position to understand what is *good enough* for >>> other people's use cases. >>> >> >> I'm trying to stick to facts. But sure, if you weighed the pros of >> running a proxy front end extremely low against the con of having 1 more >> piece of software running, then you may come out with having a proxy as a >> negative. But I would hope people are aware of all the benefits before >> making that choice. Having one more piece of software in place is a con you >> have to deal with once. The rest of the benefits you gain occur all the >> time: >> >> - Ability to proxy to multiple different backends as your site expands >> (e.g. maybe even mixing technologies, such as Rack/Sinatra and Node). >> > > Proxying and load balancing, eh? That's wonderful if you can succinctly > express all your logic here in a clunky declarative config file. Yes, it's > better than apache, but let's not kid ourselves -- couldn't a lot of that > be made substantially more efficient with a more suitable tool for this > logic? So if node makes a good static file server it makes an even better > proxy. Perhaps moreso for LB. > Yes, if you want to write it all yourself, you can do this today in Node. There's some options on npm to do some of it that may also suit your needs. > - A well tested, battle hardened static file server with support for all > of HTTP already coded in (e.g. will your Node file server do > If-Modified-Since? ETags? Gzip compress on the fly? > > It could. And I suspect there'll be a lib for that (done in c) some day. > Your use of the word "battle hardened" seems to preclude the use of > anything new. That's your prerogative, and perhaps sound advice, but you're > wielding it like a sledgehammer. There's room for nuance here. > No I'm not, I'm stating the advantages of putting nginx in front of a node backend today as your deployment method, so that people here can make professional choices based on sound advice. > - When you restart or take down your Node process for maintenance of some >> sort, do your users see a spinny beachball or a nice "Site is down for >> Maintenance" page which nginx can easily deliver? >> > > And you need nginx for this? > No but you need a front end proxy. How are you going to deliver a page if node is doing all the work and you stop the process. I'm just saying nginx is good for that. > > There's probably a couple more I forgot, but those are the biggies. >> > > And each one could be accomplished with a module or a small amount of > javascript. > Of course - I absolutely don't deny that. Is that the best option for you? If so, go ahead. > > >> If node can get 10-50% faster at serving static files, then that's X >>>>> number of more deployments that don't need to complicate their >>>>> infrastructure more than it needs to be. >>>>> >>>> >>>> I can almost guarantee you there are no deployments where this is a >>>> limiting factor. >>>> >>> >>> What? Serving static files? Exactly. >>> >> >> Right. I've never once said Node is too slow at serving static files. >> Perhaps you misread my posts? >> > > No, you've consistently said that Node will never be as fast as nginx > "at serving static files". And it won't be. And we should be OK with that. > and implied that because of that you should *of course* have nginx in > front of node. It's this implication I take issue with. > Well I think this is partly why people are so mad at me here, because what I'm trying to say is nuanced and hard to express, so let me try again. 1) please don't benchmark Node against Nginx for static file serving unless you're actively working to make it faster - that is a fools game as Nginx will always be faster. 2) having a front end proxy has many advantages, beyond just being "faster at serving static files", as I expressed above. A FEP should be used in all serious professional installations, in my (strongly stated) opinion because they provide a better UX, and a better operations environment. 3) nginx makes a great front end proxy because of features like try_file, among others. > I'm not saying we should all use node for this. What I'm replying to is > your consistent, belligerent insistence that node will never be good enough > for these use cases (in spite of the evidence, including your admission > that static files aren't the bottleneck). > > That's ridiculous. > Because I've been misinterpreted, but that's probably my fault. If someone wants to write an awesome front end proxy in Node that does all those great features, and people want to use it over Nginx (despite it being slower, have fewer real world users, etc) that's absolutely their prerogative, but if you use that, see point #1 above. Matt. -- 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
