在Intel i7 9750H、16GB RAM在Docker 環境下測試，其中使用 eclipse-mosquitto:2.0.11 Image 作為MQTT broker。由於MQTT v5的版本在Open Source 社群上並未完整支援，以Eclipse MQTT 社群為例，目前完整支援MQTT v5的只有Java、Python、C/C++等三種。
但實際使用Java、Python 發現並未完全支援，只有C語言有完整支援，如下圖所示。因此在實驗的部份採用Mosquitto 所提供的mosquitto_pub 作為Publisher；使用npm 平台的mqtt v4.2.6版本作為Subscriber進行實做。由於Nodejs該模組在publish 的部份，會因Nodejs中的Event 排程受到影響，因此只使用Subscriber 功能。
實驗分為兩種測試，吞吐量測試(TPS)、精準度測試(QoS)。吞吐量測試分為Publisher與Subscriber 兩種角色，在_Publisher 的配置以1、3、5、7、10 個Publisher 進行測試；Subscriber 同 Publisher ，分成1、3、5、7、10 個 Subscriber的場景配置，將發送100萬個封包計算平均每秒的吞吐量。精準度測試的部份，配置分成1、3、5、7、10 個 Subscriber_與1個 Publisher進行測試，將發送100萬個訊息，平均計算每個Subscriber收到的數量。
吞吐量測試(TPS): TPS = Requests/Per Second
精準度測試(Qos) Precision= sum(Correct Request)/Requests
-
測試1- [1, 3, 5, 7 ,10 ] publisher + 1 subscriber
當Publisher 增加時，Publisher TPS 明顯的下降，但Subscriber TPS 則線性成整且QoS不變，代表著mosquitto不會因為封包數量變大，造成不一樣的Qos。換句話說Client (Publisher) 之間並不會互相影響Subscriber所收集到的資訊。
-
測試2- 1 publisher + [1, 3, 5, 7 ,10 ] subscriber
當Subscriber 增加時，Publisher TPS 並沒有什麼改變，且Subscriber TPS、QoS也不變，代表著mosquitto不會因為封包數量變大，造成不一樣的Qos。換句話說Client (Subscriber)之間並不會互相影響。
-
測試3- 1 publisher + 1 subscriber，以一次1000、10,000、40,000、70,000、100,000 送出訊息，達1,000,000 條訊息後，紀錄TPS、QoS取平均值。
在Publisher當一次傳輸的封包變少時，TPS、QoS 會以指數的方式成長。一次的數量超過極限的吞吐量，則會造成Subscriber QoS下降，因為mosquitto 預設機制為當QoS > 0時，broker內部給單一個Client的內存queue封包數量為1000條訊息。因此只要超過一定的吞吐量會造成QoS降低。同時訊息數量大，會造成壅塞的情形，使Publisher、Subscriber 的 TPS 受到影響。
Subscriber 與 Publisher 都以QoS 為2的狀態下盡情測試，mosquitto 以預設值進行量測。發現MQTT v3.11、v5 並未有明顯差異，且v5的效能些微比v3來的弱一點。 且透過上述實驗可得到以下幾點結論:
- 使用MQTT時，未必將QoS調整到越高越好，由於當QoS > 0時 Broker將會限制client緩存Queue，就有可能發生Publisher 送出的資料被Broker捨棄的問題，以致實際QoS降低。
- MQTT Broker並不這麼適合用來當Micro Service中的Broker，由於無法正確預期資料的傳輸，有可能因此導致重要的錯誤。
- 在大部分情況建議MQTT的QoS設置為0會更好，由於MQTT本基於TCP，因此保證其一定會送至或傳輸到目的地。然而若 QoS > 0則會因為一些確認機制導致變慢，使得TPS、QoS 不如預期。
結論
MQTT v3.1.1 和 MQTT v5 效能並未有大的差異，且v5的版本提供更多的功能。雖然官方文件上所述QoS的實作方面有受到調整，但經過測試後並未有大的差異，但市場上的所提供的工具目前很少，相信未來MQTT v5的版本是比v3.1.1來的更好更實用的