Nginx 1.3.0 is out | Hacker News Reader

Nginx 1.3.0 is out

nginx.org

74 pointsIgorPartola35 comments

It's important to note that this is a development release, something that's not immediately apparent from the linked page. This does not replace or obsolete 1.2.0 that came out last month and it is not intended for production use. Rather, it's the first release of the new development branch that parallels 1.2.0 and will hopefully see WebSocket support added as a feature soon.

Running Ubuntu 11.04 with nginx 0.8.4 how do I upgrade to stable (1.2.0) without screwing my whole setup (multiple sites + varnish + php-fpm + memcache)?

Easily, just copy configure arguments (nginx -V) from installed version of nginx and run ./configure with them.

nginx has a ppa:

http://wiki.nginx.org/Install#Ubuntu_PPA

Question: Is there any advantage to using nginx over apache if you are not hosting a huge traffic website that uses lots of long polling etc?

It depends is the only honest answer.

However, personally I find it uses less memory, which if nothing else frees up space for other processes

Phrased another way, if Apache's performance is adequate are there any non-performance advantages to nginx?

No.

Well, I'd argue that configuration is nicer with nginx than with apache if you're running something other than php.

But the trade off there is nginx only has centralized config whereas you can do .htaccess stuff with apache, so meh.

True. But if you already have your Apache configs complete then it might not be worth switching at this point.

Not really. The standard "it depends" answer usually doesn't take personal preference and choice of language into account though. I'm used to seeing the Apache or Nginx question framed in a way that's all about performance but performance isn't everything.

Nginx configuration will probably feel a little foreign to you because you're used to Apache. There's a bit of a learning curve with Nginx too. Apache modules are something I feel are important and Nginx doesn't really have anything comparable that just works out of the box. Nginx has a large community and good docs so its not like it's hard to Google your way through any issues that crop up bit Apache has more because it's so damn common. So the more obscure the issue the harder it'll be to find the answer compared to Apache.

But then again some platforms work better with and are partial to Nginx. The Rails community is one that I can think of that seems to put a lot of effort into making it easy to run Rails apps on Nginx out of the box. I'd argue that they actually put more effort into supporting Nginx out of the box than Apache. I've heard it's easier to get multiple SSL sites working in Nginx than it is with Apache so if that's important I might look into it.

I think your background is also a factor. I'm not a server guy. I'm a programmer. I write code, put it on a server and would prefer not to get into too much detail with the server configuration. So to me, Apache feels like the better choice because any time I want to use a new framework or anything that's going to run on the server the docs are always written in a way that assumes you use Apache. It's rare that I see setup instructions that include Nginx configurations too. One exception is Passenger which goes out of its way to show you how to use it on both Apache and Nginx. I'm sure that my reasons for choosing one over the other aren't relevant to hardcore server people because they're far more well versed in how server software works than a front end dev or even a backend dev.

I also want to point out that while Nginx is fast out of the box you can still get comparable performance out of Apache. You just have to do a little homework and get your hands dirty in the confit files. I hope my answer wasn't perceived as saying one is better than the other. I just wanted to expand on the standard "it depends" answer because a need for speed and your site's traffic are just the tip of the iceberg.

I found nginx more pleasant to set up.

Some would say it is easier to setup and manage.

I would concur. I've found it easier to write an nginx config than an Apache one.

It's not ideal for basic PHP dev, what with the lack of .htaccess equivalent, but other than that, I definitely prefer it.

> I've found it easier to write an nginx config than an Apache one

I found the opposite - mod_rewrite is way more powerful and has less surprising behavior than nginx's version. nginx's "if" blocks in particular are quite hairy -- note the Wiki page name: http://wiki.nginx.org/IfIsEvil

I still see no SPDY, looks like it's still planned though.

nginx 1.3.0 isn't actually out, and they weren't actually targeting 1.3.0 for SPDY support according to this: http://trac.nginx.org/nginx/roadmap

And still no websockets. Makes me sad inside :(

It’s planned for 1.3.x: http://trac.nginx.org/nginx/milestone/1.3

Looking forward to a day when I can give Nginx another try when its feature set has matured in more directions. Its unfortunate lack of fine-grained versatility in some areas of configuration forced us to stick with Apache's httpd after trying to replace an old Apache setup with Nginx - everything looked much better in terms of resource efficiency, until we hit the problem of simply not being able to translate a few specific configuration scenarios from Apache to Nginx, forcing us to deem Nginx as a definite no-go for our case.

Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out!

I think it's because you didn't expand on the problems you experienced sufficiently.

> Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out!

I don't believe the comments had anything to do with being a zealot, but instead a curiosity: being HN, it is useful to know why a user made a technical decision.

If you could elaborate on the problem, you're much less likely to get downvoted.

No you just gave a handwave "Nginx is not all that" without supporting the assertion. You would get the same response posting "Nginx is the greatest thing since sliced bread and you should ditch httpd."

I wasn't aware that this was a Q&A or issues tracker for Nginx, which is why I never had the intent of bringing details up. My apologies for posting these things in the official Nginx resources. The sarcasm is on the house.

(Your new posts appear [dead]. You may want to petition pg and/or make a new account.)

(You're still [dead]. Look at HN from a non-logged-in computer.)

I've run into the same issues. Apache and it's modules simply do more out of the box.

It would be helpful if you explain what those scenarios are.

One problem that comes to mind is Nginx' inability to have multiple root dirs set for one and the same host depending on what location directive will be in use, for example when wanting to set unique root dirs during userdir mapping - which also happens to be something that Nginx can't do as properly as Apache. Another problem I can recall is how some configuration scenarios require an abundance of PCRE matching clauses to fulfill, which in turn causes Nginx a tangible but most noticable delay for each request that happens to match the implied regexp portion. I am not sure why this is the case, and I am not sure why it isn't so in Apache, where regexp clauses introduce no noticable stall.

For the userdir example, would the following link solve your problem?

http://wiki.nginx.org/UserDir

We used something just like that to map users' home directories, but it doesn't solve the problem of not being able to set a unique root directory for each user case. Nginx accepts just one root dir setting, and it can't be conditionally set (or overwritten in a later if-else scenario) by putting it inside a location clause. One solution is to globally set /home as the definite root for all user location cases, but this does not sit alright with me - the document root should just not sit outside the target's home.

This example uses the alias directive, which can be set inside location clauses unlike the root directive. The distinction between root and alias isn't the most user friendly, but I think this setup is effectively the same as separate roots per user. Unless otherwise configured, users will not be able to access anything directly in /home, only in the user subdirectories.

That being said, I have no problems with Apache, especially if it's already in place and working.

Alias does not change the root dir, according to Nginx documentation. This was what made us believe that through eventual exploit, it could be possible to reach the active root dir through a completely different path as set per alias. In addition to that, having an erroneous document root communicated to CGI components such as PHP or mod_perl can lead to problems. We're still following Nginx development, in case things evolve.

Newer versions of PCRE have pcrejit which should make things faster.

I tried to get pcrejit into Ubuntu 12.04 but failed

Reply on news.ycombinator.com