こんにちは、ツカノ(@snuffkin)です。
MQTT Broker 比較の第二弾です。
前回は、機能の比較を行いました。
実際のシステムへの適応を考えると、性能は特に気になるところ。
ということで、今回は性能比較を行ってみました。
ベンチマークは環境や測定方法、バージョンによっても大きく異なりますので、
あくまで一例として参考にしてもらえればと思います。
ベンチマークに利用したプログラムは、Goで開発された以下の MQTT-Bench を利用しています。
ベンチマークの条件は以下の通りです。
- 構成、メッセージ長
- MQTT Broker に対して、500connections で同時処理
- 1つのメッセージ長は 1024byte
- マシンスペック
- MQTT Broker のバージョン
計測内容
計測は、以下のパターンで行っています。
- Publish(Retainなし)
- MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainなしの場合は、最後にPublishされたメッセージをBrokerが保持しません。
- Publish(Retainあり)
- MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainありの場合は、最後にPublishされたメッセージをBrokerが保持します。
- Subscribe
- MQTT Broker から、クライアントがメッセージを受信する処理になります。MQTTの特性として、接続されているときのみメッセージを受信するため、Subscribeしている間、それとは別プロセスでPublish(Retainなし)の処理を行っています。
計測結果は、以下のグラフになりますが、グラフの縦軸は、「処理したメッセージ数/秒」です。
また、機能的に対応していない箇所はグラフを記載していません。
※RabbitMQ のQoS=1の場合のSubscribeの処理は、Publishされたメッセージが内部のキューを介するようで、今回のSubscribeの計測方法では、性能があまり出なかったため、計測結果からは除いています。
Publish性能(retain=false)
Publish性能(retain=true)
Subscribe性能
結果
- 全体として、Mosquitto/Apollo/VerneMQの性能が良いです。
- 以前は、Mosquittoの性能はいまひとつ、という話がありましが、現在のバージョンでは、他と比べてもトップレベルの性能になっているようです。
- VerneMQ は、Retainありの場合は性能が低くなる傾向がありますが、1プロセスでもトップレベルの性能になっています。クラスタ構成を組むことで、分散して処理することができるため、さらに性能を向上できる可能性があります(クラスタ構成での性能は、今回未計測です)。
さて、2回に分けて、MQTT Brokerの機能比較と性能比較を行ってきましたが、
この1~2ヶ月の間にも、MQTT Brokerがバージョンアップされて機能や性能が改善したり、
VerneMQのような新しいプロダクトがリリースされたりと、動きが大きい分野だと感じています。
これからも、IoTとともにMQTT Brokerは要注目、ですね!
Acroquest Technologyでは、キャリア採用を行っています。
- 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
- 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
- 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
- OSSの開発に携わりたい。
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
キャリア採用ページ