Throttling and Limits (HiveMQ 3.4)
| This documentation is for the HiveMQ 3.4 legacy version. For up-to-date information on the current version of HiveMQ, switch to the latest version of our HiveMQ Platform documentation and update your bookmarks as needed. |
CPU, memory and bandwidth are limited resources. It can be crucial to limit the bandwidth or the maximum TCP connections HiveMQ can accept to save resources and avoid abuse by malicious clients.
All throttling and limit properties reside in the config.xml file, which has a throttling element where all global
throttling can be configured.
Limiting connections (HiveMQ 3.4)
You can apply a global connection limit to HiveMQ. That means, after a defined number of open MQTT connections, HiveMQ automatically inhibits new client connections. Limiting the connections can be pretty handy if your server hardware resources are limited.
By default, the max-connections property is set to -1, which means
HiveMQ can handle unlimited connections (setting the property to 0 also results in unlimited connections). [1].
| Option | Default Value | Description |
|---|---|---|
|
|
The maximum allowed MQTT connections. |
The following example shows how to configure HiveMQ to allow a maximum of 100 concurrent connections:
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../hivemq-config.xsd">
...
<throttling>
<max-connections>-1</max-connections>
</throttling>
...
</hivemq>If there are multiple listeners configured, be aware that the concurrent connections are global for this HiveMQ instance.
|
Connection Limits
If you set a connection limit which is higher than the connection limit defined by your license, the higher limit
will have no effect and the lower of the two limits will be used.
|
Throttling connection rates (HiveMQ 3.4)
The <connect-overload-protection> tag enables the connect overload protection feature of HiveMQ per
Listener. This is useful if your deployment makes use of extended authentication and/or
authorization systems that can only handle a certain average rate of authentications per second.
If this feature is enabled HiveMQ will accept MQTT CONNECT messages only at the configured <connect-rate> over a
sustained period of time. HiveMQ will allow short time bursts of CONNECT events up to the <connect-burst-size>.
If this limit is reached and there are still incoming CONNECT messages above the rate HiveMQ will temporary stop
reading from new sockets and finally disconnect newly connecting clients.
| Option | Required | Default Value | Description |
|---|---|---|---|
|
|
|
The maximum sustained rate of connects that the listener is able to handle per second. This depends to a large amount on the system and the authentication logic. |
|
|
|
The maximum amount of simultaneous arriving |
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="hivemq-config.xsd">
<listeners>
<tcp-listener>
<port>1883</port>
<bind-address>0.0.0.0</bind-address>
<connect-overload-protection>
<!-- 2000 C/s == 2C/ms -->
<connect-rate>2000</connect-rate>
<connect-burst-size>4000</connect-burst-size>
</connect-overload-protection>
</tcp-listener>
</listeners>
...
</hivemq>Throttling bandwidth (HiveMQ 3.4)
You can configure HiveMQ to globally throttle the incoming and outgoing network traffic for MQTT clients if you don’t want to reserve all your bandwidth for HiveMQ or if you want to artificially slow down all clients.
|
Throttling message throughput
A convenient way of limiting the message throughput of HiveMQ when you have many subscribers is to throttle the incoming traffic.
If your system resources such as CPU and RAM are at premium this is an efficient and quick way to limit the maximum incoming messages.
A sane global throttling by default can prevent resource exhaustion.
|
| Option | Default Value | Description |
|---|---|---|
|
|
The maximum incoming traffic as bytes per second (b/s). |
|
|
The maximum outgoing traffic as bytes per second (b/s). |
The following example limits the incoming and outgoing traffic to 1 KBs.
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../hivemq-config.xsd">
...
<throttling>
<incoming-limit>1024</incoming-limit>
<outgoing-limit>1024</outgoing-limit>
</throttling>
...
</hivemq>|
Throttling individual clients
With HiveMQs powerful Plugin System it is possible to throttle individual
clients based on credentials, quotas or other characteristics.
|
Limiting MQTT message sizes (HiveMQ 3.4)
The MQTT protocol itself defines a MQTT PUBLISH payload size limit of 256MB. For a majority of the M2M and IoT scenarios this is a very high limit and most clients will probably never send a message with a payload which is that huge.
An convenient way set an upper message size limit is to use HiveMQs global message size limit which does not only restrict the MQTT PUBLISH payload but any message sent to the server.
To limit the upper size of incoming messages, set the property max-message-size in the config.xml file.
The of the property is the maximum message size in bytes. 256MB is the default value as specified in the MQTT specification.
If a client sends a message which is bigger than the defined value, the server will discard the message after the threshold was exceeded and the client will get disconnected. It is not possible for HiveMQ to detect that a message size in bytes is higher than the defined value before that many bytes were really sent by the client.
| Option | Default Value | Description |
|---|---|---|
|
|
The maximum allowed MQTT message size. |
The following example shows how to configure a global maximum message size of 1 MB:
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../hivemq-config.xsd">
...
<throttling>
<!-- Throttling to 1 MB -->
<max-message-size>1048576</max-message-size>
</throttling>
...
</hivemq>|
Malicious Clients
When you don’t limit the MQTT message size, it is very easy for attackers or malicious clients to steal your
bandwidth and exhaust your servers memory when sending tens or hundreds of that huge messages at once for a longer period.
You should strongly consider using a upper limit which suits your use case best.
|
Limiting Plugin Service call rate (HiveMQ 3.4)
The rate with which plugin services may be called by each plugin can be limited. Doing so can prevent the broker from being overloaded with tasks by the plugin.
By default, the plugin-service-limit is set to 0,
which means the rate with which plugin services can be called is not limited.
Each time a plugin service method call exceeds the limit, a RateLimitExceededException is thrown.
Asynchronous services will return a ListenableFuture, that has failed with this exception.
The following example shows how to configure the plugin service rate limit to 100 calls per second.
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../hivemq-config.xsd">
...
<throttling>
<plugin-service-limit>100</plugin-service-limit>
</throttling>
...
</hivemq>QoS 0 Message Ordering (HiveMQ 3.4)
In conformance with the MQTT specification, all QoS 0 messages are delivered immediately, so they will get delivered out-of-order. The QoS 0 messages are delivered to clients in the same order as they are received by HiveMQ due to TCP ordering guarantees, but this does not necessarily mean that a QoS 2 message is received by a client before the QoS 0 message, even if HiveMQ receives the QoS 2 message before QoS 0 message. This difference is subtle but very important.