Re: limit_conn is not limiting the number of connections in my use case

On Saturday 18 June 2016 11:49:16 matt_l wrote: > Hello, > > I have a hard time understanding limit_conn > > My NGINX has the configuration below. I would expect to see 16 connections > on the backend server 192.168.10.131 defined in the "dynamic" directive. > > Yet I see ~50-60 connections. >

limit_conn is not limiting the number of connections in my use case

Hello, I have a hard time understanding limit_conn My NGINX has the configuration below. I would expect to see 16 connections on the backend server 192.168.10.131 defined in the "dynamic" directive. Yet I see ~50-60 connections. QPS:3056 Active connections: 58 QPS:

Re: Why set keepalive_timeout to a short period when Nginx is great at handling them?

Hi B.R., You raised a good point. So you are referring to the 4-tuple (source_IP, source_port, server_IP, server_port) socket limitation, correct? I just came to know about this and it's interesting. Please tell me if this understanding of mine is correct: So a server identifies a user's

Re: Why set keepalive_timeout to a short period when Nginx is great at handling them?

There is no downside on the server application I suppose, especially since, as you recalled, nginx got no trouble for it. One big problem is, there might be socket exhaustion on the TCP stack of your front-end machine(s). Remember a socket is defined by a triple and the

Why set keepalive_timeout to a short period when Nginx is great at handling them?

I read something interesting today: "Keep alive is a HTTP feature which allows user agents to keep the connection to your server open for a number of requests or until the specified time out is reached. This won’t

Re: What exactly does keepalive_timeout work?

Hi Richard, thank you for your reply. Since posting on this mailing-list I've come across some very good (and credible) descriptions of Keep-Alive, and the best thing is that they are all in agreement, i.e. no conflicting views. I'll quote them here as a note to self and for everyone; they

SSL handshake failed with mutual TLS

Hello everyone. I'm setting up an internal web server that will accept requests from another systems (mostly enterprise-ish something) authenticated with client certificates. We've successfully configured interaction with two of these systems (all with mutual TLS), and when pointed another one