Nested Locations Better???

[Igor Sysoev]

On Sat, Feb 12, 2011 at 02:33:31PM -0500, Dayo wrote:
> 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 ...
> 
> [code]
> location /set/subset/ {
> 	abc;
> }
> location /set/ {
> 	xyz;
> }
> [/code]
> 
> ... and wrote it like this in his response ...
> [code]
> location /set/ {
> 	location /set/subset/ {
> 		abc;
> 	}
> 	xyz;
> }
> [/code]
> 
> 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?

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 Sysoev
http://sysoev.ru/en/