Stress Test Report

1. Machine Preparation

Prepare two servers: one deploys the FastBee server-side application, and the other acts as the client load generator. Details:

1. FastBee server (1 unit)

• System: TencentOS Server 2.4 (TK4)
• CPU: 4C
• Memory: 16GB
• Bandwidth: 15Mbps
• MQTT Broker server: EMQX 5.7.2

2. Load generator (1 unit)

• System: OpenCloudOS 8 (Tencent Cloud Lighthouse)
• CPU: 4C
• Memory: 8GB
• Peak bandwidth: 200Mbps
• Load testing tool: emqtt-bench-0.4.18-el7-amd64.tar.gz

2. Stress Test Steps

1. Pull the stress test branch code (dev-yace), compile the jar package, and run it
2. Create a script rule and modify the published message content

import cn.hutool.json.JSONArray;
import cn.hutool.json.JSONObject;
import cn.hutool.json.JSONUtil;
import cn.hutool.core.util.NumberUtil;
                                                
// 1. Get the topic and content (required)
String sysPayload = "";


// 2. Data conversion (handle it yourself)
JSONArray newArray = new JSONArray();
JSONObject newObject = new JSONObject();
newObject.put("id","temperature");
newObject.put("value","18");
newArray.add(newObject);
sysPayload = newArray.toString();


// 3. Return the new data (required)
msgContext.setSerialNumber("D1ELV3A5TOJS");
msgContext.setPayload(sysPayload);

3. Optimize system tuning

• Server side:

// Modify system parameters to expand the available port range
sudo sysctl -w net.ipv4.ip_local_port_range="1025 65534"
// Maximum number of file handles allowed system-wide
sudo sysctl -w fs.file-max=2097152
sudo sysctl -w fs.nr_open=2097152
sudo echo 2097152 > /proc/sys/fs/nr_open
// Number of file handles allowed for the current session / process
sudo ulimit -n 1048576
// Allow reusing ports in the `TIME_WAIT` state
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

• Load generator:

// A test client server can create at most 65000 connections on one interface
sysctl -w net.ipv4.ip_local_port_range="500 65535"
echo 1000000 > /proc/sys/fs/nr_open
ulimit -n 100000

4. Execute the stress test commands

// Message publish command
// 20k client connections, one 1-byte message every 3300 ms, starting with 1000 clients (20k connections, 6k QPS)
./emqtt_bench pub -t /41/D1ELV3A5TOJS/property/post -h 1.14.207.123  -s 1 -q 0 -c 20000 -I 3300 -n 1000

// Pure connection command
./emqtt_bench conn -h 1.14.207.123 -p 1884 -u sunrain -P sunrain -c 60000 -i 10

3. Stress Test Results

3.1. Scenario 1: 20k client connections, one 1-byte message every 5000 ms, 4k QPS

The final test results are as follows:

3.2. Scenario 2: 20k client connections, one 1-byte message every 3300 ms, 6k QPS

The final test results are as follows:

3.3. Scenario 3: 20k client connections, one 1-byte message every 3300 ms, 6k QPS

With 10 additional subscribers, tested without CPU resource limits, at 8c and 16c The final test results are as follows:

• 8c:

• 16c:

4. Stress Test Summary

1. The recommended configuration for stable standalone operation is: CPU: 8c, memory: 16G, bandwidth: 10Mbps; achievable performance: 20k client connections at 4-6k QPS
2. Under the recommended configuration, 20k-30k client connections can be supported, with stable QPS processing capacity of 4k-6k. If the system requirements exceed this performance, consider the cluster version
3. It is recommended to switch to a better-performing MQTT client: mica-mqtt. paho-mqtt has a risk of disconnection under high concurrency, which can lose data.
4. When devices have high-frequency property publishing requirements, the subscribe and publish built-in MQTT clients can be separated to reduce message blocking and improve connection stability.