Proxy pass location inheritance

[Brian Hill]

Are there any performance implications associated with having a large number of static prefix locations? We really are looking at having hundreds of location blocks per server if we use static prefixes, and my primary concern up until now has been maintainability. If I eliminate maintainability as a concern, the next question that comes up is performance. How much of a performance hit (if any) will I take if my config files have 150 or 250 locations per server block, instead of the 5 or 10 that I've limited myself to until now? Will the increased parsing cause any major performance problems? 
 
As I was looking over my config files, it occurred to me that it would be fairly straightforward for me to write a frontend to generate the server blocks and locations automatically, which would eliminate my worries over maintainability. If having a large number of location blocks isn't going to harm performance, I may just go that route. If I'd spent the last few days writing a tool to generate the static config locations instead of wrestling with regex, I'd be done right now. 



-----Original Message-----
From: nginx-bounces at nginx.org [mailto:nginx-bounces at nginx.org] On Behalf Of Maxim Dounin
Sent: Tuesday, February 18, 2014 4:13 AM
To: nginx at nginx.org
Subject: Re: Proxy pass location inheritance

Hello!

On Mon, Feb 17, 2014 at 09:26:56PM +0000, Brian Hill wrote:

> So there is no precedence given to nested regex locations at all? What 
> value does nesting provide then?

Nesting is to do thins like this:

   location / {
       # something generic stuff here

       location ~ \.jpg$ {
           expires 1w;
       }
   }

   location /app1/ {
       # something special for app1 here, e.g.
       # access control
       auth_basic ...
       access ...

       location = /app1/login {
           # something special for /app1/login,
           # eveything from /app1/ is inherited

           proxy_pass ...
       }

       location ~ \.jpg$ {
           expires 1m;
       }
   }

   location /app2/ {
       # separate configuration for app2 here,
       # changes in /app1/ doesn't affect it

       ...

       location ~ \.jpg$ {
           expires 1y;
       }
   }

That is, it allows to write scalable configurations using prefix locations.  With such approach, you can edit anything under /app1/ without being concerned how it will affect things for /app2/.

It also allows to use inheritance to write shorter configurations, and allows to isolate regexp locations within prefix ones.

> This seems like it should be a fairly simple thing to do. 
> Image/CSS requests to some folders get handled one way, and image/CSS 
> requests to all other folders get handled another way.

See above for an example.

(I personally recommend using separate folder for images/css to be able to use prefix locations instead of regexp ones.  But it should be relatively safe this way as well - as long as they are isolated in other locations.  On of the big problems with regexp locations is that ofthen they are matched when people don't expect them to be matched, and isolating regexp locations within prefix ones minimizes this negative impact.)

> This is an experimental pilot project for a datacenter conversion, and 
> the use of regex to specify both the file types and folder names is 
> mandatory. The project this pilot is for will eventually require more 
> than 50 server blocks with hundreds of locations in each block if 
> regex cannot be used. It would be an unmaintainable mess without 
> regex.

Your problem is that you are trying to mix regex locations and prefix locations without understanding how they work, and to make things even harder you add nested locations to the mix.

Instead, just stop doing things harder.  Simplify things.

Most recommended simplification is to avoid regexp location.  Note that many location blocks isn't necessary bad thing.  Sometimes it's much easier to handle hundreds of prefix location blocks than dozens of regexp locations.  Configuration with prefix locations are much easier to maintain.

If you can't avoid regexp locations for some external reason, it would be trivial to write a configuration which does what you want with regexp locations as well:

    location / {
        ...
    }

    location ~ ^/app1/ {
        ...
        location ~ \.jpg$ {
            expires 1m;
        }
    }

    location ~ ^/app2/ {
        ...
        location ~ \.jpg$ {
            expires 1y;
        }
    }

    location ~ \.jpg$ {
        expires 1w;
    }

Though such configurations are usually much harder to maintain in contrast to ones based on prefix locations.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx