Continuing issues with limit_conn

[Calomel]

Maxim,

Thank you for the response. I just want to make sure I understand this
directive correctly as the Wiki seems a bit unclear. 

The ngx_http_limit_zone_module only limits the amount of connections from a
single ip address which are currently being processed by the Nginx daemon.

For example, if we declared "limit_conn gulag 1" and one worker_processes
is enabled then Nginx should only process one connection at a time
(serial). If requests are coming in faster than Nginx can process them with
the single worker, then the client will get a error 503. But, with more
workers enabled a remote ip would need to bog down all of them in order to
get a error 503. 

The ngx_http_limit_zone_module does _NOT_ limit the total amount of
connections any single remote ip can open to the server.

Does this sound correct?


  Nginx "how to"
  http://calomel.org/nginx.html

--
  Calomel @ http://calomel.org
  Open Source Research and Reference


On Tue, Apr 29, 2008 at 11:57:44AM +0400, Maxim Dounin wrote:
>Hello!
>
>On Mon, Apr 28, 2008 at 11:29:08PM -0400, Calomel wrote:
>
>>Building Nginx 0.6.29, we are also _unable_ to get limit_zone/limit_conn to
>>work as expected.
>>
>>As a test we setup the relative lines in the http and server sections. 
>>Nginx
>>should only accept ONE concurrent connection for any single ip address.  
>>
>>http{
>> limit_zone gulag $binary_remote_addr 1m;
>>   server{
>>     limit_conn gulag 1;
>>   }
>>}
>>
>>When I run "ab -c 50 -n 10000 http://testbox/" the server answers all
>>requests with response code 200. As you mentioned, this is _not_ the
>>expected behavior.
>>
>>Perhaps we are missing something? The code could be at fault or perhaps
>>something has been omitted from the Wiki and the documentation. If there is
>>a proper solution I will make sure to document it.
>
>It looks like there is some misunderstanding regarding to what 
>limit_conn actually limits.  It limits concurrent connections 
>*processed* by nginx (not keep-alive ones), and only after header 
>has been received (and thus configuration for request has been
>determined).
>
>Since nginx is event-based, with one worker process you shouldn't 
>expect requests to hit limit_conn unless they block at some stage 
>(i.e. responses bigger than socket buffers if sendfile off, 
>replies bigger than sendfile_max_chunk if sendfile on, proxy_pass 
>...).  With many workers limit_conn may be hit without blocking, 
>but this generally requires _very_ high concurrency for small 
>requests.
>
>Maxim Dounin