Perbandingan Kinerja Redis, Mosquitto, Dan Mongodb Sebagai Message Broker Pada Iot Middleware Fitri Febriyani1, Eko Sakti Pramukantoro2, Fariz Andri Bakhtiar3

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-ISSN: 2548-964X Vol. 3, No. 7, Juli 2019, hlm. 6816-6823 http://j-ptiik.ub.ac.id

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: [email protected], [email protected], [email protected]

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

“things” pada sudut pandang IoT memiliki arti 1. PENDAHULUAN yang sangat luas dan sangat berkaitan dengan Adanya teknologi IoT (Internet of Things), sejumlah besar perangkat yang terhubung ke manusia dan komputer dapat melakukan internet (Razzaque, et al., 2016). Keberagaman interaksi dengan berbagai things yang terkoneksi bentuk perangkat IoT tersebut menyebabkan internet secara otomatis. Namun, definisi timbulnya permasalahan interoperabilitas pada

Fakultas Ilmu Komputer Universitas Brawijaya 6816 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6817

IoT. Menurut Razzaque, et al. (2016), solusi 2. LANDASAN KEPUSTAKAAN permasalahan interoperabilitas yakni dengan membangun sebuah middleware. Sebab 2.1 Kajian Pustaka middleware dapat memberi kemudahan dalam Pada penelitian penelitian Anwari, pengembangan aplikasi dengan Pramukantoro, dan Hanafi (2016), mengintegrasikan beraneka-ragam komputasi dikembangkan IoT middleware dengan dan perangkat komunikasi. Untuk itu, penelitian arsitektur seperti gambar 1 . 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 Gambar 1 Arsitektur IoT Middleware mendukung pola publish-subscribe. IoT Berdasarkan gambar 1, arsitektur IoT middleware tersebut kemudian dilakukan middleware terdiri dari application gateway, pengujian dari segi semantik oleh Pramukantoro, service unit, dan sensor gateway. Pada service Kusyanti, dan Yazid (2018) menunjukkan hasil unit digunakan Redis sebagai message broker bahwa IoT middleware dengan Redis sebagai karena dapat mendukung pola publish- message broker dapat menerima berbagai tipe subscribe. Penelitian ini menggunakan IoT data. Namun selain dapat menerima data, middleware yang sama dalam menerapkan message broker perlu memiliki kemampuan MongoDB dan Mosquitto sebagai message skalabilitas agar dapat meningkatkan beban yang broker. Kemudian dilakukan perbandingan ditangani dan terus beroperasi walau terjadi dengan Redis message broker yang telah kegagalan (Ionescu, 2015). diterapkan sebelumnya. Hal ini bertujuan untuk Terdapat berbagai jenis message broker mengetahui pengaruh kinerja dari ketiga yang dapat digunakan, yakni MongoDB, message broker terhadap IoT middleware. Mosquitto, ZeroMQ, dan RabbitMQ. Namun penelitian ini menggunakan MongoDB dan 2.2 Dasar Teori Mosquitto sebagai message broker. Penggunaan MongoDB karena karakteristik high 2.2.1 Message Broker performance dan scalable yang Message broker berfungsi sebagai media memungkinkannya untuk mendukung yang menjembatani komunikasi antara sensor skalabilitas pada IoT middleware. Sedangkan dan application gateway. Messaging mode data penggunaan Mosquitto karena karakteristik transfer yang diterapkan adalah model publish- kestabilan kinerjanya yang baik dalam subscribe dengan tipe topic-based. Mekanisme pengiriman data memungkinkannya untuk dapat kerja message broker yakni data yang terus beroperasi walaupun terjadi kegagalan. dikirimkan oleh publisher kemudian diterima Perbandingan Redis, MongoDB, dan Mosquitto message broker dan diteruskan ke subscriber sebagai message broker dilakukan dengan berdasarkan topik yang di-subscribe. menerapkan masing-masing message broker secara bergantian pada IoT middleware yang 2.2.2 Persisten/Nonpersisten telah dibangun di penelitian sebelumnya. Definisi persisten/nonpersisten merujuk Kemudian dilakukan pengujian, analisis, dan pada konsistensi data terhadap memory- pembahasan satu persatu pada masing-masing database. Persisten dalam hal memory database message broker. Hasil pengujian lalu diuraikan merupakan sistem manajemen basis data yang untuk menjadi bahan pembahasan dalam mengandalkan memori utama untuk mendeskripsikan apakah kinerja dan skalabilitas penyimpanan data pada komputer. Klasifikasi pada IoT middleware dipengaruhi oleh message persisten/nonpersisten dilakukan untuk broker yang digunakan. Sehingga melalui mengetahui karakteristik dari masing-masing penelitian ini, didapatkan informasi mengenai message broker terhadap konsistensi datanya. bagaimana kinerja dari masing-masing message Bertujuan untuk melihat apakah masing-masing broker yang diterapkan pada IoT middleware. message broker dapat menyimpan data secara real-time. Sehingga jika terjadi crash pada

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6818 middleware maka data tetap dapat dicadangkan. penelitian pada gambar 2. 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 Gambar 2 Alur Metodologi Penelitian Redis memiliki kemampuan pembacaan data Berdasarkan gambar 2, metodologi yang lebih cepat dibandingkan NoSQL lainnya. penelitian dimulai dari studi literatur, Walaupun Redis dikenal sebagai sebuah pengembangan lingkungan uji, pengambilan database, tetapi Redis juga dapat berperan data uji, hasil, dan pembahasan serta sebagai cache dan message broker. Mekanisme kesimpulan. kerja Redis sebagai message broker menerapkan model publish-subscribe, yaitu topic-based. 3.1 Studi Literatur 2.2.5 MongoDB Studi literatur berisi penjelasan mengenai MongoDB merupakan database NoSQL teori dasar dan penelitian terdahulu terkait yang dapat diimplementasikan sebagai message dengan objek penelitian. Sumber studi literatur broker melalui fitur capped collection. Pada fitur berasal dari jurnal, situs resmi, dan penelitian tersebut terdapat fixed-size collections yang sebelumnya. menjalankan mekanisme publish-subscribe. Bekerja seperti buffer circular, dimana setelah 3.2 Pengembangan Lingkungan Uji collection mengisi alokasi ruang maka terbentuk Tahap ini menjelaskan perancangan dan dokumen baru dengan cara menimpa dokumen implementasi yang dilakukan dalam tertua dalam collection tersebut. membangun lingkungan uji. Pada tahap perancangan diuraikan kebutuhan dan rancangan 2.2.6 Mosquitto komponen sistem yang diperlukan. Pada sisi Mosquitto merupakan message broker yang lingkungan sistem dikategorikan menjadi menggunakan protokol MQTT dalam kebutuhan perangkat lunak dan kebutuhan pemrosesan mekanisme pub-sub. MQTT perangkat keras. Kemudian dari sisi alur sistem membutuhkan dua komponen perangkat lunak terdapat kebutuhan fungsional sistem dan utama yaitu MQTT Client yang nantinya akan kebutuhan data. Aktivitas perancangan dipasang pada device dan MQTT Broker yang lingkungan uji terdiri dari perancangan alur berfungsi untuk menangani publish dan sistem, perancangan program publisher, subscribe data. Tidak adanya ketentuan antrian perancangan program subscriber, perancangan di tingkat protokol mengharuskan publisher dan payload, perancangan IoT middleware, dan subscriber harus aktif pada waktu yang perancangan pengujian. Sedangkan aktivitas bersamaan untuk dapat melakukan komunikasi implementasi terdiri dari implementasi program (Patro, Potey, & Golhani, 2017). publisher, subscriber, dan implementasi IoT middleware. Pada implementasi IoT middleware, terdapat tiga jenis IoT middleware 3. METODOLOGI yang digunakan dalam membangun lingkungan Pembahasan tahapan-tahapan yang uji. Sehingga terdapat tiga jenis lingkungan uji dilakukan ditunjukkan melalui metodologi juga yang digunakan. Ketiga jenis lingkungan uji

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6819 tersebut ditunjukkan gambar 3, 4, dan 5. 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. Gambar 3 Lingkungan Uji IoT Middleware dengan Redis sebagai message broker 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 Gambar 4 Lingkungan Uji IoT Middleware dengan MongoDB sebagai message broker 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 Persisten atau Jenis Message Broker Nonpersisten Gambar 5 Lingkungan Uji IoT Middleware dengan Redis Message Broker Persisten Mosquitto sebagai message broker MongoDB Message Broker Persisten Berdasarkan gambar 3, 4, dan 5, masing- Mosquitto Message broker Nonpersisten masing message broker diimplementasikan pada Berdasarkan tabel 1 dapat ditarik service unit sistem dan tetap memiliki kesimpulan bahwa Redis dan MongoDB bersifat mekanisme alur sistem yang sama. persisten. Hal ini karena Redis dan MongoDB merupakan database, sehingga mendukung 3.3 Pengambilan Data Uji proses penyimpanan data. Sedangkan Mosquitto Sebelum proses pengambilan data uji, bersifat nonpersisten karena Mosquitto tidak dilakukan pengujian pada masing-masing IoT memiliki ketiga syarat yang memenuhi middleware dengan message broker yang ketersediaan adanya mekanisme persisten. berbeda secara bergantian. Terdapat dua sumber dalam proses pengambilan data, yakni data dari 4.2 Hasil Pengujian Kinerja hasil capture Wireshark dan data dari kode Pengujian kinerja bertujuan untuk program pengujian kinerja. Data hasil tangkapan mengetahui penggunaan CPU, penggunaan aplikasi Wireshark disimpan dalam bentuk memori, disk i/o, runtime, dan skalabilitas format PCAP dan diolah untuk mendapatkan masing-masing message broker dalam nilai time publish, concurrent publish, time menangani sejumlah data saat proses publish subscribe, dan concurrent subcribe. Sedangkan maupun subscribe. Pengujian pada saat proses data dari kode program pengujian kinerja berupa publish bertujuan untuk melihat kinerja message file CSV yang berisi data log performa broker saat melakukan write data. Sedangkan middleware saat proses publish-subscribe pengujian pada proses subscribe bertujuan berjalan. Kedua jenis file tersebut kemudian melihat kinerja broker saat melakukan read data. diubah menjadi data dalam bentuk Excel untuk Pengujian pada masing-masing parameter

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6820 kinerja dilakukan sebanyak tiga kali. 500 Redis 52 64 70 75 46 1000 Redis 49 55 62 66 43 4.2.1 Hasil Pengujian Penggunaan CPU 100 MongoDB 50 53 56 60 49 500 MongoDB 58 67 72 80 46 Hasil pengolahan data pada pengujian 1000 MongoDB 51 60 71 83 40 penggunaan CPU saat proses write dan read data 100 Mosquitto 49 52 57 58 46 ditunjukkan tabel 2 dan tabel 3. 500 Mosquitto 84 88 93 94 77 1000 Mosquitto 159 174 196 237 144 Tabel 2 Perbandingan Penggunaan CPU saat Write Data Tabel 5 Perbandingan Penggunaan Memori saat Read Jumlah Variasi Q1 Median Q3 Max Min Data Data Jumlah Variasi Q1 Median Q3 Max Min 100 Redis 10 13 30 60 7 Data 500 Redis 24 41 66 124 13 100 Redis 58 59 61 65 56 1000 Redis 17 25 32 64 6 500 Redis 53 58 62 67 50 100 MongoDB 7 10 12 36 4 1000 Redis 54 58 62 66 45 500 MongoDB 21 30 42 106 15 100 MongoDB 56 57 59 66 55 1000 MongoDB 38 49 62 107 13 500 MongoDB 57 68 72 75 44 100 Mosquitto 2 5 15 31 1 1000 MongoDB 59 69 74 79 43 500 Mosquitto 26 36 50 84 10 100 Mosquitto 53 55 55 58 50 1000 Mosquitto 47 66 84 165 19 500 Mosquitto 78 82 86 92 67 1000 Mosquitto 142 148 151 154 137 Tabel 3 Perbandingan Penggunaan CPU saat Read Data Pada penggunaan memori saat proses write Jumlah Variasi dan read data, dapat disimpulkan bahwa Q1 Median Q3 Max Min Data penggunaan memori terbaik dimiliki Redis 100 Redis 3 24 53 76 1 message broker. Hal tersebut tidak dipengaruhi 500 Redis 75 85 98 116 62 1000 Redis 10 36 52 91 7 oleh banyaknya data yang ditangani oleh Redis 100 MongoDB 12 16 20 30 4 sebab karakteristik Redis yang bekerja secara in- 500 MongoDB 56 92 103 112 21 memory. Penggunaan memori Redis saat proses 1000 MongoDB 36 75 98 110 19 write data berkisar 53MB–64MB. Sedangkan 100 Mosquitto 4 8 22 51 3 penggunaan memori Redis saat proses read data 500 Mosquitto 34 62 82 109 20 1000 Mosquitto 39 52 77 123 26 berkisar 54MB–59MB. Berdasarkan hasil pengujian penggunaan 4.2.3 Hasil Pengujian Disk I/O CPU saat proses write dan read data terlihat Pengujian disk i/o di bertujuan untuk adanya peningkatan penggunaan CPU seiring mengetahui besar kecilnya operasi input output dengan peningkatan jumlah data yang di-publish yang berjalan pada media penyimpanan fisik. maupun di-subscribe. Saat proses write data, Data hasil uji ditunjukkan pada tabel 6 dan tabel penggunaan CPU Redis message broker 7 dalam satuan megabit. memiliki nilai yang lebih efisien dibandingkan MongoDB dan Mosquitto message broker Tabel 6 Perbandingan Disk I/O saat Write Data Jumlah Variasi Q1 Median Q3 Max Min dengan rentang 13% sampai 41%. Sedangkan Data saat proses read data, penggunaan CPU 100 Redis 5 5 5 5 5 Mosquitto message broker memiliki nilai yang 500 Redis 6 6 8 8 6 lebih efisien dibandingkan Redis dan MongoDB 1000 Redis 12 12 12 15 12 message broker dengan rentang 8% - 62%. 100 MongoDB 8 9 10 10 7 500 MongoDB 27 33 37 42 25 4.2.2 Hasil Pengujian Penggunaan Memori 1000 MongoDB 103 111 121 130 98 100 Mosquitto 0 0 0 0 0 Hasil pengujian penggunaan memori saat 500 Mosquitto 0 0 0 0 0 proses write dan read data ditunjukkan oleh tabel 1000 Mosquitto 0 0 0 0 0 4 dan tabel 5. Data penggunaan memori Tabel 7 Perbandingan Disk I/O saat Read Data Jumlah Variasi ditampilkan dalam satuan MB. Q1 Median Q3 Max Min Data 100 Redis 8 8 8 8 8 500 Redis 8 8 8 8 8 Tabel 4 Perbandingan Penggunaan Memori saat 1000 Redis 8 8 8 8 8

Write Data 100 MongoDB 688 688 688 688 688 Jumlah Variasi Q1 Median Q3 Max Min 500 MongoDB 689 689 689 689 689 Data 1000 MongoDB 689 689 689 689 689 100 Redis 51 53 55 57 47

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6821

100 Mosquitto 0 0 0 0 0 4.2.5 Hasil Pengujian Skalabilitas 500 Mosquitto 0 0 0 0 0 1000 Mosquitto 0 0 0 0 0 4.2.5.1 Hasil Pengujian Time Publish Pada disk i/o terjadi peningkatan nilai disaat Pengujian time publish bertujuan untuk data yang di-publish dan di-susbcribe mengetahui berapa lama waktu yang dibutuhkan meningkat. Maka dapat disimpulkan bahwa middleware untuk menangani sejumlah kecepatan harddisk dalam menulis data publisher melalui protokol CoAP dan MQTT. dipengaruhi oleh banyaknya data yang ditangani Hasil pengujian time publish ditunjukkan pada oleh message broker. Namun kecepatan tabel 10. harddisk dalam menulis data tetap lebih cepat Tabel 10 Hasil Pengujian Time Publish MongoDB message broker dari pada Redis Rata-rata Rata-rata Jumlah Time Publish Time Publish message broker. Nilai disk i/o saat proses write Publisher dan read data yakni 111 megabit dan 689 CoAP MQTT megabit. 100 Redis 10,58 11,12 500 Redis 81,71 88,60 4.2.4 Hasil Pengujian Runtime 1000 Redis 169,45 184,14 100 MongoDB 16,08 12,01 Pengujian runtime bertujuan untuk 500 MongoDB 80,69 93,79 mengetahui waktu yang dibutuhkan message 1000 MongoDB 173,90 254,27 100 Mosquitto 10,63 19,21 broker saat operasi input output disk i/o berjalan. 500 Mosquitto 74,90 89,96 Data hasil uji ditampilkan pada tabel 8 dan tabel 1000 Mosquitto 159,43 181,76 9 dalam satuan detik. Kesimpulan dari pengujian dengan Tabel 8 Perbandingan Runtime saat Write Data parameter time publish melalui protokol CoAP Jumlah Q1 Median Q3 Max Min maupun MQTT adalah kecepatan time publish Variasi Data 100 Redis 0,61 0,62 0,63 0,63 0,60 dipengaruhi oleh jenis protokol dan ukuran data 500 Redis 0,99 1,02 1,24 1,29 0,97 yang dikirimkan. Hal ini karena ukuran data 1000 Redis 2,30 2,37 2,44 2,89 2,25 yang dikirimkan oleh CoAP lebih kecil 100 1,39 1,55 1,75 1,78 1,30 dibandingkan ukuran data yang dikirimkan oleh MongoDB 500 MQTT walaupun keduanya memiliki isi data 6,07 6,84 7,44 8,28 5,69 MongoDB yang sama. Time publish tercepat melalui 1000 protokol CoAP diperoleh Mosquitto pada variasi 19,91 21,23 22,83 24,43 19,06 MongoDB 100 yaitu 10,58, untuk variasi 500 bernilai 81,71, 100 Mosquitto 0,00 0,00 0,00 0,00 0,00 dan pada variasi 1000 bernilai 169,45. 500 Mosquitto 0,00 0,00 0,00 0,00 0,00 1000 Sedangkan time publish tercepat melalui 0,00 0,00 0,00 0,00 0,00 Mosquitto protokol MQTT diperoleh Redis pada variasi 100 yaitu 11,12, pada variasi 500 bernilai 88,60, Tabel 9 Perbandingan Runtime saat Read Data dan pada variasi 1000 bernilai 184,14. Jumlah Variasi Q1 Median Q3 Max Min Data 4.2.5.2 Hasil Pengujian Concurrent Publish 100 Redis 0,05 0,05 0,05 0,05 0,05 500 Redis 0,05 0,05 0,05 0,05 0,05 Pengujian concurrent publish bertujuan 1000 Redis 0,05 0,05 0,05 0,05 0,05 untuk mengetahui berapa banyak jumlah pesan 100 MongoDB 0,09 0,09 0,09 0,09 0,09 yang mampu ditangani oleh middleware dalam 500 MongoDB 0,10 0,10 0,10 0,10 0,10 satu detik saat proses publish. Hasil pengujian 1000 MongoDB 0,10 0,10 0,10 0,10 0,10 100 Mosquitto 0,00 0,00 0,00 0,00 0,00 concurrent publish ditunjukkan pada tabel 11. 500 Mosquitto 0,00 0,00 0,00 0,00 0,00 Tabel 11 Hasil Pengujian Concurrent Publish 1000 Mosquitto 0,00 0,00 0,00 0,00 0,00 Rata-rata concurrent Berdasarkan data hasil pengujian runtime, Jumlah Publisher (message/s) terjadi peningkatan nilai runtime seiring dengan CoAP MQTT bertambahnya jumlah data yang di-publish dan 100 Redis 10 10 di-susbcribe. Namun Redis message broker 500 Redis 6 6 selalu memiliki nilai runtime yang lebih cepat 1000 Redis 6 6 100 MongoDB 8 8 daripada MongoDB message broker. Hal ini 500 MongoDB 6 7 terlihat dari nilai runtime akhir Redis saat proses 1000 MongoDB 5 5 write data sebesar 2,37 detik dan saat read data 100 Mosquitto 15 13 sebesar 0,05 detik 500 Mosquitto 6 6

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6822

1000 Mosquitto 6 6 500 Mosquitto 15 1000 Mosquitto 7 Concurrent publish dipengaruhi oleh jumlah data yang di-publish. Hal ini dapat Concurrent subscribe dipengaruhi oleh terlihat dari penurunan nilai concurrent publish jumlah data yang di-subscribe. Hal ini karena ketiga message broker saat jumlah data yang di- adanya peningkatan maupun penurunan nilai publish meningkat. Namun Mosquitto tetap concurrent subscribe ketiga message broker memiliki skalabilitas yang lebih baik dalam disaat terjadi peningkatan jumlah data yang di- menangani banyaknya data masuk daripada subscribe. Namun MongoDB tetap memiliki Redis dan MongoDB. Concurrent publish nilai concurrent subscribe yang lebih tinggi Mosquitto melalui protokol CoAP sebesar 15 daripada Redis dan Mosquitto. Sehingga pesan per detik. Sedangkan melalui protokol kesimpulan yang dapat ditarik adalah MongoDB MQTT sebesar 13 pesan per detik. message broker memiliki kemampuan skalabilitas yang lebih baik dalam menangani 4.2.5.3 Hasil Pengujian Time Subscribe sejumlah subscriber daripada Redis dan Pengujian time subscribe dilakukan untuk Mosquitto. Hal ini dapat dilihat dari nilai meilhat waktu yang dibutuhkan middleware concurrent subscribe MongoDB yang terus dalam menangani sejumlah subscriber. Hasil meningkat seiring dengan peningkatan jumlah pengujian time subscribe ditunjukkan tabel 12. subscriber, yakni mencapai 24 pesan per detik.

Tabel 12 Hasil Pengujian Time Subscribe 5. KESIMPULAN & SARAN Jumlah Subscriber Rata-rata Time (s) 100 Redis 7,36 500 Redis 35,08 5.1 Kesimpulan 1000 Redis 115,07 100 MongoDB 7,17 Pengembangan IoT middleware dengan 500 MongoDB 37,62 Redis, MongoDB, dan Mosquitto sebagai 1000 MongoDB 39,50 message broker dapat berjalan dengan baik. 100 Mosquitto 5,75 Pada pengujian persisten dan nonpersisten, 500 Mosquitto 36,47 Redis dan MongoDB message broker bersifat 1000 Mosquitto 150,69 persisten. Sedangkan Mosquitto bersifat Time subscribe dipengaruhi oleh nonpersisten. banyaknya data yang di-subscribe oleh Pada hasil pengujian kinerja, penggunaan subscriber. Hal ini terlihat dari peningkatan nilai CPU terbaik saat read data adalah Mosquitto time subscribe message broker seiring dengan rentang 8%-62%. Pada penggunaan CPU peningkatan jumlah subscriber. Walaupun saat write data, penggunaan memori, dan mengalami peningkatan time subscribe, runtime terbaik dimiliki oleh Redis dengan nilai MongoDB tetap memiliki rentang nilai time penggunaan CPU saat write data 13%-41%, subscribe yang terendah karena sifatnya yang penggunaan memori saat write dan read data high performance dan scalable. Hal ini terlihat berkisar 53MB-64MB dan 54MB-59MB, serta dari rentang time subscribe MongoDB yang runtime saat write dan read data sebesar 2,37 hanya berkisar 7,17 hingga 39,50. detik dan 0,05 mdetik. Pada disk i/o, MongoDB 4.2.5.4 Hasil Pengujian Concurrent Subscribe memiliki kinerja yang lebih baik saat write dan read data sebesar 111 megabit dan 689 megabit. Pengujian concurrent subscribe bertujuan Sedangkan dalam hal skalabilitas, time publish untuk mengetahui banyak pesan yang dapat terbaik melalui CoAP dimiliki Mosquitto dengan diterima oleh middleware dalam satu detik. Hasil rentang 10,59 hingga 169,45. Time publish pengujian concurrent subscribe ditunjukkan terbaik melalui MQTT dimiliki Redis dengan pada tabel 13. rentang 11,12 hingga 184,14. Concurrent Tabel 13 Hasil Pengujian Concurrent Subscribe publish terbaik adalah Mosquitto sebesar 18 Rata-rata concurrent Jumlah Subscriber pesan per detik melalui CoAP dan 15 pesan per (message/s) detik melalui MQTT. Pada time subscribe dan 100 Redis 14 500 Redis 10 concurrent subscribe, nilai terbaik dimiliki 1000 Redis 9 MongoDB dengan nilai 7,17-39,50 dan 24 pesan 100 MongoDB 13 per detik. 500 MongoDB 13 Kesimpulan yang dapat ditarik yakni Redis 1000 MongoDB 24 memiliki kinerja yang baik pada penggunaan 100 Mosquitto 19

Fakultas Ilmu Komputer, Universitas Brawijaya Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 6823

CPU write data, memori, runtime, dan kecepatan Pramukantoro, E. S., Kusyanti, A., & Yazid, dalam menangani data yang masuk melalui 2018. Performance Evaluation of MQTT. Namun dari segi disk i/o dan kecepatan Semantic IoT Middleware. Dalam: IEEE, membaca data, MongoDB memiliki kinerja yang 2018. 2018 International Conference on lebih baik. Hal ini karena MongoDB yang lebih Sustainable Information Engineering and scalable dibandingkan Redis dan Mosquitto. Technology (SIET). Malang, Indonesia, Sedangkan Mosquitto memiliki kinerja yang 10-12 November 2018. New York: IEEE. lebih baik dalam kecepatan menulis data, Razzaque, M. A., Dublin, T. C., Milojevic, M., menerima data melalui protokol CoAP, dan & Clarke, S., 2015. Middleware for menangani data yang keluar. Internet of Things: A Survey. Dalam: 5.2 Saran IEEE, 2015. IEEE Internet of Things Journal. 09 November 2015. New York: Saran untuk penelitian selanjutnya yaitu IEEE. 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.

Fakultas Ilmu Komputer, Universitas Brawijaya