如今許多的智能硬件應用都須要從傳感器得到相應的數據,處理後把這些數據傳遞到後端。爲了可以評估這些應用的性能,首先咱們須要解決如下的問題:java
在本次的測試中咱們使用Raspberry Pi 2 (Model B),具體的參數以下:react
Quad-core Broadcom BCM 2836 CPU後端
900 MHz服務器
1GB RAM模塊化
從網關發送消息到後端性能
咱們使用MQTT協議將信息發送到後端,使用在愛爾蘭的AWS數據中心做爲MQTT的服務器。因爲咱們的網關設定在挪威的特隆赫姆,因此傳輸的距離跨越了整個北海。測試
下圖是測試應用的配置:spa
信息將會以1,2,5…10000的信息組的模式發送,並記錄發送的時間。線程
首先,這個實驗說明了在qos=0和qos=2時的顯著的差別。在MQTT是能夠設置qos的(quality of service)。當qos=0時,信息是沒有保證送達和認證的,當qos=2時,信息是保證送達而且不會有重複。若是沒有以上的配置,qos=2時每秒平都可以送達8到9條認證的消息,而當qos=0時每秒平都可送達1000條,是qos=2時的100多倍。這並非件很稀奇的情形,主要仍是由於後者不須要花大量時間從服務器的到認證。所以,肯定一個應用須要什麼樣的qos等級是很是重要的。翻譯
純Java和反應模塊比較
咱們一樣也要在反應模塊和純Java(使用Paho)環境中建立解決方案進行比較。雖然反應模塊一樣使用的Paho核心,但和自動生成的code封裝成模塊。下面是測試的結果:
從圖中咱們能夠看到用純java應用和經過反應模塊產生jave code來推送必定數量的MQTT信息,所耗費的時間幾乎是同樣的。那就意味着generated code和programmed code同樣的高效。
使用多核心
擁有quad-core CPU的Raspberry Pi 2能夠並行相關任務。這使得網關應用更方便接收典型的傳感器的數據,咱們用單線程的模擬傳感數據測試了這一典型的應用,經過不一樣的線程來進行多項式計算和經過MQTT發佈數據。
這些任務能夠經過劃分不一樣的線程來在四核的Raspberry Pi上並行。這裏咱們選着每秒產生大約18000個傳感器事件。模塊化的多項式計算解決了每一個事件的多項式方程,並賦予每2000個事件的平均值。這些均值將會經過MQTT發佈模塊進行發佈。也就是說,將會有每秒大約9條qos=2的MQTT消息被髮布。不管MQTT發佈模塊何時報告進程消息,緩衝庫裏的BES(Buffer Eager Simple)模塊將會存儲要被髮布的生產消息。
經過java能夠將這種應用劃分紅不一樣的核。然而反應模塊卻能使得全部同步的線程更加容易的產生純淨並且可靠的應用。
本文翻譯至http://www.bitreactive.com/how-fast-can-you-publish-mqtt-messages/?utm_campaign=shareaholic&utm_medium=twitter&utm_source=socialnetwork (How Fast Can You Publish MQTT Messages?)如轉載請請註明出處
後記:以後本身也作過相似的實驗測試(一樣用的相似的板,用的雲巴的MQTT)在qos>0時速度比原做者快,可能也和距離有關吧~但基本差很少