Report of Mqtt Broker Benchmark Test (Template)

1. Brokers

Single Node:

RabbitMQ 3.3.5 release
Mosquito 1.4.10 release
New Mqtt

Cluster:

RabbitMQ 3.3.5 release [4,8] nodes
New Mqtt [4] nodes

2. Mqtt in LineWorks server NCS

2.1 Mqtt usage in NCS

There are two kinds of mqtt clients : publisher subscriber. In LineWorks server usage, the two kinds of mqtt clients are separated,api servers which are less than 20 amount are publishers, LineWorks clients which are about 10000 amount in NCS environment are subscribers.
Figure 1 represents mqtt usage in NCS environment.

Figure 1 : mqtt in ncs environment

2.2 Statistics publish counts on ncs

date qos1 total qos1 max tps qos0 total qos0 max tps
20170118 4807211 630 545497 42
20170116 4760298 685 508954 58
20170113 4761518 684 534527 52
Figure 2 : statistics in one day

3. Test scenario

3.1 Focus on LineWorks real environment usage

We design this test scenario based on statistics of mqtt usage on ncs env.The goal of the benchmark is to evaluate the impact of the number of subscribers on MQTT server, in terms of the delivered throughtput(message rate on the subscriber side), the CPU usage of the server, and the time required to transmit a message from a publisher to a subscriber, i.e. the message transmission latency.There should be no limitation caused by the clients (affecting each other) or by the network.

The scalability test starts with a minimum of 10.000 subscribers, and tries to reach a maximum of 100.000 subscribers. The publishers send messages at a steady rate which is proportional to the subscribers amounts.

The tests do not try to reach the maximum message throughput. The goal is to show how the server scales with the number of publishers, each publishing at a fixed rate.

Figure 3: test environment

3.2 Machines infomation

The machines used for the benchmark all create on nclould, they have the same configuration listed in the table hereafter.

OS Processor RAM
centos 7.2 Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz * 4 8 GB

3.3 Test steps

A test is executed as a sequence of 3 steps:

  1. During the first step, every thread launches the publishers and the subscribers. Connections are opened.
  2. The second step starts after a time delay in order to allow the first step to be completed by every thread. Each thread publishes a message to the topic. In this way, as the total number of threads is known, each thread can handle a countdown and start publishing messages when the countdown reaches zero. Messages are asynchronously published, each message being sent by a different publisher. The message production lasts 5 minutes, which appeared to be long enough to reach a steady states.The second step ends when all the messages have been received by the subscribers. Therefore, the test also checks that there is no message lost by the server. The delivered throughput, CPU usage and message transmission latency are measured after a warmup period equal to 1 minute. The latency is measured for every published message. A timestamp is added to the payload of every message.The latency result shown by the graphics is the average of the latencies of all the messages published after the warmup period.
  3. The third step starts after a time delay allowing not to affect the measures done during the second step. During this step, subscribers unsubscribe and connections are closed.

4. test result

broker|subscriber counts(k)|publish rate(k)|payload size(byte)|qos|cpu|cpu total| latency(ms)|annotation
---------|--------------|-----|----------|--------|-------|-------|------------|----|----------
mosquito| 5 | 0.5 |10 | 1 | 100% | 100 | 180 | cpu max
rabbitmq| 5 | 0.5 |10 | 1 | 107% | 107 | 200 | connection max
rabbitmq| 5 | 0.5 |1000 | 1 | 109% | 109 | 200 | connection max
rabbitmq| 5 | 0.5 |10000 | 1 | 112% | 112 | 220 | connection max
new mqtt| 5 | 0.5 |10 | 1 | 48.8% | 48.8 | 40 |
new mqtt| 5 | 0.5 |1000 | 1 | 52.4% | 52.4 | 40 |
new mqtt| 5 | 0.5 |10000 | 1 | 57.1% | 57.1 | 50 |
new mqtt| 10 | 1 |10 | 1 | 90.3% | 90.3 | 45 |
new mqtt| 10 | 1 |1000 | 1 | 98.9% | 98.9 | 45 |
new mqtt| 10 | 1 |10000 | 1 | 106.6% | 106.6 | 50 |
rabbitmq| 10 | 1 |10 | 1 | 154% * 4 | 616 | 250 |
rabbitmq| 10 | 1 |1000 | 1 | 160% * 4 | 640 | 250 |
rabbitmq| 10 | 1 |10000 | 1 | 167% * 4 | 668 | 300 |
rabbitmq| 40 | 4 |10 | 1 | 130% *8 | 1040 | 1000 | delay max
new mqtt| 40 | 4 |10 | 1 | 137% * 4 | 548 | 40 |
new mqtt| 40 | 4 |1000 | 1 | 149% * 4 | 596 | 40 |
new mqtt| 40 | 4 |10000 | 1 | 160% * 4 | 640 | 50 |
new mqtt| 100 | 10 |10 | 1 | 198.0% * 4 | 792 | 50 |
new mqtt| 100 | 10 |1000 | 1 | 255.2% * 4 | 1020 | 50 |
new mqtt| 100 | 10 |10000 | 1 | 277% * 4 | 1108 | 60 |
mosquito| 5 | 0.5 |10 | 0 | 91% | 91 | 37 | cpu max
rabbitmq| 5 | 0.5 |10 | 0 | 78% | 78 | 57 | connection max
rabbitmq| 5 | 0.5 |1000 | 0 | 80% | 80 | 60 | connection max
rabbitmq| 5 | 0.5 |10000 | 0 | 85% | 85 | 60 | connection max
new mqtt| 5 | 0.5 |10 | 0 | 34.2% | 34.2 | 30 |
new mqtt| 5 | 0.5 |1000 | 0 | 38.7% | 38.7 | 30 |
new mqtt| 5 | 0.5 |10000 | 0 | 42.2% | 42.2 | 40 |
new mqtt| 10 | 1 |10 | 0 | 64.9% | 64.9 | 30 |
new mqtt| 10 | 1 |1000 | 0 | 71.6% | 71.6 | 30 |
new mqtt| 10 | 1 |10000 | 0 | 79.7% | 79.7 | 40 |
rabbitmq| 10 | 1 |10 | 0 | 66% * 4 | 264 | 60 |
rabbitmq| 10 | 1 |1000 | 0 | 75% * 4 | 300 | 60 |
rabbitmq| 10 | 1 |10000 | 0 | 84% * 4 | 336 | 60 |
rabbitmq| 40 | 4 |10 | 0 | 112% * 8 | 896 | 1000 | delay max
new mqtt| 40 | 4 |10 | 0 | 102% * 4 | 408 | 35 |
new mqtt| 40 | 4 |1000 | 0 | 111% * 4 | 444 | 40 |
new mqtt| 40 | 4 |10000 | 0 | 118% * 4 | 472 | 50 |
new mqtt| 100 | 10 |10 | 0 | 166% * 4 | 664 | 50 |
new mqtt| 100 | 10 |1000 | 0 | 211.8% * 4 | 847 | 50 |
new mqtt| 100 | 10 |10000 | 0 | 248.7% *4 | 995 | 55 |

4.1 qos1 (acknowledgement, not retained)

qos1_cpu.PNG
qos1_delayPNG.PNG

4.2 qos0 (no acknowledgement, retained)

qos0_cpu.PNG
qos0_delay.PNG

4.3 discuss

  1. mosquito
  • mosquito only have a single node and only use one cpu, when subscriber users are 5k, cpu reach almost 100%
  1. rabbitmq
  • when 40k user subscribe on 4 nodes, delay is increasing.
  • for 1 node, rabbitmq can establish not more than 6821 subscriber users
[irteam@dev-chenzhaoyu1.ncl ~]$ mosquitto_pub -h 10.113.236.145 -p 1884  -t 123 -q 0 -m hahaha
Error: Connection refused

[irteam@test-mqtt-cluster003.ncl ~]$ netstat -ant | grep 1884 | grep EST | wc -l
6849

 {file_descriptors,[{total_limit,81820},
                    {total_used,6821},
                    {sockets_limit,73636},
                    {sockets_used,6819}]},

3.new mqtt

  • new mqtt use less resources
  • 4 nodes can hold 100k subscribes(tps 10k)
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,983評論 6 537
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,772評論 3 422
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,947評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,201評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,960評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,350評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,406評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,549評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,104評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,914評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,089評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,647評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,340評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,753評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,007評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,834評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,106評論 2 375

推薦閱讀更多精彩內容