Nginx design details
aosabook.org
Nginx design details
1–10 of 30 posts
Re: Nginx design details
#2My one experience with this server was quite bad. The web group we contracted used it, but would constantly run into issues us developers could have helped them with had they used Apache. Things like needing to return certain headers in the request, or return certain status codes, or do certain things handled easily by Apache's large ecosystem of modules became very grueling trials full of meetings with the contractors running the thing.
Just like Java is sometimes the best language to use because it has huge mind share despite the warts, sometimes Apache is the right server to use just because that's what almost everyone uses and it makes things so much easier than using something more rare.
Re: Nginx design details
#3My one experience with this server was quite bad. The web group we contracted used it, but would constantly run into issues us developers could have helped them with had they used Apache. Things like needing to return certain headers in the request, or return certain status codes, or do certain things handled easily by Apache's large ecosystem of modules became very grueling trials full of meetings with the contracto…
Can you give concrete examples of what you couldn't do?
Here's the wiki on how to set headers: http://wiki.nginx.org/HttpHeadersModule
Here's the wiki on returning a particular http code: http://wiki.nginx.org/HttpRewriteModule#return
Re: Nginx design details
#4This is great! I didn't know that volume II has been published...
Also be sure to read the chapter about LLVM compiler family (written by LLVM creator, who is an Apple employee now): http://www.aosabook.org/en/llvm.html
It's great. A learnt a lot from that chapter.
This book (The Architecture of Open Source Application) is a treasure trove. Just look at the index here: http://www.aosabook.org/en/index.html and tell me you don't want to skip work (or school, or whatever else is you're doing) for a week to read it all :D
Re: Nginx design details
#5My only quibble with Nginx so far is the magical order in which it evaluates location directives. http://wiki.nginx.org/HttpCoreModule#location
On more than one occasion, you have to unintuitively try to figure out whether a rule at the bottom is getting matched before a rule at the top. The matching algo is quite intricate and easy to to trip up on. It tries to help novices by matching literal strings first for them rather than simply making a note of the performance benefits of putting literal locations at the top, but ends up failing to reveal the true matching order at a glance - you need to check the verbose logs, yuck.
Re: Nginx design details
#6My one experience with this server was quite bad. The web group we contracted used it, but would constantly run into issues us developers could have helped them with had they used Apache. Things like needing to return certain headers in the request, or return certain status codes, or do certain things handled easily by Apache's large ecosystem of modules became very grueling trials full of meetings with the contracto…
You would run into the same situation with contractors who used apache, if they didn't know apache very well.
Returning status codes from nginx is easy. Adding headers is easy. Perhaps you could elaborate about "certain things handled easily by Apache's large ecosystem of modules".
Apache's large ecosystem of modules is built around doing everything in the webserver. More often these days, that stuff is handled by a dynamic application. Nginx talks to those via fastcgi, scgi, uwsgi, or plain http proxying. Nginx does not need to know anything about how the apps do whatever it is they do.
Re: Nginx design details
#7My one experience with this server was quite bad. The web group we contracted used it, but would constantly run into issues us developers could have helped them with had they used Apache. Things like needing to return certain headers in the request, or return certain status codes, or do certain things handled easily by Apache's large ecosystem of modules became very grueling trials full of meetings with the contracto…
I'm curious what you issues you ran into as well. I've used it in production environments for the past few years after moving away form Apache. It was a near seamless transition for my team, myself included. We use it behind some heavy iron load balancers and in front of a dozen web servers and it's been a generally pleasant experience.
Re: Nginx design details
#8My only quibble with Nginx so far is the magical order in which it evaluates location directives. http://wiki.nginx.org/HttpCoreModule#location On more than one occasion, you have to unintuitively try to figure out whether a rule at the bottom is getting matched before a rule at the top. The matching algo is quite intricate and easy to to trip up on. It tries to help novices by matching literal strings first for them…
I think the configuration language will eventually have to be reworked to address some of the issues with magical ordering and unintuitive behavior. Making the configuration language lua, for instance, would be a huge step forward, because many complex configs already use the lua 3rd party module.
In addition to "location" eval order, "If" statements are another common gotcha.
Re: Nginx design details
#9Not in this book, but worth taking a look at if you're into reading source code for large open source projects, is Redis and Mongrel2. Both are really well written C code-bases.
Re: Nginx design details
#10Another problem with the existing worker model is related to limited support for embedded scripting. For one, with the standard nginx distribution, only embedding Perl scripts is supported.
For those looking for full featured and robust embedded scripting support in nginx, Yichun Zhang's lua-nginx-module is highly recomended. https://github.com/chaoslawful/lua-nginx-module