Nginx design details • Hacker News Board

Re: Nginx design details

#11

Post by mfjordvald » Sat, Jul 07, 2012, 4:21 PM UTC

leeoniya wrote: post #5

My 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'll fully grant you that the learning curve for locations is quite steep and it takes some getting used to, but the order is always logical and it's entirely possible to reason your way through it without needing verbose logs.

Re: Nginx design details

#12

Post by justincormack » Sat, Jul 07, 2012, 4:22 PM UTC

mef wrote: post #10

Another 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

The slides from a talk about it at the London Lua group the other day are here http://www.londonlua.org/scripting_nginx_with_lua/slides.htm... video coming shortly.

Re: Nginx design details

#13

Post by leeoniya » Sat, Jul 07, 2012, 4:35 PM UTC

mfjordvald wrote: post #11

leeoniya wrote: post #5

My 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'll fully grant you that the learning curve for locations is quite steep and it takes some getting used to, but the order is always logical and it's entirely possible to reason your way through it without needing verbose logs.

Perhaps you have not been thrown someone else's list of 15-20 locations and tried to determine why one was not matching, and what was being matched before it based on specificity, whether or not it was a literal or regex, whether or not it halted further matching in the order that specific type was defined.

The complexity is entirely unneeded, mod_rewrite could def use some minor convenience tweaks, but is far more intuitive and therefore more effective in both understanding and debugging. I assure you that "match in order defined, unless passed through explicitly by a sub-condition" is sufficient and simple for 99.5%.

nginx's "match literals, then match everything, then choose most specific, in the order defined by its type" is craziness, "getting used to it" does not make it good, it's simply the first unnecessary step in making it useable.

Re: Nginx design details

#14

Post by genwin » Sat, Jul 07, 2012, 4:55 PM UTC

herewego wrote: post #7

lnanek2 wrote: post #2

My 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.

Why do you use a web server (Nginx) in front of other web servers? I'm pretty new to this. Thanks.

Re: Nginx design details

#15

Post by genwin » Sat, Jul 07, 2012, 5:01 PM UTC

I've read several times about people using the Go language's (golang) web server in conjunction with Nginx. Apparently Nginx provides some benefit that Go's web server doesn't, but I haven't seen that thing called out. Can anyone tell me what it is? Thanks. (I'd also love to see a performance comparison between these two.)

Re: Nginx design details

#16

Post by ceejayoz » Sat, Jul 07, 2012, 5:19 PM UTC

genwin wrote: post #14

herewego wrote: post #7

Earlier quoted context omitted.

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.

Why do you use a web server (Nginx) in front of other web servers? I'm pretty new to this. Thanks.

I've seen situations where nginx sits in front of Apache and serves static files directly, but proxies requests for PHP through to Apache for easier setup.

Re: Nginx design details

#17

Post by tuxychandru » Sat, Jul 07, 2012, 5:44 PM UTC

genwin wrote: post #15

I've read several times about people using the Go language's (golang) web server in conjunction with Nginx. Apparently Nginx provides some benefit that Go's web server doesn't, but I haven't seen that thing called out. Can anyone tell me what it is? Thanks. (I'd also love to see a performance comparison between these two.)

I do not know about others but I do it because not mixing up web server responsibilities with application server is a good idea. For example, I leave things like gzip compression and TLS handling to nginx without having to deal with them in my app.

Re: Nginx design details

#18

Post by ObnoxiousJul » Sat, Jul 07, 2012, 6:15 PM UTC

genwin wrote: post #14

herewego wrote: post #7

Earlier quoted context omitted.

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.

Why do you use a web server (Nginx) in front of other web servers? I'm pretty new to this. Thanks.

As described, static or lighttpd for static and reverse proxy for the domain achieves more than one goal:

* you can serve page faster; * you can mix on a same domain more than one app from different servers in the DMZ (for sharing domain based mechanism (flash, Cross site ajax) by rewriting the url; * you can have one front (nginx) and several servers, which with heartbeat mechanism can handle failover. * you could (when ssl certificate were only IP based) share one SSL certificate for more than one back (VIP)

It is a pretty low cost quite scalable architecture. I guess you could do it with apache, but I dropped apache since its licence is as understandable as its configurations.

Re: Nginx design details

#19

Post by cluda01 » Sat, Jul 07, 2012, 7:57 PM UTC

tuxychandru wrote: post #17

genwin wrote: post #15

I've read several times about people using the Go language's (golang) web server in conjunction with Nginx. Apparently Nginx provides some benefit that Go's web server doesn't, but I haven't seen that thing called out. Can anyone tell me what it is? Thanks. (I'd also love to see a performance comparison between these two.)

I do not know about others but I do it because not mixing up web server responsibilities with application server is a good idea. For example, I leave things like gzip compression and TLS handling to nginx without having to deal with them in my app.

Using HTTP in general as an internal transport protocol has always struck me as odd. But I come from a financial services perspective where latency is the key driver.

Re: Nginx design details

#20

Post by mfjordvald » Sat, Jul 07, 2012, 8:06 PM UTC

leeoniya wrote: post #13

mfjordvald wrote: post #11

Earlier quoted context omitted.

I'll fully grant you that the learning curve for locations is quite steep and it takes some getting used to, but the order is always logical and it's entirely possible to reason your way through it without needing verbose logs.

Perhaps you have not been thrown someone else's list of 15-20 locations and tried to determine why one was not matching, and what was being matched before it based on specificity, whether or not it was a literal or regex, whether or not it halted further matching in the order that specific type was defined. The complexity is entirely unneeded, mod_rewrite could def use some minor convenience tweaks, but is far more i…

I've spent about 3 years doing support in #nginx. Perhaps I've just been thrown someone else's list of 15-20 locations too many times.

Locations definitely need reworking, never said they didn't, I just took issue with the having to check the verbose logs as it's perfectly possible without.