Nested Locations Better?

Server NGINX
1

Just noticed that in Igor’s response to an earlier query of mine on a
separate issue, he took code I had shown effectively as …

location /set/subset/ {
  abc;
}
location /set/ {
  xyz;
}

… and wrote it like this in his response …

location /set/ {
  location /set/subset/ {
    abc;
  }
  xyz;
}

I had put the first location block on top so that it would be processed
since both would match but now wondering if the nested version is more
efficient.

I had been under the impression that nested locations were to be avoided
but seeing Igor writting the code in that manner got me wondering.

Is it better to have them all independent as I had originally shown were
Nginx would match against the two in some cases and then choose the
closest match out of the two, or the second, nested version where it
will always match the broader location and then sometimes also match the
tighter location inside?

Also, how many layers deep can this go if so?

Thanks

Posted at Nginx Forum:

2

On Sat, Feb 12, 2011 at 02:33:31PM -0500, Dayo wrote:

[/code]

will always match the broader location and then sometimes also match the
tighter location inside?

If you use only locations without regexes, then you may not use nested
locations. nginx uses some kind of binary tree to match locations, so

location /set/subset/ { }
location /set/ { }

are slightly faster than nested locations. BTW you may write

location /set/ { }
location /set/subset/ { }

or

location /set/subset/ { }
location /set/ { }

  • there is no difference for nginx: it finds the longest match using
    the tree. The nested locations are better if you had to use regex
    locations. Then I usually isolate regex location inside usual location:

location /dir/ {
location ~ ^/dir/(.+)$ {
…
}
}

Also, how many layers deep can this go if so?

No limit, except memory, etc.

–
Igor S.
http://sysoev.ru/en/

3

Igor S. Wrote:

the tree.
Understood. Thanks. I’ll continue to order them as …

location /set/subset/ { }
location /set/ { }

… just to maintain consistency with what I have done before.

The nested locations are better if you
had to use regex
locations. Then I usually isolate regex location
inside usual location:

location /dir/ {
location ~ ^/dir/(.+)$ {
…
}
}

Got it. The example I was referring to had …

location ~ subset { }
location ~ set { }

… so I will nest them as per your indication in the original response

Also, how many layers deep can this go if so?

No limit, except memory, etc.

Good to know. I don’t expect to go deep than one layer anyway.

Thanks for the clarification.

Posted at Nginx Forum:

4

Hi Igor.

Igor S. Wrote:

The nested locations are better if you
had to use regex
locations. Then I usually isolate regex location
inside usual location:

location /dir/ {
location ~ ^/dir/(.+)$ {
…
}
}

How about the other way round? Non regex nested in regex?

location ~ set {
location /subset/ {
…
}
}

Not likely to be common but possible. Any views?

Thanks

Posted at Nginx Forum:

5

On Sat, Feb 12, 2011 at 04:00:36PM -0500, Dayo wrote:

location /dir/ {
}
}

Not likely to be common but possible. Any views?

You may use it, but do not see any advantage: you still have unisolated
configuration dependences.

–
Igor S.
http://sysoev.ru/en/

6

Igor S. Wrote:

You may use it, but do not see any advantage: you
still have unisolated
configuration dependences.

I see. Seems to me that there is likely to be limited benefit in nested
two regex based locations as well and that the main potential advantage
would be static and then regex. Is this correct?

Now that I have the debug compiled in, I’ll try looking there to see how
things flow as well.

Thanks.

Posted at Nginx Forum:

7

On Sat, Feb 12, 2011 at 03:47:22PM -0500, Dayo wrote:

are slightly faster than nested locations. BTW you

  • there is no difference for nginx: it finds the
    longest match using
    the tree.

Understood. Thanks. I’ll continue to order them as …

location /set/subset/ { }
location /set/ { }

… just to maintain consistency with what I have done before.

Note, that order is important for locations with regex. And this is
causes configuraiton dependences. This is why I try to avoid regexes
or try to isolate them as nested locations inside usual locations.

Got it. The example I was referring to had …

location ~ subset { }
location ~ set { }

… so I will nest them as per your indication in the original response

–
Igor S.
http://sysoev.ru/en/