JuggleIM: A Single Node Can Support Tens of Thousands of Concurrent Users
Preface
We recently ran several rounds of performance tests on JuggleIM and would like to share the data here. The performance tests were conducted on a single node, which can serve as the performance baseline for JuggleIM. The performance of the cluster version can be understood as "single-node performance x number of machines". In theory, JuggleIM cluster edition can scale horizontally without limit, so as long as enough machines are available, the cluster version's performance has no theoretical upper bound.
Looking at the stress test results, although single-node performance is sufficient to support tens of thousands of users, we must stay humble in production environments. Please be sure to use the cluster version in production.
The performance tests focused on the following scenarios: number of concurrent online users on a single node, single-chat message concurrency and maximum supported users, group-chat message concurrency and maximum group size.
Stress test environment deployment:
| Purpose | Server Configuration | Operating System | Quantity | Description |
|---|---|---|---|---|
| IM Server | 4C8G, 100G disk | CentOS 7.9 64 bit | 1 | Deploys the full IM service and its dependent storage |
| Load Generators | 4C8G, 100G disk | CentOS 7.9 64 bit | Several | Runs the client simulator as a load testing tool. Due to the single-machine long-connection limit (50,000/machine), at least 20 load generators are needed to test 1 million concurrent online users |
Concurrent Online: A Single Node Easily Supports One Million Concurrent Connections
Data interpretation: Maintaining a single long connection consumes roughly 2k of memory. Therefore, as long as the single machine has more than 2G of available memory, it can support one million long connections. For IM systems, the main pressure is on message concurrency; concurrent online is actually not a big deal.
Test objective: Verify the IM service's concurrent login capability and long-connection retention capability. Long connections must be maintained for at least 30 minutes.
Test method: Use the built-in client simulator in JuggleIM as the load testing tool. Each load generator simulates 50,000 users, performs random logins, and records login latency.
Test results:
| Load Generators | Total Logged-in Users | Throughput | Avg. Login Latency (ms) | Failure Rate | Notes |
|---|---|---|---|---|---|
| 1 | 50,000 | 12175.9 | 4.71 | 0.00% | |
| 5 | 250,000 | 89762.1 | 13.24 | 0.00% | |
| 10 | 500,000 | 113823.4 | 55.67 | 0.00% | |
| 20 | 1,000,000 | 169829.8 | 385.2 | 0.00% |
Server resource usage:
Message Concurrency: A Single Node Can Support Tens of Thousands of Concurrent Users
Data interpretation: From message throughput and concurrency perspective, given message send/receive latency no greater than 1 second — i.e. imperceptible to the human eye — the single-node message-per-second concurrency is no less than 3000. Reaching this level of concurrency requires at least 50,000 concurrent users. Therefore, JuggleIM on a single node can easily support 50,000 concurrent users.
Test objective: Simulate a large number of users using the system simultaneously, with users sending and receiving messages at random, to verify message concurrency and message-receive latency.
Test method: Simulate 50,000 users logging in at the same time. The message senders are randomly selected from these 50,000 users, and the number of selected senders gradually increases, to verify message throughput, success rate, and latency.
Test results:
| Total Users | Senders | Message Size (chars) | Message Latency (ms) | Throughput | Failure Rate | Notes |
|---|---|---|---|---|---|---|
| 50,000 | 1,000 | 100 | 136 | 974 | 0.00% | |
| 50,000 | 2,000 | 100 | 332 | 1863 | 0.00% | |
| 50,000 | 3,000 | 100 | 835 | 2927.3 | 0.00% | |
| 50,000 | 5,000 | 100 | 1832 | 4328 | 0.00% |
Server resource usage:
Group chat scenario: a single node supports a 50,000-person super group
Data interpretation: In group chat, the pressure is on distributing messages to online group members. For large groups, the ratio of total members to online members is roughly 20:1, and even for very active groups, the ratio does not exceed 10:1. Therefore, with message latency around 1 second, JuggleIM on a single node can support a maximum group size of 50,000.
Note: For super groups (communities), functional degradation is generally applied — disabling read receipts, adding message-send rate limits, disabling multi-device message sync, and other resource-heavy features. With these features turned off, a single group on a single node can support up to 100,000 people.
Test objective: Simulate a realistic 50,000-person large group scenario to verify message throughput and receive latency.
Test method: Create a 50,000-person large group, simulate different scales of online group member interactions, send new messages, receive old messages, and verify message throughput, success rate, and latency.
Test results:
| Group Size | Online Members | Message Concurrency (msg/s) | Message Latency (ms) | Failure Rate | Notes |
|---|---|---|---|---|---|
| 50,000 | 1,000 | 963 | 185 | 0.00% | |
| 50,000 | 2,000 | 1924 | 563 | 0.00% | |
| 50,000 | 3,000 | 2837 | 1353 | 0.00% | |
| 50,000 | 5,000 | 3298 | 2074 | 0.00% |
Server resource usage:
Chat Room Scenario: A Single Node Supports a 100,000-Person Live Room with Real-Time Interaction
Data interpretation: JuggleIM on a single node can easily support a chat room with 100,000 concurrent users and real-time interaction.
Test objective: Create a large-scale chat room with concurrent online users, simulate real-time interactions among users, and verify message throughput, success rate, and latency.
Test method: Create a chat room, simulate 10,000 / 20,000 / 50,000 / 100,000 users interacting in real time, and verify message-receive success rate and latency.
Test results:
| Concurrent Online Users | Message Latency (ms) | Throughput | Notes |
|---|---|---|---|
| 10,000 | 634 | 9845 | On a single node (4C8G), the difference in performance loss for chat rooms under 100,000 users is small; CPU usage remains below 80%. Message latency is stable — it does not increase as the number of users grows, nor does it decrease as the number of users shrinks. |
| 20,000 | 589 | 18872 | |
| 50,000 | 597 | 42396 | |
| 100,000 | 753 | 89327 |
Server resource usage:
JuggleIM official site: https://www.jugglechat.com