Fakultas Ilmu Komputer
Universitas Brawijaya
6816
Perbandingan Kinerja Redis, Mosquitto, dan MongoDB sebagai Message
Broker pada IoT Middleware
Fitri Febriyani1, Eko Sakti Pramukantoro2, Fariz Andri Bakhtiar3 Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya
Email: 1fitrifbryani@student.ub.ac.id, 2ekosakti@ub.ac.id, 3fariz@ub.ac.id
Abstrak
IoT middleware memiliki service unit yang menerapkan Redis message broker untuk menerima berbagai
tipe data. Selain menerima data, message broker perlu scalable untuk menangani banyak data dan untuk terus beroperasi walaupun terjadi kegagalan. Penelitian ini melakukan perbandingan kinerja Redis, Mosquitto, dan MongoDB sebagai message broker pada IoT middleware secara bergantian. MongoDB dipilih karena karakteristik skalabilitasnya dan Mosquitto karena kinerjanya yang stabil. Hasil pengujian kinerja, penggunaan CPU terbaik saat read data adalah Mosquitto dengan rentang 8%-62%. Penggunaan CPU saat write data, penggunaan memori, dan runtime, hasil terbaik dimiliki Redis dengan nilai berkisar 13%-41%, 53MB-64MB, dan 54MB-59MB. Kemudian runtime saat write dan read data sebesar 2,37 detik dan 0,05 detik. Pada disk i/o, MongoDB memiliki kinerja yang terbaik saat write dan read data sebesar 111 megabit dan 689 megabit. Dalam hal skalabilitas, concurrent publish terbaik adalah Mosquitto sebesar 18 pesan per detik melalui CoAP dan 15 pesan per detik melalui MQTT. Kesimpulan yang dapat ditarik adalah Redis memiliki kinerja yang baik pada penggunaan CPU saat write data, penggunaan memori, runtime, dan kecepatan menangani data yang masuk. Dari segi disk i/o dan kecepatan membaca data, MongoDB memiliki kinerja yang terbaik. Sedangkan Mosquitto memiliki kecepatan menulis data dan menangani data yang keluar.
Kata kunci: redis, mongodb, mosquitto, broker, perbandingan, kinerja
Abstract
IoT middleware has a service unit that implements Redis message broker to accept various types of data. In addition to receiving data, message brokers need to be scalable to handle a lot of data and to continue to operate despite failures. This study compares the performance of Redis, Mosquitto, and MongoDB as alternating message brokers on IoT middleware. MongoDB was chosen because of its scalability and Mosquitto was chosen because of its stable performance. The results of performance testing, the best CPU usage when reading data is Mosquitto with a range of 8%-62%. CPU usage when writing data, memory usage, and runtime, Redis has the best results with values ranging from 13%-41%, 53MB-64MB and 54MB-59MB. Then the write and read data runtime are 2,37 seconds and 0,05 seconds. On disk i/o, MongoDB has the best performance when writing and reading data of 111 megabits and 689 megabits. In terms of scalability, the best concurrent publish is Mosquitto for 18 messages per second through CoAP and 15 messages per second through MQTT. It can be concluded that Redis has a good performance on CPU usage when writing data, memory usage, runtime, and speed of handling incoming data. In terms of disk i/o and speed of reading data, MongoDB has the best performance. Whereas Mosquitto has the speed of writing data and handling data that comes out.
Keywords: redis, mongodb, mosquitto, broker, comparison, performance
1. PENDAHULUAN
Adanya teknologi IoT (Internet of Things), manusia dan komputer dapat melakukan interaksi dengan berbagai things yang terkoneksi internet secara otomatis. Namun, definisi
“things” pada sudut pandang IoT memiliki arti yang sangat luas dan sangat berkaitan dengan sejumlah besar perangkat yang terhubung ke internet (Razzaque, et al., 2016). Keberagaman bentuk perangkat IoT tersebut menyebabkan timbulnya permasalahan interoperabilitas pada
IoT. Menurut Razzaque, et al. (2016), solusi permasalahan interoperabilitas yakni dengan membangun sebuah middleware. Sebab
middleware dapat memberi kemudahan dalam
pengembangan aplikasi dengan mengintegrasikan beraneka-ragam komputasi dan perangkat komunikasi. Untuk itu, penelitian sebelumnya membangun IoT middleware yang bertujuan untuk mengatasi interoperabilitas pada IoT (Anwari, Pramukantoro, & Hanafi, 2016).
IoT middleware pada penelitian Anwari,
Pramukantoro, dan Hanafi (2016) memiliki
service unit yang bekerja sama dengan Redis.
Penggunaan Redis dikarenakan Redis dapat berperan sebagai message broker dan mendukung pola publish-subscribe. IoT middleware tersebut kemudian dilakukan pengujian dari segi semantik oleh Pramukantoro, Kusyanti, dan Yazid (2018) menunjukkan hasil bahwa IoT middleware dengan Redis sebagai
message broker dapat menerima berbagai tipe
data. Namun selain dapat menerima data,
message broker perlu memiliki kemampuan
skalabilitas agar dapat meningkatkan beban yang ditangani dan terus beroperasi walau terjadi kegagalan (Ionescu, 2015).
Terdapat berbagai jenis message broker yang dapat digunakan, yakni MongoDB, Mosquitto, ZeroMQ, dan RabbitMQ. Namun penelitian ini menggunakan MongoDB dan Mosquitto sebagai message broker. Penggunaan MongoDB karena karakteristik high
performance dan scalable yang
memungkinkannya untuk mendukung skalabilitas pada IoT middleware. Sedangkan penggunaan Mosquitto karena karakteristik kestabilan kinerjanya yang baik dalam pengiriman data memungkinkannya untuk dapat terus beroperasi walaupun terjadi kegagalan. Perbandingan Redis, MongoDB, dan Mosquitto sebagai message broker dilakukan dengan menerapkan masing-masing message broker secara bergantian pada IoT middleware yang telah dibangun di penelitian sebelumnya. Kemudian dilakukan pengujian, analisis, dan pembahasan satu persatu pada masing-masing
message broker. Hasil pengujian lalu diuraikan
untuk menjadi bahan pembahasan dalam mendeskripsikan apakah kinerja dan skalabilitas pada IoT middleware dipengaruhi oleh message
broker yang digunakan. Sehingga melalui
penelitian ini, didapatkan informasi mengenai bagaimana kinerja dari masing-masing message
broker yang diterapkan pada IoT middleware.
2. LANDASAN KEPUSTAKAAN 2.1 Kajian Pustaka
Pada penelitian penelitian Anwari, Pramukantoro, dan Hanafi (2016), dikembangkan IoT middleware dengan arsitektur seperti gambar 1 .
Gambar 1 Arsitektur IoT Middleware
Berdasarkan gambar 1, arsitektur IoT
middleware terdiri dari application gateway, service unit, dan sensor gateway. Pada service
unit digunakan Redis sebagai message broker
karena dapat mendukung pola publish-subscribe. Penelitian ini menggunakan IoT middleware yang sama dalam menerapkan
MongoDB dan Mosquitto sebagai message
broker. Kemudian dilakukan perbandingan
dengan Redis message broker yang telah diterapkan sebelumnya. Hal ini bertujuan untuk mengetahui pengaruh kinerja dari ketiga
message broker terhadap IoT middleware. 2.2 Dasar Teori
2.2.1 Message Broker
Message broker berfungsi sebagai media
yang menjembatani komunikasi antara sensor dan application gateway. Messaging mode data
transfer yang diterapkan adalah model publish-subscribe dengan tipe topic-based. Mekanisme
kerja message broker yakni data yang dikirimkan oleh publisher kemudian diterima
message broker dan diteruskan ke subscriber
berdasarkan topik yang di-subscribe.
2.2.2 Persisten/Nonpersisten
Definisi persisten/nonpersisten merujuk pada konsistensi data terhadap
memory-database. Persisten dalam hal memory database
merupakan sistem manajemen basis data yang mengandalkan memori utama untuk penyimpanan data pada komputer. Klasifikasi persisten/nonpersisten dilakukan untuk mengetahui karakteristik dari masing-masing
message broker terhadap konsistensi datanya.
Bertujuan untuk melihat apakah masing-masing
message broker dapat menyimpan data secara real-time. Sehingga jika terjadi crash pada
Fakultas Ilmu Komputer, Universitas Brawijaya
middleware maka data tetap dapat dicadangkan. 2.2.3 Kinerja
Pengujian kinerja dilakukan untuk mengetahui penggunaan CPU, penggunaan memori, disk i/o, runtime, dan skalabilitas
message broker dalam menangani sejumlah data
saat proses publish maupun subscribe.
Parameter yang diukur pada pengujian skalabilitas yaitu time publish, concurrent
publish, time subscribe, dan concurrent subscribe.
2.2.4 Redis
Redis merupakan database NoSQL yang menyimpan data dalam bentuk pasangan
key-value dan memiliki sistem in-memory dalam
pengambilan datanya (Paksula, 2010). Sehingga Redis memiliki kemampuan pembacaan data yang lebih cepat dibandingkan NoSQL lainnya. Walaupun Redis dikenal sebagai sebuah
database, tetapi Redis juga dapat berperan
sebagai cache dan message broker. Mekanisme kerja Redis sebagai message broker menerapkan model publish-subscribe, yaitu topic-based.
2.2.5 MongoDB
MongoDB merupakan database NoSQL yang dapat diimplementasikan sebagai message
broker melalui fitur capped collection. Pada fitur
tersebut terdapat fixed-size collections yang menjalankan mekanisme publish-subscribe.
Bekerja seperti buffer circular, dimana setelah
collection mengisi alokasi ruang maka terbentuk
dokumen baru dengan cara menimpa dokumen tertua dalam collection tersebut.
2.2.6 Mosquitto
Mosquitto merupakan message broker yang menggunakan protokol MQTT dalam pemrosesan mekanisme pub-sub. MQTT membutuhkan dua komponen perangkat lunak utama yaitu MQTT Client yang nantinya akan dipasang pada device dan MQTT Broker yang berfungsi untuk menangani publish dan
subscribe data. Tidak adanya ketentuan antrian
di tingkat protokol mengharuskan publisher dan
subscriber harus aktif pada waktu yang
bersamaan untuk dapat melakukan komunikasi (Patro, Potey, & Golhani, 2017).
3. METODOLOGI
Pembahasan tahapan-tahapan yang dilakukan ditunjukkan melalui metodologi
penelitian pada gambar 2.
Gambar 2 Alur Metodologi Penelitian
Berdasarkan gambar 2, metodologi penelitian dimulai dari studi literatur, pengembangan lingkungan uji, pengambilan data uji, hasil, dan pembahasan serta kesimpulan.
3.1 Studi Literatur
Studi literatur berisi penjelasan mengenai teori dasar dan penelitian terdahulu terkait dengan objek penelitian. Sumber studi literatur berasal dari jurnal, situs resmi, dan penelitian sebelumnya.
3.2 Pengembangan Lingkungan Uji
Tahap ini menjelaskan perancangan dan implementasi yang dilakukan dalam membangun lingkungan uji. Pada tahap perancangan diuraikan kebutuhan dan rancangan komponen sistem yang diperlukan. Pada sisi lingkungan sistem dikategorikan menjadi kebutuhan perangkat lunak dan kebutuhan perangkat keras. Kemudian dari sisi alur sistem terdapat kebutuhan fungsional sistem dan kebutuhan data. Aktivitas perancangan lingkungan uji terdiri dari perancangan alur sistem, perancangan program publisher,
perancangan program subscriber, perancangan
payload, perancangan IoT middleware, dan
perancangan pengujian. Sedangkan aktivitas implementasi terdiri dari implementasi program
publisher, subscriber, dan implementasi IoT
middleware. Pada implementasi IoT
middleware, terdapat tiga jenis IoT middleware
yang digunakan dalam membangun lingkungan uji. Sehingga terdapat tiga jenis lingkungan uji juga yang digunakan. Ketiga jenis lingkungan uji
tersebut ditunjukkan gambar 3, 4, dan 5.
Gambar 3 Lingkungan Uji IoT Middleware dengan Redis sebagai message broker
Gambar 4 Lingkungan Uji IoT Middleware dengan MongoDB sebagai message broker
Gambar 5 Lingkungan Uji IoT Middleware dengan Mosquitto sebagai message broker
Berdasarkan gambar 3, 4, dan 5, masing-masing message broker diimplementasikan pada
service unit sistem dan tetap memiliki
mekanisme alur sistem yang sama.
3.3 Pengambilan Data Uji
Sebelum proses pengambilan data uji, dilakukan pengujian pada masing-masing IoT
middleware dengan message broker yang
berbeda secara bergantian. Terdapat dua sumber dalam proses pengambilan data, yakni data dari hasil capture Wireshark dan data dari kode program pengujian kinerja. Data hasil tangkapan aplikasi Wireshark disimpan dalam bentuk format PCAP dan diolah untuk mendapatkan nilai time publish, concurrent publish, time
subscribe, dan concurrent subcribe. Sedangkan
data dari kode program pengujian kinerja berupa
file CSV yang berisi data log performa middleware saat proses publish-subscribe
berjalan. Kedua jenis file tersebut kemudian diubah menjadi data dalam bentuk Excel untuk
mempermudah pengolahan data.
3.4 Hasil dan Pembahasan
Data hasil pengujian diolah dan dianalisis berdasarkan jenis message broker. Pembahasan berisi deskripsi hasil pengujian masing-masing
message broker saat melakukan proses publish-subscibe Pembahasan kemudian ditampilkan
dalam bentuk grafik dan perhitungan statistika.
3.5 Kesimpulan
Tahap kesimpulan berisi uraian tentang pengaruh kinerja Redis, Mosquitto, dan MongoDB sebagai message broker pada IoT
middleware. Hasil pengujian dideskripsikan dari
sisi persisten/nonpersisten dan kinerja pada masing-masing message broker.
4. HASIL DAN PEMBAHASAN
4.1 Hasil Pengujian Persisten/Nonpersisten
Klasifikasi persisten/nonpersisten untuk mengetahui karakteristik dari masing-masing
message broker terhadap konsistensi datanya.
Hasil pengujian persisten/nonpersisten ditunjukkan tabel 1.
Tabel 1 Hasil Pengujian Persisten/Nonpersisten
Jenis Message Broker Persisten atau Nonpersisten
Redis Message Broker Persisten MongoDB Message Broker Persisten Mosquitto Message broker Nonpersisten
Berdasarkan tabel 1 dapat ditarik kesimpulan bahwa Redis dan MongoDB bersifat persisten. Hal ini karena Redis dan MongoDB merupakan database, sehingga mendukung proses penyimpanan data. Sedangkan Mosquitto bersifat nonpersisten karena Mosquitto tidak memiliki ketiga syarat yang memenuhi ketersediaan adanya mekanisme persisten.
4.2 Hasil Pengujian Kinerja
Pengujian kinerja bertujuan untuk mengetahui penggunaan CPU, penggunaan memori, disk i/o, runtime, dan skalabilitas masing-masing message broker dalam menangani sejumlah data saat proses publish maupun subscribe. Pengujian pada saat proses
publish bertujuan untuk melihat kinerja message broker saat melakukan write data. Sedangkan
pengujian pada proses subscribe bertujuan melihat kinerja broker saat melakukan read data. Pengujian pada masing-masing parameter
Fakultas Ilmu Komputer, Universitas Brawijaya kinerja dilakukan sebanyak tiga kali.
4.2.1 Hasil Pengujian Penggunaan CPU
Hasil pengolahan data pada pengujian penggunaan CPU saat proses write dan read data ditunjukkan tabel 2 dan tabel 3.
Tabel 2 Perbandingan Penggunaan CPU saat Write Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 10 13 30 60 7 500 Redis 24 41 66 124 13 1000 Redis 17 25 32 64 6 100 MongoDB 7 10 12 36 4 500 MongoDB 21 30 42 106 15 1000 MongoDB 38 49 62 107 13 100 Mosquitto 2 5 15 31 1 500 Mosquitto 26 36 50 84 10 1000 Mosquitto 47 66 84 165 19 Tabel 3 Perbandingan Penggunaan CPU saat Read
Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 3 24 53 76 1 500 Redis 75 85 98 116 62 1000 Redis 10 36 52 91 7 100 MongoDB 12 16 20 30 4 500 MongoDB 56 92 103 112 21 1000 MongoDB 36 75 98 110 19 100 Mosquitto 4 8 22 51 3 500 Mosquitto 34 62 82 109 20 1000 Mosquitto 39 52 77 123 26 Berdasarkan hasil pengujian penggunaan CPU saat proses write dan read data terlihat adanya peningkatan penggunaan CPU seiring dengan peningkatan jumlah data yang di-publish maupun di-subscribe. Saat proses write data, penggunaan CPU Redis message broker memiliki nilai yang lebih efisien dibandingkan
MongoDB dan Mosquitto message broker
dengan rentang 13% sampai 41%. Sedangkan saat proses read data, penggunaan CPU
Mosquitto message broker memiliki nilai yang
lebih efisien dibandingkan Redis dan MongoDB
message broker dengan rentang 8% - 62%. 4.2.2 Hasil Pengujian Penggunaan Memori
Hasil pengujian penggunaan memori saat proses write dan read data ditunjukkan oleh tabel 4 dan tabel 5. Data penggunaan memori ditampilkan dalam satuan MB
.
Tabel 4Perbandingan Penggunaan Memori saat Write Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 51 53 55 57 47 500 Redis 52 64 70 75 46 1000 Redis 49 55 62 66 43 100 MongoDB 50 53 56 60 49 500 MongoDB 58 67 72 80 46 1000 MongoDB 51 60 71 83 40 100 Mosquitto 49 52 57 58 46 500 Mosquitto 84 88 93 94 77 1000 Mosquitto 159 174 196 237 144 Tabel 5 Perbandingan Penggunaan Memori saat Read
Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 58 59 61 65 56 500 Redis 53 58 62 67 50 1000 Redis 54 58 62 66 45 100 MongoDB 56 57 59 66 55 500 MongoDB 57 68 72 75 44 1000 MongoDB 59 69 74 79 43 100 Mosquitto 53 55 55 58 50 500 Mosquitto 78 82 86 92 67 1000 Mosquitto 142 148 151 154 137
Pada penggunaan memori saat proses write dan read data, dapat disimpulkan bahwa penggunaan memori terbaik dimiliki Redis
message broker. Hal tersebut tidak dipengaruhi
oleh banyaknya data yang ditangani oleh Redis sebab karakteristik Redis yang bekerja secara
in-memory. Penggunaan memori Redis saat proses write data berkisar 53MB–64MB. Sedangkan
penggunaan memori Redis saat proses read data berkisar 54MB–59MB.
4.2.3 Hasil Pengujian Disk I/O
Pengujian disk i/o di bertujuan untuk mengetahui besar kecilnya operasi input output yang berjalan pada media penyimpanan fisik. Data hasil uji ditunjukkan pada tabel 6 dan tabel 7 dalam satuan megabit.
Tabel 6 Perbandingan Disk I/O saat Write Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 5 5 5 5 5 500 Redis 6 6 8 8 6 1000 Redis 12 12 12 15 12 100 MongoDB 8 9 10 10 7 500 MongoDB 27 33 37 42 25 1000 MongoDB 103 111 121 130 98 100 Mosquitto 0 0 0 0 0 500 Mosquitto 0 0 0 0 0 1000 Mosquitto 0 0 0 0 0
Tabel 7Perbandingan Disk I/O saat Read Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 8 8 8 8 8 500 Redis 8 8 8 8 8 1000 Redis 8 8 8 8 8 100 MongoDB 688 688 688 688 688 500 MongoDB 689 689 689 689 689 1000 MongoDB 689 689 689 689 689
100 Mosquitto 0 0 0 0 0 500 Mosquitto 0 0 0 0 0 1000 Mosquitto 0 0 0 0 0 Pada disk i/o terjadi peningkatan nilai disaat data yang di-publish dan di-susbcribe meningkat. Maka dapat disimpulkan bahwa kecepatan harddisk dalam menulis data dipengaruhi oleh banyaknya data yang ditangani oleh message broker. Namun kecepatan
harddisk dalam menulis data tetap lebih cepat MongoDB message broker dari pada Redis message broker. Nilai disk i/o saat proses write
dan read data yakni 111 megabit dan 689 megabit.
4.2.4 Hasil Pengujian Runtime
Pengujian runtime bertujuan untuk mengetahui waktu yang dibutuhkan message
broker saat operasi input output disk i/o berjalan.
Data hasil uji ditampilkan pada tabel 8 dan tabel 9 dalam satuan detik.
Tabel 8Perbandingan Runtime saat Write Data
Jumlah
Variasi Data Q1 Median Q3 Max Min
100 Redis 0,61 0,62 0,63 0,63 0,60 500 Redis 0,99 1,02 1,24 1,29 0,97 1000 Redis 2,30 2,37 2,44 2,89 2,25 100 MongoDB 1,39 1,55 1,75 1,78 1,30 500 MongoDB 6,07 6,84 7,44 8,28 5,69 1000 MongoDB 19,91 21,23 22,83 24,43 19,06 100 Mosquitto 0,00 0,00 0,00 0,00 0,00 500 Mosquitto 0,00 0,00 0,00 0,00 0,00 1000 Mosquitto 0,00 0,00 0,00 0,00 0,00 Tabel 9Perbandingan Runtime saat Read Data
Jumlah Variasi
Data Q1 Median Q3 Max Min
100 Redis 0,05 0,05 0,05 0,05 0,05 500 Redis 0,05 0,05 0,05 0,05 0,05 1000 Redis 0,05 0,05 0,05 0,05 0,05 100 MongoDB 0,09 0,09 0,09 0,09 0,09 500 MongoDB 0,10 0,10 0,10 0,10 0,10 1000 MongoDB 0,10 0,10 0,10 0,10 0,10 100 Mosquitto 0,00 0,00 0,00 0,00 0,00 500 Mosquitto 0,00 0,00 0,00 0,00 0,00 1000 Mosquitto 0,00 0,00 0,00 0,00 0,00 Berdasarkan data hasil pengujian runtime, terjadi peningkatan nilai runtime seiring dengan bertambahnya jumlah data yang di-publish dan di-susbcribe. Namun Redis message broker selalu memiliki nilai runtime yang lebih cepat daripada MongoDB message broker. Hal ini terlihat dari nilai runtime akhir Redis saat proses
write data sebesar 2,37 detik dan saat read data
sebesar 0,05 detik
4.2.5 Hasil Pengujian Skalabilitas 4.2.5.1 Hasil Pengujian Time Publish
Pengujian time publish bertujuan untuk mengetahui berapa lama waktu yang dibutuhkan
middleware untuk menangani sejumlah
publisher melalui protokol CoAP dan MQTT.
Hasil pengujian time publish ditunjukkan pada tabel 10.
Tabel 10 Hasil Pengujian Time Publish
Jumlah Publisher Rata-rata Time Publish CoAP Rata-rata Time Publish MQTT 100 Redis 10,58 11,12 500 Redis 81,71 88,60 1000 Redis 169,45 184,14 100 MongoDB 16,08 12,01 500 MongoDB 80,69 93,79 1000 MongoDB 173,90 254,27 100 Mosquitto 10,63 19,21 500 Mosquitto 74,90 89,96 1000 Mosquitto 159,43 181,76
Kesimpulan dari pengujian dengan parameter time publish melalui protokol CoAP maupun MQTT adalah kecepatan time publish dipengaruhi oleh jenis protokol dan ukuran data yang dikirimkan. Hal ini karena ukuran data yang dikirimkan oleh CoAP lebih kecil dibandingkan ukuran data yang dikirimkan oleh MQTT walaupun keduanya memiliki isi data yang sama. Time publish tercepat melalui protokol CoAP diperoleh Mosquitto pada variasi 100 yaitu 10,58, untuk variasi 500 bernilai 81,71, dan pada variasi 1000 bernilai 169,45. Sedangkan time publish tercepat melalui protokol MQTT diperoleh Redis pada variasi 100 yaitu 11,12, pada variasi 500 bernilai 88,60, dan pada variasi 1000 bernilai 184,14.
4.2.5.2 Hasil Pengujian Concurrent Publish
Pengujian concurrent publish bertujuan untuk mengetahui berapa banyak jumlah pesan yang mampu ditangani oleh middleware dalam satu detik saat proses publish. Hasil pengujian
concurrent publish ditunjukkan pada tabel 11.
Tabel 11 Hasil Pengujian Concurrent Publish
Jumlah Publisher Rata-rata concurrent (message/s) CoAP MQTT 100 Redis 10 10 500 Redis 6 6 1000 Redis 6 6 100 MongoDB 8 8 500 MongoDB 6 7 1000 MongoDB 5 5 100 Mosquitto 15 13 500 Mosquitto 6 6
Fakultas Ilmu Komputer, Universitas Brawijaya
1000 Mosquitto 6 6
Concurrent publish dipengaruhi oleh
jumlah data yang di-publish. Hal ini dapat terlihat dari penurunan nilai concurrent publish ketiga message broker saat jumlah data yang di-publish meningkat. Namun Mosquitto tetap memiliki skalabilitas yang lebih baik dalam menangani banyaknya data masuk daripada Redis dan MongoDB. Concurrent publish Mosquitto melalui protokol CoAP sebesar 15 pesan per detik. Sedangkan melalui protokol MQTT sebesar 13 pesan per detik.
4.2.5.3 Hasil Pengujian Time Subscribe
Pengujian time subscribe dilakukan untuk meilhat waktu yang dibutuhkan middleware dalam menangani sejumlah subscriber. Hasil pengujian time subscribe ditunjukkan tabel 12.
Tabel 12 Hasil Pengujian Time Subscribe
Jumlah Subscriber Rata-rata Time (s)
100 Redis 7,36 500 Redis 35,08 1000 Redis 115,07 100 MongoDB 7,17 500 MongoDB 37,62 1000 MongoDB 39,50 100 Mosquitto 5,75 500 Mosquitto 36,47 1000 Mosquitto 150,69
Time subscribe dipengaruhi oleh banyaknya data yang di-subscribe oleh
subscriber. Hal ini terlihat dari peningkatan nilai time subscribe message broker seiring peningkatan jumlah subscriber. Walaupun mengalami peningkatan time subscribe,
MongoDB tetap memiliki rentang nilai time
subscribe yang terendah karena sifatnya yang high performance dan scalable. Hal ini terlihat
dari rentang time subscribe MongoDB yang hanya berkisar 7,17 hingga 39,50.
4.2.5.4 Hasil Pengujian Concurrent Subscribe
Pengujian concurrent subscribe bertujuan untuk mengetahui banyak pesan yang dapat diterima oleh middleware dalam satu detik. Hasil pengujian concurrent subscribe ditunjukkan pada tabel 13.
Tabel 13Hasil Pengujian Concurrent Subscribe
Jumlah Subscriber Rata-rata concurrent
(message/s) 100 Redis 14 500 Redis 10 1000 Redis 9 100 MongoDB 13 500 MongoDB 13 1000 MongoDB 24 100 Mosquitto 19 500 Mosquitto 15 1000 Mosquitto 7
Concurrent subscribe dipengaruhi oleh
jumlah data yang di-subscribe. Hal ini karena adanya peningkatan maupun penurunan nilai
concurrent subscribe ketiga message broker
disaat terjadi peningkatan jumlah data yang
di-subscribe. Namun MongoDB tetap memiliki
nilai concurrent subscribe yang lebih tinggi daripada Redis dan Mosquitto. Sehingga kesimpulan yang dapat ditarik adalah MongoDB
message broker memiliki kemampuan
skalabilitas yang lebih baik dalam menangani sejumlah subscriber daripada Redis dan Mosquitto. Hal ini dapat dilihat dari nilai
concurrent subscribe MongoDB yang terus
meningkat seiring dengan peningkatan jumlah
subscriber, yakni mencapai 24 pesan per detik. 5. KESIMPULAN & SARAN
5.1 Kesimpulan
Pengembangan IoT middleware dengan Redis, MongoDB, dan Mosquitto sebagai
message broker dapat berjalan dengan baik.
Pada pengujian persisten dan nonpersisten,
Redis dan MongoDB message broker bersifat
persisten. Sedangkan Mosquitto bersifat nonpersisten.
Pada hasil pengujian kinerja, penggunaan CPU terbaik saat read data adalah Mosquitto dengan rentang 8%-62%. Pada penggunaan CPU saat write data, penggunaan memori, dan
runtime terbaik dimiliki oleh Redis dengan nilai
penggunaan CPU saat write data 13%-41%, penggunaan memori saat write dan read data berkisar 53MB-64MB dan 54MB-59MB, serta
runtime saat write dan read data sebesar 2,37
detik dan 0,05 mdetik. Pada disk i/o, MongoDB memiliki kinerja yang lebih baik saat write dan
read data sebesar 111 megabit dan 689 megabit.
Sedangkan dalam hal skalabilitas, time publish terbaik melalui CoAP dimiliki Mosquitto dengan rentang 10,59 hingga 169,45. Time publish terbaik melalui MQTT dimiliki Redis dengan rentang 11,12 hingga 184,14. Concurrent
publish terbaik adalah Mosquitto sebesar 18
pesan per detik melalui CoAP dan 15 pesan per detik melalui MQTT. Pada time subscribe dan
concurrent subscribe, nilai terbaik dimiliki
MongoDB dengan nilai 7,17-39,50 dan 24 pesan per detik.
Kesimpulan yang dapat ditarik yakni Redis memiliki kinerja yang baik pada penggunaan
CPU write data, memori, runtime, dan kecepatan dalam menangani data yang masuk melalui MQTT. Namun dari segi disk i/o dan kecepatan membaca data, MongoDB memiliki kinerja yang lebih baik. Hal ini karena MongoDB yang lebih
scalable dibandingkan Redis dan Mosquitto.
Sedangkan Mosquitto memiliki kinerja yang lebih baik dalam kecepatan menulis data, menerima data melalui protokol CoAP, dan menangani data yang keluar.
5.2 Saran
Saran untuk penelitian selanjutnya yaitu perlu dilakukan penanganan handle error pada masing-masing message broker jika tidak mampu menangani banyaknya beban dari
publisher maupun subscriber yang diterima oleh IoT middleware. Selain itu, pengujian lebih baik
dilakukan secara bertahap dan bergantian pada masing-masing message broker dengan rentang waktu tertentu. Sebab keadaan resource pada
IoT middleware mempengaruhi hasil
pengukuran kinerja masing-masing message
broker.
6 DAFTAR PUSTAKA
Anwari, H., Pramukantoro E. S., & Hanafi, M. H., 2017. Pengembangan IoT Middleware Berbasis Event-Based dengan Protokol Komunikasi CoAP, MQTT dan Websocket. Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer,
Desember 2017, Indonesia. 1560-1565. Ionescu, V. M., 2015. The analysis of the
performance of RabbitMQ and ActiveMQ. Dalam: IEEE, 2015. 2015
14th RoEduNet International Conference - Networking in Education and Research (RoEduNet NER). Craiova, Romania,
24-26 September 2015. New York: IEEE. Paksula, M. 2019. Persisting Objects in Redis
Key-Value Database. [online] Tersedia di:
< https://www.cs.helsinki.fi> [Diakses 10 Februari 2019].
Patro, S., Potey, M., & Golhani, A., 2017. Comparative Study of Middleware Solutions For Control and Monitoring System. Dalam: IEEE, 2017. 2017 Second
International Conference on Electrical,
Computer and Communication
Technologies (ICECCT). Tamil Nadu,
India, 22-24 Februari 2017. New York: IEEE.
Pramukantoro, E. S., Kusyanti, A., & Yazid, 2018. Performance Evaluation of Semantic IoT Middleware. Dalam: IEEE, 2018. 2018 International Conference on
Sustainable Information Engineering and Technology (SIET). Malang, Indonesia,
10-12 November 2018. New York: IEEE. Razzaque, M. A., Dublin, T. C., Milojevic, M., & Clarke, S., 2015. Middleware for Internet of Things: A Survey. Dalam: IEEE, 2015. IEEE Internet of Things
Journal. 09 November 2015. New York:
