New nginx module: ngx_softlimit

Zeljko Tomic scyth at unixreich.com
Thu Jul 1 04:29:12 MSD 2010


On Thu, 1 Jul 2010 02:55:04 +0400
Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Wed, Jun 30, 2010 at 07:35:06PM +0200, scyth wrote:
> 
> > On Wed, 30 Jun 2010 20:53:58 +0400
> > Maxim Dounin <mdounin at mdounin.ru> wrote:
> > 
> > > Hello!
> > > 
> > > On Wed, Jun 30, 2010 at 06:28:51PM +0200, Zeljko Tomic wrote:
> > > 
> > > > I wrote a small, but sometimes very useful module for 
> > > > limiting the number of active connections, in a "soft" way.
> > > > 
> > > > Description and usage:
> > > > -----------------------
> > > > In situation when using nginx for serving static files and 
> > > > primarily as a proxy/proxy_cache with some slower backend 
> > > > (or even php fastcgi), limits of connections and requests 
> > > > that nginx can handle are much higher than they are on 
> > > > backend server(s).  When you know the limits of your 
> > > > backend, it is bad practice to apply those limits on nginx's 
> > > > worker_connections, because it's obvious that when limits 
> > > > are met, new requests won't come through and this leaves you 
> > > > with bad visitor experience.
> > > 
> > > It would be a good idea to clarify differences from limit_conn 
> > > module.  Right now it looks like use cases you consider are 
> > > better handled by limit_conn.
> > 
> > The difference is that limit_conn (from limit_zone module) 
> > limits the number of simultaneous connections PER IP.
> 
> No.  It limits number of simultaneous connections per variable 
> value.  You are free to use any variable, including one identical 
> for all requests.
> 
> See here for details:
> 
> http://wiki.nginx.org/NginxHttpLimitZoneModule#limit_zone
> 

I couldn't find variable which holds current number of connections, or any number of connections for that matter.


> > This is 
> > useful in many cases, but soflimit_module, as stated above, 
> > compares its limit with total number of active connections, 
> > which is different. For example, site can have 2000 different 
> > clients with 1 connection each, but backend can handle only 300 
> > without performance issues. Actual limits of course vary from 
> > site to site.
> 
> As long as you are trying to limit *backend* load - you probably 
> don't want to use number of active connections (you are talking 
> about ngx_stat_active, right? sorry, I haven't had time to read 
> your code yet) as it includes keepalive connections, connections 
> just sending requests to us and connections for non-backend 
> requests.
> 
> limit_conn limits number of currently running requests in certain 
> location (from preaccess phase till request pool cleanup) and this 
> is much closer to real number of backend connections than 
> ngx_stat_active (though it's still not perfect as it includes 
> reading request body and sending big buffered responses).
> 
> ...not even talking about multiple backends with quite a different 
> limits running behind the same nginx frontend...

I could not agree more, but there are no precise internal counters for what counts as backend connection. What I found is that there is a close relationship in real world between total active connections and backend connections (with keepalive ones), so setting the value a bit higher is not a problem. Finding the appropriate relationship is up to sysadmin, and isn't very hard to do. But as I said earlier, I will update the code to use more precise counter as soon as one becomes available. Also, next version will have "mode" setting, for users to choose which counter to use, where I'll probably cover most useful combinations.

Another thing I don't like about limit_conn is that returns error 503. Sure I can redirect such errors to "maintenance.html" page, but I prefer having "maintenance" behavior separated from regular 50x.

> 
> Maxim Dounin
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel


-- 
Zeljko Tomic <scyth at unixreich.com>



More information about the nginx-devel mailing list