Currently, amqpprox supports two types of limit: connection rate and data rate limits for connecting clients. This PR implements total connection limit(allowed total number of connections) for connecting clients.
The limit will be applied at vhost level. So each vhost will have separate counters to maintain the existing number of connections. The limit can be configured using existing control command LIMIT. By default, amqpprox will not configure any limit for vhost. Using LIMIT control command, one will be able to configure total connection limit per vhost or default total connection limit for all the vhosts. After configured total connection limit, violating client connections will be closed with some async sleep(~750ms) during AMQP handshake. So the limited connections will not hit the broker in any way.
The total connection limit has high priority over connection rate limit. So basically, it is possible that any particular connection might not be violating connection rate limit, but it might violate total connection limit. And in that case, the proxy will limit that connection. If the total limit is configured after already existing connections for any vhost, then the limit will ignore those extra existing connections. So for example, if there were x connections already, when the total connection limit y configured for particular vhost, then the actual limit for that vhost will be x+y. The control command also allows to configure limit in alarm only mode. In alarm only mode, the violating client connection will not be closed. But amqpprox will log at warning level in case of any limit violation with AMQPPROX_CONNECTION_LIMIT as a substring, which can be used to set an early alarm for the clients.
Performance Tests
Testing by setting up amqpprox as per the performance tests README.md, and running the perf tester like:
Currently, amqpprox supports two types of limit: connection rate and data rate limits for connecting clients. This PR implements total connection limit(allowed total number of connections) for connecting clients.
The limit will be applied at vhost level. So each vhost will have separate counters to maintain the existing number of connections. The limit can be configured using existing control command LIMIT. By default, amqpprox will not configure any limit for vhost. Using LIMIT control command, one will be able to configure total connection limit per vhost or default total connection limit for all the vhosts. After configured total connection limit, violating client connections will be closed with some async sleep(~750ms) during AMQP handshake. So the limited connections will not hit the broker in any way.
The total connection limit has high priority over connection rate limit. So basically, it is possible that any particular connection might not be violating connection rate limit, but it might violate total connection limit. And in that case, the proxy will limit that connection. If the total limit is configured after already existing connections for any vhost, then the limit will ignore those extra existing connections. So for example, if there were x connections already, when the total connection limit y configured for particular vhost, then the actual limit for that vhost will be x+y. The control command also allows to configure limit in alarm only mode. In alarm only mode, the violating client connection will not be closed. But amqpprox will log at warning level in case of any limit violation with AMQPPROX_CONNECTION_LIMIT as a substring, which can be used to set an early alarm for the clients.
Performance Tests
Testing by setting up amqpprox as per the performance tests README.md, and running the perf tester like:
Results in seconds. Testing was done inside docker on physical machine having 6 2.6 GHz cores CPU and 32 GB RAM.
This shows there isn't any significant performance issue with this code change.
TODO: