回复:Re: Can nginx has the capability to dynamically limit the connections when the upstream server has full load

tjlp at sina.com tjlp at sina.com
Sat Aug 20 08:17:28 UTC 2016


Hi, Bartenev,

Our backend server is an old product existing for more than 20 years. When a client login in to the backend server, a session is created. The session will be terminated when the client log out. To prevent the server from out of memory issue, we can configure the max allowed session number for one backend server instance. So, in the backend server instance, when the max session number is reached, no more clients can login, however, it can still serve for the client which already logined in.

So, this is different from the health check. My understanding is that full load is not equal to unhealthy. As far as I know, F5 hardware seems support such kind of requirement.

Thanks
Liu Peng
----- 原始邮件 -----
发件人:"Valentin V. Bartenev" <vbart at nginx.com>
收件人:nginx at nginx.org
主题:Re: Can nginx has the capability to dynamically limit the connections when the upstream server has full load
日期:2016年08月19日 22点06分


On Friday 19 August 2016 09:25:46 tjlp at sina.com wrote:
>  Hi,
> 
> I have a scenario: my backend servers provide URL to query whether this sever can accept new connections (the http response body is "true" or "false"). This server also has configuration for the max allowed session. Now I want to use Nginx as load balancer. Does Nginx provide such kind of load balancing configuration: when a backend server can't accept new connection, the new session won't be created for this full server?
> 
Just curious, why is it done this way?
If your server doesn't want to accept new connections,
then why it doesn't just reject them with some error code?
The commercial version of nginx is able to query such kind of URL.
See for details: http://nginx.org/r/health_check
  wbr, Valentin V. Bartenev
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160820/ef5fa396/attachment.html>


More information about the nginx mailing list