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 throttling 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"
        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

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"
        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>
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 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.
Table 3. Available throttling bandwidth configurations
Option Default Value Description

incoming-limit

0 (unlimited)

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

outgoing-limit

0 (unlimited)

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

The following example limits the incoming and outgoing traffic to 1 KBs.

Limiting bandwidth
<?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

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.

Table 4. Available limiting connections configurations
Option Default Value Description

max-message-size

268435456 (256MB)

The maximum allowed MQTT message size.

The following example shows how to configure a global maximum message size of 1 MB:

Limiting bandwidth
<?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

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.

Limiting plugin service calls
<?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

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.


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