4.1 Persiapan Sistem
Persiapan sistem dilakukan sebelum melangkah ke implementasi rancangan sistem penelitian. Hal ini berguna untuk memastikan bahwa lingkungan kerja yang digunakan telah siap dan tidak ada lagi kendala dalam pengembangan.
Diantaranya yaitu menginstall software terkait, mempersiapkan Firebase Cloud Messaging dan mempersiapkan mode debug pada smartphone.
Persiapan Firebase Cloud Messaging dilakukan dengan membuka halaman https://console.firebase.google.com, kemudian memilih . lalu masukkan nama proyek awas-banjir di Firebase Console tersebut dan menekan . Lalu menekan juga pada pilihan Google Analytics. Lalu tekan dan tunggu hingga Project FCM berhasil dibuat.
Disini perlu diaktifkan developer mode melalui
dan menekan nomor ponsel hingga 7 kali, kemudian mengaktifkan mode debug pada
. Lalu mencentang bagian Debugging USB dan Install via USB.
4.2 Implementasi
4.2.1 Implementasi IoT Platform
Implementasi IoT Platform dilaksanakan dengan mengacu pada rancangan sistem dan menghasilkan program yang tersusun pada (Lampiran A-1). Setelah itu perlu serangkaian tahap berikut untuk menjalankannya.
1. Persiapan UI Web admin
Program UI Web admin tersimpan di dalam direktori admin. Program tersebut menggunakan package dari pihak ketiga yang perlu di-install terlebih dahulu agar bisa digunakan, kemudian perlu juga melakukan build untuk menghasilkan program khusus yang nantinya digunakan oleh IoT Platform.
Keduanya dilaksanakan dengan perintah berikut melalui terminal:
Keluaran dari perintah di atas menghasilkan catatan (Lampiran A-2) yang menunjukan bahwa proses instalasi dan "build" telah berhasil meski dengan beberapa "warning".
2. Persiapan API Gateway
Program API Gateway tersimpan di dalam direktori server. Sama hal nya dengan web admin, program ini menggunakan package dari pihak ketiga yang perlu di-install terlebih dahulu dengan perintah di bawah ini:
Keluaran perintah di atas menghasilkan catatan (Lampiran A-3) yang menunjukan bahwa instalasi package berhasil. Sampai di sini, gateway masih menggunakan konfigurasi bawaan. Konfigurasinya diganti dengan membuat berkas di direktori server dengan isian sesuai (Lampiran A-15). Berikut merupakan halaman akun yang dapat dilihat pada Gambar 4.1.
Gambar 4.1 Halaman Akun Layanan Firebase Console
Berdasarkan Gambar 4.1, program memerlukan sebuah kunci pribadi untuk menghubungkan ke Firebase Cloud Messaging yang berformat . Berkas itu
didapat melalui Firebase Console, pada Setelan
klik pada . Lalu menyimpan berkas tersebut dengan nama di direktori server yang dapat dilihat pada (Lampiran A-7).
3. Membuat Sertifikat SSL
Sertifikat SSL diperlukan untuk membangun koneksi SSL di jaringan. Pada penelitian ini, digunakan metode self-signed certificate. Sertifikat yang dibuat ditanda-tangan sendiri dan tidak melibatkan Certificate Authority. Sertifikat ini cocok untuk pengujian atau penggunaan pribadi, tetapi tidak bisa digunakan secara publik. Sertifikat tersebut dihasilkan dengan perintah berikut:
Saat perintah tersebut dijalankan, muncul masukan data diri yang diperlukan (Lampiran A-4), kemudian private key tersimpan pada berkas
(Lampiran A-5) dalam direktori dan sertifikat
tersimpan pada berkas (Lampiran A-6) pada
direktori .
4. Konfigurasi Nginx
Konfigurasi bawaan dari Nginx harus diganti karena IoT Platform menggunakan server utama tanpa domain khusus. Sehingga gateway memungkinkan untuk diakses melalui localhost dan alamat IP komputer tersebut.
Berkas konfigurasi bawaan terletak di dalam direktori
dengan nama . Isi berkas diganti dengan (Lampiran A-16).
Konfigurasi di atas perlu diverifikasi untuk memastikan validitas sintaks dengan cara menjalankan perintah . Hasil yang muncul seperti di bawah ini:
5. Menjalankan IoT Platform
IoT Platform pada penelitian ini membutuhkan Nginx dan MongoDB untuk bisa berjalan. Sehingga kedua layanan tersebut perlu dijalankan terlebih dahulu menggunakan perintah di bawah.
Setelah Nginx dan MongoDB berjalan, kemudian menjalankan program IoT Platform. Pertama, yang merupakan program utama IoT Platform.
Kedua, yang mengkalkulasi nilai rata-rata
rekaman sensor setiap jamnya.
Berikut merupakan halaman IoT platform yang telah berjalan yang dapat dilihat pada Gambar 4.2.
Gambar 4.2 IoT Platform Telah Berjalan
Berdasarkan pada Gambar 4.2, halaman web admin dibuka untuk memastikan bahwa IoT Platform telah berjalan dengan baik dan terbukti halamannya dapat diakses dengan baik.
4.2.2 Implementasi Aplikasi Mobile
Implementasi aplikasi mobile dilaksanakan dengan mengacu pada rancangan sistem dan menghasilkan program khusus yang tersusun seperti pada (Lampiran A-6). Namun, program tersebut belum bisa langsung digunakan pada
smartphone. Ada beberapa tahap dan berkas tambahan yang perlu dibuat menggunakan Visual Studio Code.
1. Persiapan dan Konfigurasi
Program aplikasi mobile menggunakan package dari pihak ketiga yang perlu di-install. Tata caranya yaitu, buka melalui pilihan
. Kamudian untuk meng-install package yang dibutuhkan menggunakan perintah di bawah ini.
Setelah itu, aplikasi perlu dikonfigurasi agar dapat mengakses IoT Platform dengan alamat yang tepat. Pada penelitian ini, IoT Platform berada di alamat . IoT Platform sudah mendukung TLS, maka skema URI yang digunakan adalah HTTPS. Konfigurasi tersebut diterapkan dengan membuat sebuah berkas bernama dengan isian berikut:
Satu berkas lagi yang perlu diterapkan yaitu . Berkas ini digunakan oleh aplikasi agar bisa menerima notifikasi dari IoT Platform melalui Firebase Cloud Messaging. Penyiapan dan konfigurasinya dapat dilihat pada Gambar 4.3 berikut.
Gambar 4.3 Penyiapan dan konfigurasi SDK
Berdasarkan pada Gambar 4.3, berkas ini didapatkan di Firebase Console
melalui pilihan lalu pada bagian
ada bagian . Berkas pengaturan diunduh
dengan menekan lalu diletakkan di dalam direktori .
2. Percobaan Smartphone Mode Debug
Pada penelitian ini, dilakukan percobaan aplikasi terlebih dahulu melalui smartphone yang sudah diaktifkan mode debug atau mode pengembang dan terhubung ke komputer dengan Visual Studio Code. Mode debug dapat dilihat pada Gambar 4.4 berikut.
Gambar 4.4 Menjalankan mode debug di Visual Studio Code
Berdasarkan pada Gambar 4.4, Percobaan ini bertujuan memastikan tidak ada kecacatan dari sisi program. Setelah menekan F5 pada Visual Studio Code, muncul bilah mode debug dan debug console yang menyatakan aplikasi mode debug telah berjalan. Sementara itu juga muncul konfirmasi untuk meng-install aplikasi pada smartphone seperti pada Gambar 4.5 berikut.
Gambar 4.5 Menampilkan aplikasi mobile pada mode debug
Berdasarkan pada Gambar 4.5, aplikasi mobile berhasil berjalan dengan baik dan ditandai dengan label .
3. Bundel Aplikasi Android
Sebuah berkas tanda-tangan berformat perlu disiapkan terlebih dahulu sebelum menghasilkan bundel aplikasi android. Tanda tangan ini diperlukan oleh
compiler android dalam menghasilkan aplikasi yang sah. Berkas tanda tangan tersebut dibuat menggunakan software keytool yang merupakan bawaan dari Android Studio dengan perintah berikut.
Hasilnya, berkas pada (Lampiran A-7) tersimpan dalam direktori , kemudian menghubungkan berkas tersebut dengan aplikasi mobile dengan membuat sebuah berkas bernama di dalam direktori dengan isian berikut:
Bundel aplikasi android dihasilkan dengan perintah di bawah ini. Perintah ini menghasilkan berkas yang bisa dipasang oleh smartphone dengan arsitektur prosesor ARM, ARM64, atau X64.
Catatan perintah di atas (Lampiran A-7 sampai A-8) menunjukan bahwa aplikasi berhasil dibuat. Sementara bundel aplikasi mobile tersimpan dalam
direktori dengan nama berkas
. Berikut merupakan tampilan aplikasi yang sudah di install, yang dapat dilihat pada Gambar 4.6.
Gambar 4.6 Menampilkan aplikasi ter-install
Berdasarkan pada Gambar 4.6, aplikasi dapat dipasang dengan baik dengan bundel tersebut aplikasi mobile yang tersimpan.
4.3 Pengujian
Penelitian ini menerapkan dua metode pengujian software yaitu pengujian fungsional dan performa. Pengujian TLS dikelompokan ke dalam pengujian fungsional. Pengujian menggunakan berbagai alat yang berbeda-beda (bawaan Ubuntu OS dan pihak ketiga). Maka untuk mempermudah, dibuat sebuah alat utilitas khusus berbasis command line yang menjembatani semua kebutuhan pengujian. Alat tersebut terletak dalam direktori dan di-install ke sistem menggunakan perintah di bawah ini.
Seperti ditunjukan pada catatan instalasi (Lampiran A-8) bahwa instalasi berhasil dan menghasilkan sebuah alat command line bernama . Alat tersebut digunakan dalam pengujian sistem ke depan.
4.3.1 Pengujian Fungsional
Pengujian fungsional menguji apakah sistem berjalan dengan baik secara fungsi. Hasil masing-masing pengujiannya sebagai berikut.
1. Pengujian TLS
Pengujian TLS dilakukan dengan menangkap paket data yang lewat antara komputer client dan server menggunakan Wireshark. Tahap ini dicoba mengirimkan data pengukuran sensor dengan alat command line yang telah dibuat. Namun, terdapat kendala saat pengiriman. Yaitu penggunaan self-signed certificate yang ditandai sebagai bad certificate oleh sistem. Sehingga untuk memperbolehkan sistem melakukan request, percobaan ini diharuskan mengikut
sertakan opsi . Ini juga berakibat pada
pengujian berikutnya. Hal ini tidak masalah mengingat sertifikat ini hanya digunakan untuk pengujian. Namun pada penerapan sebenarnya, sebaiknya menggunakan sertifikat resmi yang ditanda-tangani oleh Certificate Authority.
Setelah perintah di atas dijalankan, muncul paket-paket komunikasi antara dua host sesuai dengan teori TLS seperti ditunjukkan pada Gambar 4.7 berikut.
Gambar 4.7 Rekaman TLS pada Wireshark
Berdasarkan Gambar 4.7, setelah handshake terjadi, kemudian client bisa mengirim data melalui paket Application Data. Saat paket tersebut dibedah, terlihat bahwa data berhasil terenkripsi pada segmen Encyrpted Application Data dan tidak bisa dibaca oleh Wireshark.
2. Login Web Admin
Tampilan dari halaman login web admin dapat dilihat pada Gambar 4.8 berikut ini.
Gambar 4.8 Login web admin
Berdasarkan pada Gambar 4.8, hasilnya menunjukkan bahwa login web admin berhasil. Setelah memasukan username dan password yang dikonfigurasi pada Implementasi IoT Platform, kemudian menekan . Tampilan diarahkan ke halaman list perangkat.
3. Membuat identitas perangkat IoT
Hasil implementasi IoT Platform menuntut setiap perangkat IoT untuk memiliki pasangan kunci berbasis ES256 atau RS256. Kunci private dipegang oleh perangkat IoT, sementara kunci public dipegang oleh IoT Platform. Pada pengujian ini, dibuat sepasang kunci berbasis ES256 menggunakan perintah di bawah ini.
Berkas kunci private bernama (Lampiran A-8).
Sementara berkas kunci public bernama (Lampiran A-9).
Kunci public ini hanya bisa digunakan untuk memvalidasi data masuk dan tidak bisa digunakan untuk menandatangani data keluar. Hal ini menjamin bahwa hanya perangkat IoT saja yang bisa mengirim data. Penanganan terhadap perangkat palsu juga lebih kuat. Jika salah satu kunci bocor, hal tersebut tidak mempengaruhi data identitas perangkat IoT lainnya. Setiap perangkat IoT memiliki kunci yang berbeda. Kunci perangkat IoT juga bisa diganti dengan mudah. Langkah membuat identitasnya seperti pada Gambar 4.9 berikut.
Gambar 4.9 Membuat identitas perangkat IoT
Berdasarkan pada Gambar 4.9, berkas kunci private digunakan untuk menandatangani identitas saat pengiriman data. Sementara berkas kunci public digunakan untuk mengisi isian Secret Key.
Setelah admin menekan muncul halaman untuk mengisi data identitas perangkat IoT. Pada pengujian ini, dimasukkan nama Untirta dengan lokasi yang menunjuk ke Fakultas Teknik. Ketika tombol ditekan, halaman berpindah ke list perangkat IoT yang menunjukan ada identitas baru yang ditambahkan.
4. Mengubah identitas perangkat IoT
Langkah dalam mengubah identitas dapat dilihat pada Gambar 4.10 berikut.
Gambar 4.10 Mengubah identitas perangkat IoT
Berdasarkan Gambar 4.10, menunjukan web admin berhasil mengubah identitas perangkat IoT. Setelah admin mengubah data dan menekan tombol
, sistem segera mengubah identitas sesuai dengan perubahan.
5. Menghapus identitas perangkat IoT
Langkah dalam menghapus identitas dapat dilihat pada Gambar 4.11 ini.
Gambar 4.11 Menghapus identitas perangkat IoT
Berdasarkan pada Gambar 4.11, menunjukan bahwa perangkat IoT bisa dihapus. Terdapat alert untuk mengkonfirmasi apakah admin yakin menghapus
perangkat IoT tersebut. Ketika tombol ditekan, sistem membatalkan penghapusan. Sementara saat tombol ditekan, maka identitas perangkat IoT segera terhapus.
6. Menambah perangkat IoT ke List di aplikasi
Fitur ini memungkinkan pengguna hanya memilih perangkat IoT yang kira- kira dekat dengan tempat dia berada saja. Langkah dalam menambah perangkatnya dapat dilihat pada Gambar 4.12 berikut.
Gambar 4.12 Menambahkan perangkat ke halaman list
Berdasarkan pada Gambar 4.12, hasil pengujiannya menunjukan bahwa pengguna bisa menambahkan perangkat IoT dengan baik.
7. Perangkat IoT mengirimkan data pengukuran
Pada pengujian ini disimulasikan pengiriman data dengan nilai ultrasonic yang berubah-ubah (90, 90, 80, 70, 86) ke perangkat IoT dengan ID . Sementara parameter lainnya tetap. Sebelumnya juga sudah membuat sepasang kunci khusus. Kunci private disimpan dengan nama dan kunci public sudah disimpan sebelumnya di dalam identitas perangkat IoT melalui web admin. Pengujian dilakukan dengan menjalankan perintah berikut bersamaan dengan mengamati tampilan detail pada aplikasi mobile.
Perintah di atas sebenarnya menjalankan HTTP GET request dengan format di bawah ini dengan nilai query ultrasonic yang berubah-ubah. JWT yang dikirimkan menggunakan algoritma ECDSA SHA-256 (ES256) memiliki payload
berisi ID serta dan untuk menentukan kadaluarsa.
Seperti yang dijelaskan sebelumnya. Nilai token dibuat dengan library jsonwebtoken berdasarkan kunci yang disimpan sebelumnya.
Setelah menjalankan perintah di atas, terjadi perubahan data pada tampilan detail aplikasi seperti ditunjukan pada Gambar 4.13 berikut.
Gambar 4.13 Tampilan detail perangkat IoT
Berdasarkan pada Gambar 4.13, grafik ultrasonic bergerak sesuai dengan data yang dikirimkan oleh perangkat IoT.
8. IoT Platform menolak pengiriman data yang tidak valid
IoT Platform harus bisa menolak pengiriman data dari perangkat IoT yang tidak valid. Di antaranya ID tidak ditemukan, kredensial salah atau autentikasi gagal, dan bentuk request pengiriman data tidak valid.
Pertama, dikirimkan data dengan ID yang
tidak terdaftar pada IoT Platform. Hasilnya IoT Platform membalas dengan status 404 yang berarti atau tidak ditemukan.
Kedua, dikirimkan data dengan ID yang
terdaftar. Namun, menggunakan kunci private yang salah. Hasilnya, IoT Platform membalas dengan status 401 yang berarti atau tidak sah.
Ketiga, dikirimkan data dengan ID yang terdaftar dan kunci private yang benar, tapi dengan parameter sensor yang tidak lengkap (hanya ultrasonic saja).
Hasilnya, IoT Platform membalas dengan status 400 yang berarti atau permintaan yang buruk.
9. Menghapus perangkat IoT dari List di aplikasi mobile
Fitur ini memungkinkan pengguna menghapus perangkat IoT yang sebelumnya dipilih. Langkah dalam menghapus perangkatnya dapat dilihat pada Gambar 4.14 berikut.
Gambar 4.14 Menghapus Perangkat IoT dari Halaman List
Berdasarkan pada Gambar 4.14, hasil pengujiannya menunjukan bahwa pengguna bisa menghapus perangkat IoT dari List dengan baik.
10. Perangkat IoT mengirim dengan notifikasi
Pada pengujian ini, aplikasi mobile awalnya tidak terbuka dan tidak berjalan di latar belakang. Lalu perintah di bawah ini dijalankan untuk mensimulasikan pengiriman data disertai notifikasi. Perintah ini mensimulasikan bahwa perangkat IoT mengirimkan perubahan status ke Siaga ( ) dengan tinggi air yang sudah mencapai 120 cm.
Setelah perintah di atas dijalankan, muncul notifikasi pada smartphone seperti pada Gamabr 4.15 berikut.
Gambar 4.15 Menampilkan notifikasi di aplikasi mobile
Berdasarkan pada Gambar 4.15, ketika notifikasi tersebut ditekan, aplikasi mobile terbuka dan muncul detail perangkat IoT yang dimaksud.
4.3.2 Pengujian Performa
Pengujian performa mengikuti prosedur yang terdiri dari dua skenario. Ada beberapa pengukuran yang hanya bisa diukur di komputer client dan server. Maka dari itu diukur resource usage CPU dan memory dari IoT Platform hanya di komputer server. Sementara parameter lainnya (latency, success rate, bandwidth) diukur di komputer client.
Pengujian ini diawali dengan membuat 200 identitas perangkat IoT yang berisi data acak menggunakan perintah di bawah ini, kemudian memilih salah satu ID perangkat IoT untuk skenario pengujian 1 dan 3.
Dipilih perangkat IoT dengan ID melalui web
admin. Lalu menjalankan perintah di bawah ini untuk menjalankan pengukuran untuk setiap skenario pengujian.
Perintah di atas menghasilkan berkas (Lampiran D-2 dan D-5) yang merupakan data berformat tabular. Data yang dihasilkan berisi paramater pengukuran berbading dengan waktu. Data tersebut perlu dicocokan dengan hasil pengukuran di komputer client berdasarkan waktu yang sama.
1. Perangkat IoT mengirim data
Skenario ini mensimulasikan perangkat IoT yang mengirimkan data ke IoT Platform dengan perintah di bawah. Jumlah perangkat IoT yang mengirimkan data bervariasi dari 20 hingga 200 dengan selang 20 menggunakan perintah di bawah.
Hasil keluaran berkas kemudian diolah agar menjadi tabel yang dapat dianalisis (Lampiran D-1). Sementara itu pengukuran pada server juga dijalankan secara bersamaan (Lampiran D-2).
Menurut hasil pengukuran latency, hasil yang muncul cukup linear antara jumlah request yang masuk dengan waktu balasan yang datang. Namun, nilainya tidak begitu stabil seperti yang terlihat pada Gambar 4.16.
Gambar 4.16 Latensi saat perangkat IoT mengirim data
Berdasarkan Gambar 4.16, rasio jumlah request berbanding waktu yang dibutuhkan justru semakin baik. Pada jumlah 20 request, waktu yang dibutuhkan rata-rata adalah 100 ms. Artinya sistem menangani dengan kecepatan 200 request/s. Sementara pada jumlah 200 request membutuhkan 620 ms (322 request/s). Berdasarkan hasil ini, sistem dapat menangani rata-rata 278 request/s.
Berikut success rate saat perangkat mengirim data yang dapat dilihat pada Gambar 4.17.
Gambar 4.17 Success rate saat perangkat IoT mengirim data
Berdasarkan Gambar 4.17, pengukuran success rate menunjukan semua request berhasil 100%. Ini menunjukan bahwa sistem dapat bekerja dengan
normal meski dikirimi banyak request (hingga 200). Lalu terdapat bandwidth downstream saat perangkat mengirim data seperti pada Gambar 4.18 berikut.
Gambar 4.18 Bandwidth downstream saat perangkat IoT mengirim data
Berdasarkan Gambar 4.18, pengukuran bandwidth menunjukan nilai yang cukup stabil. Berdasarkan pengukuran ini, penerimaan data (downstream) membutuhkan tetap 137 byte data setiap kali perangkat IoT membuat request ke IoT Platform. Hal ini kemungkinan karena response yang diberikan IoT Platform hanya sebuah string untuk setiap request yang berhasil, kemudian bandwidth upstream yang dapat dilihat pada Gambar 4.19 berikut.
Gambar 4.19 Bandwidth upstream saat perangkat IoT mengirim data
Berdasarkan Gambar 4.19, nilai pengukuran yang muncul saat perangkat IoT mengirim data (upstream) ke IoT Platform rata-rata menggunakan 342 byte untuk setiap request. Kadang sedikit lebih tinggi atau lebih rendah. Kemungkinan karena panjang URI pada request GET yang berbeda-beda tergantung dari panjang nilai parameter sensor. Perangkat IoT bisa jadi membutuhkan sedikit lebih banyak data jika mengirimkan notifikasi.
Pengukuran di server (Lampiran D-2) menunjukkan sistem menggunakan hanya sampai 40% kemampuan CPU seperti yang dapat dilihat pada Gambar 4.20 berikut.
Gambar 4.20 CPU Saat perangkat IoT mengirim data
Berdasarkan Gambar 4.20, hal ini dikarenakan karakteristik program JavaScript di Node.js yang hanya menggunakan satu thread. Sehingga core CPU yang dipakai hanya satu. Sementara komputer sebenarnya memiliki dua core.
Sistem mulai menggunakan CPU hingga 40% saat mendapatkan 200 request.
Berdasarkan pengukuran, sistem tidak menggunakan banyak RAM seperti ditunjujkan pada Gambar 4.21 berikut.
Gambar 4.21 Memory saat perangkat IoT mengirim data
Berdasarkan Gambar 4.21, IoT Platform menggunakan 700 Mb RAM pada kondisi tidak mendapat request. Jumlah ini bisa saja berbeda pada sistem operasi lain. Penggunaan jenis sistem operasi tanpa GUI dapat memberikan performa yang lebih baik. Tidak ada RAM yang dipakai untuk tampilan. Sementara saat mendapat 200 request, IoT Plaform menggunakan 710 Mb RAM. Terjadi penambahan 10 sampai 13 Mb penggunaan untuk 200 request. Sehingga IoT Platform membutuhkan rata-rata 50-65 kB RAM untuk setiap request-nya.
Jumlahnya yang kadang turun tiba-tiba disebabkan sistem operasi yang menggunakan waktunya untuk menghapus cache pada RAM saat tidak digunakan.
2. Pengguna mengakses aplikasi mobile
Skenario ini mensimulasikan pengguna aplikasi mobile yang sedang mengakses data dari IoT Platform. Jumlah pengguna yang mengambil data bervariasi dari 50 hingga 500 dengan selang 50 menggunakan perintah di bawah.
Hasil keluaran berkas kemudian diolah agar menjadi tabel yang dapat dianalisis (Lampiran D-4). Pengukuran pada server juga dijalankan bersamaan dengan itu (Lampiran D-5).
Pengukuran latensi menunjukan hasil yang cukup linear antara jumlah request dari pengguna aplikasi mobile dengan waktu yang dibutuhkan IoT Platform untuk membalas. Namun, rasio jumlah request berbanding waktu yang dibutuhkan justru semakin baik seperti pada Gambar 4.22 berikut.
Gambar 4.22 Latensi saat pengguna mengakses aplikasi mobile
Berdasarkan Gambar 4.22, pada jumlah request 50, waktu yang dibutuhkan rata-rata adalah 230 ms. Artinya sistem menangani 217 request/s. Sementara pada jumlah 500 request, sistem membutuhkan 1550 ms (322 request/s). Berdasarkan hasil ini, sistem dapat menangani rata-rata 295 request/s. Lalu terdapat success rate yang dapat dilihat pada Gambar 4.23.
Gambar 4.23 Success rate saat pengguna mengakses aplikasi mobile Berdasarkan Gambar 4.23, pengukuran success rate menunjukan semua request berhasil 100%. Ini menunjukan bahwa sistem dapat bekerja dengan normal meski dikirimi banyak request. Semua request yang diterima IoT Platform dapat dijawab dengan baik, kemudian terdapat bandwidth downstream yang dapat dilihat pada Gambar 4.24.
Gambar 4.24 Bandwidth downstream saat pengguna mengakses aplikasi mobile
Berdasarkan Gambar 4.24, pengukuran bandwidth menunjukan nilai yang cukup stabil. Berdasarkan pengukuran ini, penerimaan data (downstream) membutuhkan rata-rata 1538 byte data setiap kali pengguna membuat request ke IoT Platform. Besarnya kadang sedikit lebih rendah atau lebih tinggi. Hal ini kemungkinan karena perbedaan isi response yang diterima oleh masing-masing request dari aplikasi mobile. Sedangkan bandwidth upstream dapat dilihat pada Gambar 4.25 berikut.
Gambar 4.25 Bandwidth upstream saat pengguna mengakses aplikasi mobile
Berdasarkan Gambar 4.25, nilai pengukuran yang muncul saat pengguna mengirim data (upstream) ke IoT Platform cenderung tetap yaitu 84 byte untuk setiap request. Kemungkinan karena panjang URI pada request GET yang tetap.
Pengukuran di server (Lampiran D-5) menunjukan sistem menggunakan sampai 60% kemampuan CPU yang dapat dilihat pada Gambar 4.26 berikut.
Gambar 4.26 CPU saat pengguna mengakses aplikasi mobile
Berdasarkan Gambar 4.26, saat request melebihi 250, sistem memilih menambah waktu eksekusi dibandingkan penggunaan CPU. Sedangkan berdasarkan pengukuran, sistem tidak menggunakan banyak RAM seperti ditunjukan pada Gambar 4.27 berikut.
Gambar 4.27 Memory saat pengguna mengakses aplikasi mobile
Berdasarkan Gambar 4.27, IoT Platform menggunakan 700 MB RAM pada kondisi tidak mendapat request. Jumlah ini bisa saja berbeda pada sistem operasi lain. Penggunaan jenis sistem operasi tanpa GUI pada server harusnya memberikan performa yang lebih baik. Tidak ada RAM yang dipakai oleh tampilan layar. Sementara saat mendapat 500 request, IoT Plaform menggunakan 740 MB RAM. Terjadi penambahan 40 Mb untuk 500 request. Sehingga jika dihitung, IoT Platform membutuhkan rata-rata 80 kB RAM untuk setiap request.
