Nginx 1.0.0 is out
nginx.orgFor me and this big PHP application of ours, switching from just Apache to nginx in front of Apache for PHP execution and serving the rest directly with nginx was the one optimization that brought the best bang for the buck over all the years.
Memory usage went down drastically and response times got much better.
Additionally, I personally much prefer the syntax of the nginx configuration file (though this really is a matter of taste) and it generally feels like much more of the really cool stuff is built right in (I'm looking at you, memcached module).
As such, I love nginx and I would recommend it to anybody asking me what lightweight web server to use.
Note though that the performance improvements I listed above are not as such specific to nginx: You could probably achieve the same result with any other web server that isn't also your application server. What is specific to nginx is its stability, its nice (for my taste) configuration language and the availability of really interesting modules right in the core.
Congratulations to everybody for reaching 1.0. I'm looking forward to many happy years with your awesome tool in my utility belt.
I despise having to configure web servers, but a few months ago I had to set one up on my server and I chose nginx. It was a breeze to set up (though occasionally I still struggle when I need something new in the config of a specific site, but I can usually figure it out reasonably quickly and am usually surprised by how straightforward it really is (once you know how)). So far, its done everything I want and then some.
tldr; I hate web server, but I like nginx.
Congratulations to the team indeed. I'm setting up my next project in this configuration as well and I've found nginx to be a very sweet server. I'll be serving a lot of javascript and css, but using php to handle the utility chores of accessing mysql and couchdb. Even though I'm keeping the apache back-end for this, I confess it's more out of comfort and laziness (and the rush to get it out) than because of some profound technical insight on my part.
for me the reason to stay with an apache/mod_php backend was very bad experience I had with fastcgi back in the 2006/2007 area where I was using a lighttpd/fastcgi configuration.
I've seen crashes in lighty, crashes in fastcgi and subtle differences in behavior between fastcgi and mod_php.
FastCGI just wasn't a commonly used method of deployment back then, so there were for sure some bugs around that I didn't have time or interest to fix.
By now, there's PHP-FPM and fastcgi is much more common, so you could probably just hook php directly into nginx by now, but I didn't want to do experiments and I knew that apache worked, so that's what I used.
Just remember to turn off keep-alive in apache, btw.
There was a bit of chatter recently about ill-configured nginx-fastcgi servers having a php vulnerability. Seems to be summed up here:
https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...
Thanks for the keep-alive tip. I missed that one.
EDIT: I see that the author of the post I linked replied below- also with the link.
I use nginx with PHP-FPM on multiple sites and have been quite happy with the results.
I'd say it's fairly stable, as (IIRC) WordPress.com is all run off nginx.
It really is trivial to set up an fcgi process to run PHP directly from nginx.
On the nginx side, something like my config: location ~ \.php { fastcgi_index index.php; include fastcgi_params; fastcgi_pass localhost:55155; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }
Then you just need to run php in fcgi daemon mode which is built in, use php-cgi -b localhost:55155 to match that setup... more details on http://wiki.nginx.org/PHPFcgiExample
I found this much simpler than running nginx and apache...
If you do that, you have to be very careful. I actually did a writeup about this a few days ago that I posted on HN: https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...
tl:dr is that the configuration you're suggesting will leave a site open to arbitrary code execution if the site allows for user uploads.
Thats not a full config, I did reference the documentation. I have a try_files line, as fcgi runs locally as it happens.
Just use PHP-FPM instead, it's easier and scales better. I run PHP, Django/Python and Perl without a problem at a single domain. NGINX allows to run almost anything as long as you are able to attach the socket of what you want to output towards NGINX.
A socket is probably faster.
Not really the bottleneck if you are running PHP. Linux optimises most of tcp out over the loopback device anyway.
I ran into a problem with a tcp connection to php-fpm just some weeks ago: The Server served requests at a rate of about 400req/s for some time without a single problem, until I ran out of useable ports. You won't have this problem with sockets.
Is it really a team? I thought it was just Igor Sysoev :)
Fun bit: on the http://sysoev.ru/ the news starts with "Поехали!" (Let's go! / Let's ride!)—Yuri Gagarin quote from the launch of the first manned space flight fifty years ago.
Heh - off-topic, but that reminds me of a story involving the same idiom. A friend told me that in the 80s she spent some time as an exchange student in Moscow and they would go see movies on Friday nights. Occasionally there would be an American movie dubbed into Russian (all the parts played by the same Russian male voice who would read everything in a deep monotone) and one time it somehow turned out to be a trashy zombie movie. They get to the obligatory "teenagers in the cemetery in the middle of the night" scene and when the zombies appear, one of the teenagers yells "Holy shit man, let's get the fuck out of here!" This gets translated by the monotone Russian baritone as: "Пошли" (let's go).
We've had nginx in production for three years. 20 billion requests. 458 live configuration changes. A dozen or more live binary upgrades. Countless DOS attacks.
One known failure. One. Because I was an idiot and tried to do something a little too clever in our configuration.
It's one of the best pieces of system software I've ever used. I can't thank Igor and the nginx community enough.
I hadn't even considered that it wasn't at a 1.0.0 release yet! Aside from version numbers being a bit meaningless, Nginx has been an absolutely rock-solid workhorse for me for about the last 5 years.
One of my favourite pieces of software, and the things you can do with Lua as a module make it an extremely flexible intelligent proxying service.
Same for me. Nginx does everything Apache does, only with a little less clunk.
And a lot less memory usage!
I first heard of Nginx from a blog post[1] by Ezra Zygmuntowicz almost 5 years ago. I suspect Ezra was the primary contributor to the success of Nginx in the western world.
[1]: http://brainspl.at/articles/2006/08/23/nginx-my-new-favorite...
On a slightly related note, I first heard about Redis from Ezra -- probably ~2 years ago. I believe he deserves some similar type of credit for the early spread of Redis.
(His latest project cloudfoundry.com just launched today, so I think it's fairly relevant to give the guy some props right now :-)
Thanks guys ;)Glad the configs and blog posts helPed you.
How does your conclusion follow from the first sentence? It sounds like you're using your own individual experience to draw conclusions about how Nginx took off across the entire world, without any actual evidence to prove that the two are related.
Donation page: http://sysoev.ru/en/donation.html
Nginx is awesome! I hope they'll start working on SPDY-support eventually now that they've reached a stable point with no major features missing.
There are a few features missing, arguably. There is only HTTP 1.0 not HTTP 1.1 support for the proxy module for example.
I don't think nginx has support for websockets yet.
... because WebSockets requires a HTTP 1.1 server (just connecting the dots in case people didn't know this).
I doubt the server would need to implement all of 1.1 to support WebSockets. Many proxies support a subset of 1.1 while reporting as a 1.0 server (Squid was one for years, and probably still is, even though it supports a wide variety of 1.1 capabilities). I talked about this in another thread: http://news.ycombinator.com/item?id=2439406
Are you trolling? nginx supports HTTP 1.1 since I can remember
Not for the proxy module.
Does anybody know if/when Nginx will support HTTP 1.1? I'd love to be able to use Nginx as the frontend for WebSocket stuff.
What do you mean? HTTP1.1 says nothing about WebSockets, and nginx does support HTTP1.1.
Websockets uses the http 1.1 upgrade header to transform an http request into a websocket.
Nginx proxy module only supports http 1.0 basically.
So no proxying to a websocket server yet.
For what it's worth, proxying HTTP/1.1 is tremendously complex, and WebSockets are an interesting and somewhat intimidating pile of additional trouble. It's been years since I've worked on a proxy (I was a Squid developer many years ago), but since my current project will be dealing with WebSockets, it triggered an instant "I wonder how that's going to work through proxies" response, and an ingrained moment of my heart skipping a beat thinking about how complex such an implementation might become...so I went digging, and found this great thread on the Squid list:
http://www.squid-cache.org/mail-archive/squid-dev/200907/003...
If you want to skim, the really knowledgeable parties in the discussion are Henrik Nordstrom, Robert Collins, Alex Rousskov, Mark Nottingham, and Ian Hickson.
It's actually not as bad as I'd feared, but the protocol also obviously had many issues unresolved back then (and probably still, since security concerns led to it being disabled in Firefox 4 and Opera), as did the plausibility of implementing a proxy or a proxy cache that could support it.
But, to get back to nginx, it is also possible to selectively support 1.1 features without supporting the entire protocol. Squid has supported persistent connections for over a decade, but took years to get support for caching with ETag, ranges, and a number of MUST features, so it reported as HTTP/1.0 with additional capabilities (it might still do this, I haven't paid much attention since leaving the project). So, it seems plausible that someone could implement just the necessary features for WebSockets, without having to implement everything in HTTP/1.1.
Interesting thread. Yes nginx already selectively supports 1.1 features but not everything. And yes I think the current security issues are the same ones, so maybe this will never have to be solved by proxies in this form, I havent seen what the current proposals to fix the websocket issues are...
The changelog: http://nginx.org/en/CHANGES
Great to see a project that is constantly being worked on!
Averaged more than 2 releases a month last year with bugfixes and features.
An awesome web server.
until very recently, the SVN repo was not made available to the public. AFAIK, there is still no bug tracker.
Dont get me wrong, I have several production sites on nginx - but the development methodology makes me very nervous.
Cherokee has some of the same objectives as nginx (fast and lightweight) and has a very open development process.
Plus, the Cherokee Market is very cool (http://cherokee-market.com/) !
It (nginx) is bsd licensed. If you don't like the development model, you can always fork it on github, or start a company that develops and supports a closed-source fork.
Not to mention that Cherokee's configuration file format is very human-unfriendly, and its configuration utility is a GUI that requires a web browser (and port forwarding if you want to configure a server remotely, which would typically be the case outside of dev environments).
Let's say Cherokee does not force you to deal with text based, error prone configuration files. Not mention that it allows you to configure your web server safely without the need to learning an additional custom grammar.
I tried Cherokee 1 year ago trying to setup a wordpress blog on a vanilla Ubuntu install. It just didn't work so I gave up and haven't looked back.
Linus Torvalds said in 2001 he didn't use a bug tracker for the Linux kernel so I'm not sure if I should be worried.
Apache, nginx and Cherokee also work on Haiku as well as a bunch of other native ones (e.g. PoorMan http://en.wikipedia.org/wiki/PoorMan and RobinHood). nginx fits well with it because Haiku performs well under heavy load for responsiveness, is lightweight and fast.
I was hoping 1.0 would include support for dynamic modules. It's the only thing nginx is missing. I have to compile my own nginx everywhere to get all the modules I need (which isn't hard, just a tad annoying to manage).
Nine years to get to version one. Happy birthday nginx.
I've always wondered why there's such an extreme aversion for OSS to go to version 1.0, or to roll over to any major version, when commercial software has no problems going crazy with the versioning?
I want to believe that serious devs, OSS or otherwise, would be thinking about something along the lines of semantic versioning (http://semver.org/) as they bump version numbers.
Additionally, marketing likes to see the major number change (the "X" in the X.Y.Z). I think the public does too. They feel like they're getting more bang for their buck.
Bravo to the whole team. Nginx is the AK-47 of webservers: when you absolutely positively have to serve every single request, accept no alternative.
Beyond that, I've found both the built in modules and the addons to be excellent quality. I've instantaneously improved performance an order of magnitude for some applications just by dropping in nginx and a little bit of configuration. I've also created a global cdn that served hundreds of millions of video streams a month on a few commodity machines with nginx, all without a hitch.
Truly excellent software.
I've been very pleased with nginx. I switched from lighttpd and previously from apache.
Lighty is about as fast and memory-friendly as nginx, but I found nginx to be more stable when dealing with FastCGI.
A bit off topic, please consider the following example in [1]:
if ($args ~ post=140){
rewrite ^ http://example.com/ permanent;
}
I think that regex matches any string as well - ^ simply matches the start of a line and all strings have a start.
It might also be more performant because the regex engine doesn't consume the whole string before finding a match..
That is exactly right. See "Taxing Rewrites" on http://wiki.nginx.org/Pitfalls
In Soviet Russia, regex starts you.
So, Nginx is supposedly more resource-efficient and easier to configure than Apache. But I assume Apache still has advantages or abilities that Nginx doesn't have.
When would you still pick Apache? I'd love to see answers here:
http://serverfault.com/questions/258980/what-does-nginx-lack...
1.0.0 nginx is really more like a version 10.0, this thing is a real pleasure to use.
Nginx is a thing of beauty, definitely scores over Apache. - ease of use - simplified configuration, I dont need a 500pg manual to get a grasp of nginx - speed, speed, speed - what else do you want :)
Is there anything like cpanel / webmin but for managing nginx?
Yes, the Froxlor Control Panel is available specifically for Nginx.
It is on our todo list for Webmin and Virtualmin.
Any timeframe for this?
Great news. Excellent work by the nginx team. I'll second (or third) others by being surprised that it wasn't already at the 1.0.0 milestone!
"Nginx uses an asynchronous event-driven approach to handling requests which provides more predictable performance under load, in contrast to the Apache HTTP server model that uses a threaded or process-oriented approach to handling requests."
Does this mean if a crash occurs, the whole process of nginx will crash? Whereas Apache's processes can be restarted?
/Genuinely curious
Nginx uses a configurable, fixed number of worker processes, handling many connections per worker process. This allows Nginx to maximize throughput on any variety of multi-processor and/or multi-core configurations.
If one worker dies, any of the connections it's handling will close, but connections associated with the other worker processes stay alive. I'm not 100% sure, but I believe the master process will restart a worker if it dies.
All that said, I've never seen Nginx crash (except when playing around with an experimental third-party module - but never in production). For any production server, you should be using some form of monitoring daemon that will alert in case of a failure and automatically restart the web server process.
Cool thanks for the information.
why is your handle green?
I have no idea.
Usernames under 5 days old are green; part of PG's experiments on Hacker News to prevent dilution of the community.
See http://news.ycombinator.com/item?id=2434333 and http://news.ycombinator.com/noobstories
I'm looking for a nginx guru if anybody is looking for some quick, easy side work.
Sure, send me an email, it's in my bio.
Fitting that Nginx hits 1.0 at the same time as the Yuri Gagarin 50th anniversary. Here's a toast to Russian ingenuity!
Reaching version 1 is meaningless. Their versioning, like many other projects, is completely botched.
"Oh look, we're getting to the high 0.9's, better call the next one 1.0.0!"
There is some reasoning behind version numbers. Check out http://semver.org/ for more information (although I don't know if nginx actually subscribes to the semver spec)
Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.
It's mentioned elsewhere in this thread, but it's not something I knew about beforehand so figured you may also find it helpful.