Throttling and Limits

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 restrictions element where all global throttling can be configured.

Limiting connections

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. [1].

Table 1. Available limiting connections configurations
Option Default Value Description

max-connections

-1 (unlimited)

The maximum allowed MQTT connections.

The following example shows how to configure HiveMQ to allow a maximum of 100 concurrent connections:

Limiting concurrent connections
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
   <restrictions>
       <max-connections>100</max-connections>
   </restrictions>
    ...
</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

The rates of allowed MQTT CONNECT packets per second can be configured.

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.

Table 2. Available connect overload protection configurations
Option Required Default Value Description

connect-rate

true

-1

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.

connect-burst-size

false

<connect-rate> * 2

The maximum amount of simultaneous arriving CONNECT messages that the listener will accept and process. This can not be set to 0 (zero).

Connect overload protection example xml
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <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>
Connect overload protection example

A system validates connecting clients using an external API which needs on average 1.5ms per request. Additionally our ping round trip time from broker to the API is 600ms.

It is prudent to not exceed a saturation of more than 80% of the capabilities of the API to avoid stochastic queueing catastrophe.

This means for the <connect-rate>:

  • 1.5ms / request ⇒ 667 request / s

  • 667 / s * 80% = 533 / s

  • <connect-rate>530</connect-rate>

For the <connect-burst-size>:

At least as long as the processing lag:

  • 667 / s * (0.6 + 0.0015) s = 400

Additonal grace of 100%:

  • 400 * 2 = 800

  • <connect-burst-size>800</connect-burst-size>

Throttling bandwidth

You can configure HiveMQ to globally throttle the incoming 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.

Available throttling bandwidth configurations

Option Default Value Description

incoming-bandwidth-throttling

0 (unlimited)

The maximum incoming traffic as bytes per second (b/s).

The following example makes the incoming traffic unlimited.

Limiting bandwidth
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
   <restrictions>
        <incoming-bandwidth-throttling>0</incoming-bandwidth-throttling>
   </restrictions>
    ...
</hivemq>

QoS 0 Message Ordering

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.

Connection Timeouts

MQTT, as layer 7 protocol in the OSI layer model, relies on TCP and so it’s required for clients to open a TCP connection before they can send a MQTT CONNECT message to initiate the MQTT connection.

The fact that MQTT operates at application layer means that just because a client initiates a TCP connection, doesn’t necessarily mean that it initiates a MQTT connection. So malicious MQTT clients could drain server resources by opening a TCP connection and never initiating a MQTT connection by sending a MQTT CONNECT message. These kind of clients can attack your MQTT broker by draining all system resources (like memory) quickly.

To avoid these kind of attacks, it’s important that you disconnect clients which don’t initiate a MQTT connection as soon as possible.

HiveMQ by default waits 10 seconds for the CONNECT message of a client before it closes an open TCP socket. You can tune this behaviour to your application needs.

Available throttling bandwidth configurations

Option Default Value Description

no-connect-idle-timeout

10

The time in seconds where HiveMQ waits for a CONNECT message of a client before it closes an open TCP socket.

Change the idle timeout
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
    <!-- Disconnect idle clients after 10 seconds -->
    <restrictions>
        <no-connect-idle-timeout>10000</no-connect-idle-timeout>
    </restrictions>
    ...

</hivemq>
Clients with a slow connection
If you have clients which use a network with very high latency, a few seconds might not be enough and these clients could get disconnected although they try to send a CONNECT message. So make sure the timeout fits your use case.

1. This is only true if your license allows unlimited connections. Otherwise you are restricted to the maximum connections which is defined by your license