Penerapan Metode LZW dalam Kompresi File Chat Multimedia pada Sistem E-Marketplace Sarana Upakara Bali
on
Jurnal Ilmu Komputer VOL. XI No. 2
p-ISSN: 1979-5661
e-ISSN: 2622-321X
Penerapan Metode LZW dalam Kompresi File Chat Multimedia pada Sistem E-Marketplace Sarana Upakara Bali
Ni Luh Devi Lingga Pratiwi1, I Gede Santi Astawa2, Ida Bagus Made Mahendra3, Luh Arida Ayu R.P4.
-
1,2,3,4 Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam, Universitas Udayana Jl Kampus Bukit Jimbaran (80361), Badung, Bali, Indonesia [email protected]
Abstrak
Sarana upakara dalam agama Hindu merupakan salah satu unsur untuk membangun kesucian upacara. Saat ini, pembelian sarana upakara masih dilakukan dengan bertemu langsung antara penjual dan pembeli. Cara ini memiliki kekurangan dari segi waktu dan kelengkapan satu jenis banten yang berbeda-beda sesuai dengan Desa, Kala, Patra. Peningkatan pelayanan dalam bertransaksi sarana upakara dapat dilakukan melalui e-marketplace yang menyediakan berbagai sarana Upakara.
E-marketplace upakara berbasis web ini mempunyai beberapa fitur tambahan diantaranya integrasi pembayaran dengan API Midtrans, fitur chatting dengan metode long polling untuk memudahkan interaksi antar penjual dan pembeli, serta menggunakan algoritma LZW untuk kompresi file multimedia dalam mengirim file saat melakukan chatting. Proses kompresi ini bertujuan untuk menghemat kebutuhan tempat penyimpanan dan waktu transmisi data. Pengujian yang dilakukan menghasilkan kesimpulan bahwa e-marketplace ini optimal dilakukan saat pengguna yang mengunjungi web kurang dari 200 dalam waktu bersamaan, kualitas citra dan video kompresi cukup baik, serta ratio pemampatan kompresi sebesar 84.84% pada file gambar, 30.09% pada file audio dan 41.44% pada file video.
Keywords: E-marketplace, Chatting, Kompresi, Algoritma LZW
Agama Hindu dalam pelaksanaan upacara keagamaan memiliki lima unsur yang bersinergi dalam membangun kesucian upacara. Salah satunya sarana upakara bebantenan (Suardana, 2016). Saat ini masyarakat Bali di wilayah perkotaan kurang memiliki waktu untuk membuat sarana upakara, sehingga masyarakat lebih memilih cara yang praktis yaitu membelinya langsung. Selain dari sisi efisiensi waktu, cara tersebut dipilih karena kurangnya keterampilan masyarakat Hindu dalam membuat banten dan kelangkaan bahan baku. Hal ini mengakibatkan tingginya permintaan masyarakat terhadap pembelian sarana upakara. Saat ini, pembelian sarana upakara masih dilakukan secara konvensional yaitu dengan bertemu langsung antara penjual dan pembeli. Namun cara ini memiliki kekurangan dari segi waktu dan lokasi. Selain itu cara pembuatan ataupun kelengkapan satu jenis banten dapat berbeda-beda sesuai dengan Desa, Kala, Patra (Tempat, Waktu, dan Keadaan). Ketidaksesuaian antara kelengkapan dan harga dari pembelian sarana upakara akan berdampak pada menurunnya nilai dan esensi dari suatu upacara keagamaan. Maka dari itu, dalam meningkatkan pelayanan terhadap transaksi sarana upakara, e-marketplace dapat digunakan untuk melakukan transaksi jual beli maupun memasarkan sarana upakara secara online yang menjangkau masyarakat luas.
E-marketplace merupakan salah satu pengembangan e-commerce dimana e-marketplace menjadi media perantara yang mempertemukan antara penjual dan pembeli (Naovarat, Juntongjin 2015). E-Marketplace memungkinkan pembeli untuk menemukan berbagai jenis barang dan jasa yang ditawarkan dari berbagai penjual yang berbeda. Selain itu e-marketplace menyediakan fasilitas bertransaksi yang aman dan mudah bagi penjual maupun pembeli. Penelitian sejenis sebelumnya telah dilakukan oleh (Amijaya, 2016) mengenai Perancangan
dan Implementasi E-Commerce Prasarana Bebantenan Berbasis Web. Penelitian tersebut sudah berhasil membangun e-commerce prasarana bebantenan, namun masih memerlukan beberapa pengembangan dalam fitur pembayaran. Selain itu e-commerce yang dibangun, belum menyediakan fitur agar penjual dan pembeli dapat berinteraksi secara langsung melalui e-commerce tersebut. Pada penelitian ini, untuk mewadahi penjual, pembeli dan barang yang ditawarkan, dikembangkanlah e-marketplace dengan fitur chatting untuk komunikasi antara penjual dan pembeli. Saat berinteraksi pada website, penjual dan pembeli banyak menggunakan file multimedia dalam menyampaikan permintaan sesuai dengan sarana upakara yang diperlukan (made by request). Maka dari itu, e-marketplace ini juga mengusulkan fitur chatting dengan metode kompresi LZW (Lempel-Ziv-Welch). Kompresi file multimedia digunakan untuk optimalisasi penyimpanan dan kecepatan transfer data pada website ecommerce. Teknik kompresi LZW dipilih karena algoritma kompresi LZW merupakan jenis lossless dimana hasil file sebelum dan sesudah kompresi tidak akan berbeda secara signifikan.
E-commerce adalah suatu proses membeli dan menjual produk-produk secara elektronik oleh konsumen dan dari perusahaan ke perusahaan dengan komputer sebagai perantara transaksi bisnis. Penggunaann sistem e-commerce yang biasa disebut juga dengan istilah E-com atau Emmerce atau EC dapat menguntungkan banyak pihak, baik pihak konsumen, maupun pihak produsen dan penjual (retailer). Bagi pihak konsumen, menggunakan E-Com dapat membuat waktu berbelanja menjadi singkat. Selain itu, harga barang-barang yang dijual melalui E-Com biasanya lebih murah dibandingkan dengan harga di toko, karena jalur distribusi dari produsen barang ke pihak penjual lebih singkat dibandingkan dengan toko konvensional. (Ramadijanti, Badriyah, 2002). Penggolongan e-commerce yang dilakukan orang adalah berdasarkan sifat transaksinya, antara lain (Whitten, dkk 2004):
-
a. Business to Business (B2B)
Jenis transaksi dimana pembeli biasanya membeli dalam jumlah besar karena akan dijual kembali. Contoh penjualan grosir.
-
b. Business to Consumer (B2C)
Jenis transaksi dimana pembelinya perorangan dan tidak punya tujuan untuk menjualnya kembali biasanya semacam toko online yang menjual berbagai macam barang.
-
c. Consumer to Consumer (C2C)
Jenis transaksi dimana pembelinya perorangan yang tidak mempunyai tujuan untuk dijual kembali dan penjualnya juga perorangan yang tidak menyediakan bermacam-macam barang melainkan hanya beberapa barang saja. Contoh: online advertising
-
d. Consumer to Busines (C2B)
Termasuk kedalam kategori ini adalah perseorangan yang menjual produk atau layanan kepada organisasi, dan perseorangan yang mencari penjual, berinteraksi dengan mereka dan menyepakati suatu transaksi.
Saat ini transaksi online menjadi sangat populer di banyak negara. Ada dua jenis toko online yaitu penjual memiliki website sebagai tokonya sendiri (E-Commerce dan pasar online (EMarketplace) dimana penjual dapat mendaftarkan tokonya melalui penyedia layanan online. EMarketplace adalah pasar online yang digunakan untuk menjual barang melalui situs pihak ketiga. Ini membantu penjual mengurangi biaya pembukaan toko fisik dan mengantarkan barang ke pelanggan. Hal ini juga memudahkan pembeli untuk melakukan keputusan pembelian melalui situs web karena banyak produk dapat dibandingkan dari banyak penjual melalui e-marketplace. E-Marketplace dapat dikelompokkan menjadi banyak jenis. Ada tiga jenis e-marketplace yang dapat dikategorikan dengan model bisnis yaitu B2B (Business-to-Business), B2C (Business-to-Customer) dan C2C (Customer-to-Customer). Saat ini model bisnis yang sedang populer untuk E-Marketplace adalah model B2C. (Naovarat, Panitharn, 2015)
LZW merupakan kependekan kata dari Lempel-Ziv-Welch. Abraham Lempel, Jacob Ziv, dan Terry Welch adalah pencipta algoritma kompresi lossless universal ini. Kelebihan algoritma ini yaitu cepat dalam implementasi dan kekurangannya yaitu kurang optimal karena hanya melakukan analisis terbatas pada data. Algoritma ini melakukan kompresi dengan menggunakan kamus, di mana fragmen-fragmen teks digantikan dengan indeks yang diperoleh dari sebuah “kamus”. Pendekatan ini bersifat adaptif dan efektif karena banyak karakter dapat dikodekan dengan mengacu pada string yang telah muncul sebelumnya dalam teks. Prinsip kompresi tercapai jika referensi dalam bentuk pointer dapat disimpan dalam jumlah bit yang lebih sedikit dibandingkan string aslinya. Ada beberapa faktor yang sering menjadi pertimbangan dalam memilih suatu metode kompresi yang tepat, yaitu kecepatan kompresi, sumber daya yang dibutuhkan (memori, kecepatan PC), ukuran file hasil kompresi, besarnya redundansi, dan kompleksitas algoritma. Tidak ada metode kompresi yang paling efektif untuk semua jenis file.
Aplikasi web awalnya dikembangkan dengan model client / server, dimana client web selalu menjadi inisiator transaksi dan meminta data dari server. Dengan demikian, tidak ada mekanisme bagi server secara mandiri mengirim, atau mendorong, data ke client ketika client tidak membuat permintaan. Untuk mengatasi kekurangan ini, pengembang aplikasi Web dapat menerapkan teknik yang disebut long polling HTTP, dimana client terlebih dahulu menghubungi server yang mempunyai informasi baru. Server terbuka dalam menerima permintaan sehingga data baru dapat tersedia. Setelah data tersedia, server merespon dan mengirim informasi baru. Ketika client menerima informasi baru, client segera mengirim permintaan lain, dan operasi diulang. Hal ini secara efektif meminimalkan fitur push server. Pada website yang menggunakan long polling HTTP untuk streaming data, dapat menghasilkan lingkungan komunikasi web low-latency and low-overhead, selain itu dapat menghasilkan fitur untuk mengirim pesan ke satu client, grup client, dan semua client. (Hanson, 2014).
Long polling dikenal juga dengan istilah asynchronous polling. Pada long polling setiap request akan ditahan oleh server dan dibiarkan terbuka selama waktu tertentu (default 45 detik). Apabila selama waktu yang telah ditentukan tidak ada event yang terjadi, server akan memberikan response timeout dan meminta untuk melakukan request ulang. Sedangkan apabila terdapat event yang terjadi, server akan langsung mengirimkan informasi terbaru kepada client dan meminta client untuk melakukan request ulang. (Pradana, 2014)
Peak signal to noise ratio (PSNR) adalah rasio antara kekuatan maksimum dari sebuah sinyal dan kekuatan dari noise yang mempengaruhi citra. Dikarenakan banyak sinyal yang mempunyai jarak dinamik (dynamic range) yang sangat lebar. PSNR biasanya diekspresikan dalam skala logarithmic decibel. PSNR digunakan untuk mengetahui perbandingan kualitas citra cover sebelum dan sesudah disisipkan pesan atau kompresi. Untuk menentukan PSNR, terlebih dahulu harus ditentukan nilai MSE (Mean Square Error). MSE adalah nilai error kuadrat rata-rata antara citra asli dengan citra manipulasi (dalam kasus steganografi; MSE adalah nilai error kuadrat rata-rata antara citra asli (cover-image) dengan citra hasil penyisipan (stego-image).
Dalam suatu pengembangan dan pelaksanaan rekonstruksi gambar diperlukan perbandingan antara gambar hasil rekonstruksi dengan gambar asli. Ukuran umum yang digunakan untuk tujuan ini adalah PSNR (Peak Signal to Noise Ratio). Nilai PSNR yang lebih tinggi menyiratkan kemiripan yang lebih erat antara hasil rekonstruksi dan gambar asli. PSNR didefinisikan sebagai:
C2
PSNR = 10 log10(-≡..............................(2.1)
MSE J
Dimana MSE dinyatakan sebagai mean square error yang didefinisikan sebagai:
1 m n
MSE= MN∑Σ(Sχy- Cχy)2 ...........................(2.2)
"=1 y-1
Keterangan:
-
• Cmax : nilai pixel terbesar pada keseluruhan citra
-
• x dan y : koordinat suatu titik pada citra
-
• M dan N : dimensi dari citra
-
• S : citra tersisipi (stego image)
-
• C : citra asli (cover image)
PSNR sering dinyatakan dalam skala logaritmik dalam decibel (dB). Nilai PSNR jatuh dibawah 30 dB mengindikasikan kualitas yang cukup baik, dimana distorsi yang dikarenakan penyisipan terlihat jelas. Sedangkan nilai MSE menandakan jumlah erorr yang terjadi dari perbandingan kedua gambar. Sehingga nilai MSE yang mendekati nol menghasilkan gambar dengan tingkat kemiripan yang sama. (Cheddad, dkk, 2010).
Pengujian rasio kompresi algoritma LZW digunakan untuk menganalisis sejauh mana algoritma kompresi LZW dapat bekerja optimal pada file multimedia (gambar, audio dan video). Rasio kompresi juga digunakan untuk mengetahui nilai pemampatan pada ukuran file yang dikompresi (Prasetyo,2016). Adapun rumus untuk menghitung rasio kompresi yaitu: a
Rasio Kompresi = 100% — -— / 100% 0...........................(2.3)
a = Ukuran File sebelum dikompresi b = Ukuran File sesudah dikompresi
Pada bab ini akan dijelaskan mengenai langkah-langkah yang dilakukan dalam merancang aplikasi E-Marketplace Sarana Upakara Bali dalam diagram fishbone seperti pada gambar 1.
Gambar 1. Diagram Fish Bone Penelitian
Pada diagram fishbone telah dijabarkan langkah-langkah dalam membangun e-marketplace sarana upakara yang dimulai dari identifikasi permasalahan yaitu proses jual beli sarana upakara masih dilakukan secara konvensional sehingga kurangnya efisiensi waktu dan lokasi hingga mencapi tujuan akhir sebuah E-marketplace Sarana Upakara dengan Fitur Kompresi Chatting berbasis Web.
Kebutuhan fungsional merupakan kebutuhan yang mendefinisikan fungsi apa saja yang mampu dilakukan oleh sistem. Kebutuhan fungsional sistem ditujukan pada tabel 1.
Tabel 1. Kebutuhan Fungsional Sistem
No. |
Kebutuhan |
1. |
E-marketplace berbasis website dapat menangani transaksi-transaksi dengn fitur e-commerce |
2. |
Pembeli dan penjual pada e-marketplace sarana upakara dapat melakukan interaksi melalui fitur chatting yang disediakan |
3. |
Fitur chatting e-commerce menggunakan algoritma kompresi LZW untuk mengurangi penyimpanan dan meminimalkan pengunaan kuota saat transfer data dengan jenis (image, audio, video) |
4. |
Sistem dapat menangani proses pembayaran, namun belum dapat menangani proses pengiriman pesanan melalui sistem. |
Sistem ini dibangun dengan teknik pemrograman berorientasi objek sehingga sistem akan dirancang menggunakan Unified Modeling Language diantaranya Use Case Diagram, Activity Diagram, Class Diagram, dan Entity Relational Diagram.
Use Case Diagram menjabarkan aktor yang terlibat dan hal-hal apa saja yang dapat dilakukan pada sistem. Terdapat 3 pengguna dalam sistem ini yaitu Pembeli, Penjual, dan Admin yang akan di jabarkan pada gambar 2, gambar 3 dan gambar 4.
Gambar 2. Use Case Diagram Pembeli
Gambar 2 merupakan usecase diagram dari aktor pembeli. Dimana pada gambar 2 digambarkan hubungan pembeli dengan usecase dan hubungan antar usecase.
Gambar 3. Use Case Diagram Penjual
Gambar 3 merupakan usecase diagram dari aktor penjual. Dimana pada gambar 3 digambarkan hubungan penjual dengan usecase dan hubungan antar usecase yang ada didalamnya.
Gambar 4. Use Case Diagram Admin
Gambar 4 merupakan usecase diagram dari aktor penjual. Dimana pada gambar 4 digambarkan hubungan admin dengan usecase dan hubungan antar usecase yang ada didalamnya.
Activity Diagram berikut menjabarkan aktivitas yang terdapat pada setiap use case pada use case diagram. Diagram activity yang ditampilkan hanya pada proses chatting dengan algoritma kompresi LZW yang dijelaskan pada gambar 5.
Gambar 5. Activity Diagram Proses Chatting
Gambar 6. Merupakan perancangan dari E-marketplace Sarana Upakara yang dimodelkan dengan Class Diagram yang dibangun berdasarkan pendefinisian dari Use Case Diagram dimana masing-masing fungsi yang terdapat pada setiap kelas dibuat untuk memenuhi kebutuhan proses yang terdapat pada Use Case.
Gambar 6. Class Diagram E-Marketplace Sarana Upakara
Berikut adalah perancangan sistem yang dimodelkan dengan sequence diagram yang menggambarkan kelakuan atau perilaku class pada use case dengan mendeskripsikan waktu hidup objek dan pesan yang dikirimkan dan diterima antar class. Diagram sequence yang ditampilkan hanya pada proses chatting dengan algoritma kompresi LZW yang dijelaskan pada gambar 7.
Gambar 7. Sequence Diagram Proses Chatting
Berikut adalah perancangan Entity Relationship Diagram dari E-marketplace Sarana Upakara Bali untuk mendefinisikan entitas yang terlibat serta relasi antar entitas.
Gambar 8. Entity Relational Diagram
Dari ERD pada gambar 8, terdapat 11 entitas yang terlibat diantaranya entitas penjual, produk, kategori, customer, pemesanan, pembayaran, chat_conversation, chat_content, chat_notification dan chat_file.
Perancangan antarmuka (interface) sistem digunakan untuk merancang desain antarmuka dari sistem yang akan dibangun. Perancangan antarmuka akan menggambarkan tata letak konten serta menu – menu yang terdapat dari sistem. Gambar 9, gambar 10 dan gambar 11 merupakan tampilan halaman untuk pembeli, penjual dan admin yang disertai dengan konten-konten per halaman.
Gambar 9. Desain Interface Halaman Utama User
Gambar 10. Desain Interface Halaman Utama Pembeli
Gambar 11. Desain Interface Halaman Utama Admin
FOOTER
Gambar 12. Desain Interface Halaman Chatting
Sistem dirancang pada komputer dengan Sistem operasi OS X Yosemite. Sistem dirancang di sebuah laptop yang memiliki Processor Intel® Core™ i5 CPU @2.5 GHz, RAM 4 GB, Hardisk 750 GB.
Sedangkan dari segi perangkat lunak (software) mulai tahap penelitian sampai tahap implementasi sistem, menggunakan beberapa software. Sistem ini dibangun menggunakan teknologi berbasis web menggunakan HTML dan CSS, menggunakan bahasa pemrograman JavaScript dan PHP, menggunakan basis data MySQL serta menggunakan API pembayaran dari pihak ketiga Midtrans.
Skema basis data sistem seperti pada Gambar 4.1 yang merupakan turunan dari skema ERD yang dirancang pada Bab 3 dalam sub bab 3.2.5. Dari gambar 4.1 ini terdapat tiga belas tabel basis data yang dihasilkan. Adapun tabel yang dihasilkan dari rancangan ERD akan dijabarkan sebagai berikut :
Gambar 13. Implementasi Database Sistem
Tahap Implementasi merupakan kelanjutan dari tahap sebelumnya dimana pada tahap ini penulis akan mengimplementasikan perancangan e-marketplace sarana upakara dengan fitur kompresi file multimedia pada chatting, tahapan yang dilakukan penulis adalah tahap implementasi fungsi-fungsi operasi pada sistem, implementasi proses kompresi file multimedia dan implementasi proses chatting
Implementasi sistem e-marketplace sarana upakara ini akan dijelaskan berdasarkan fungsi – fungsi operasi yang digunakan pada sistem yang dibangun. Berikut ini merupakan penjelasan dari bagian utama proses order yang meliputi Sourcecode login, Sourcecode detail_produk, Sourcecode detail_keranjang, Sourcecode checkout, Sourcecode cek_status, Sourcecode update_status.
Pada aplikasi ini terdapat tiga entitas utama yang menjadi inti dari sebuah aplikasi chatting, yaitu channel, user, dan message yang sudah diimplementasikan pada database dengan tabel chat_conversation, chat_content, dan chat_notification. Long-Polling melakukan pemeriksaan dalam jarak waktu yang lama dalam selang waktu 50 detik hingga 2 menit (tergantung pengaturan pada sistem) dan akan menghubungi client hanya saat terdapat data baru pada database yang digunakan.
Proses chatting pada sistem menggunakan metode XHR (XML HTTP Request)/ AJAX Long-Polling (Server). Untuk menjalankan metode long-polling sehingga chatting dapat berjalan secara realtime, sistem harus memiliki sub domain yang bertugas menjalankan proses permintaan menuju server secara berkesinambungan. Cara kerja dari metode ini yaitu server melakukan long-polling yang artinya akan mengunggu data baru dari database selama 50 detik, dimana proses long-polling server berjalan saat terdapat permintaan dari Client (AJAX). Proses permintaan akan dijalankan oleh sub domain dan status pada AJAX akan tertunda selama 5055 detik, maka mulai dari sini alur akan terbagi menjadi 2 kondisi yaitu:
-
1. Server akan berstatus timeout saat melebihi dari waktu 50 detik dan client akan bertugas memulai Request AJAX baru untuk 50 detik berikutnya, seterusnya berjalan dan melakukan perulangan. Proses ini yang akan menjadikan fitur chatting berjalan secara realtime.
-
2. Server akan berstatus sukses (kode 200) jika ada data baru dalam rentan waktu kurang dari 50 detik. Tugas server mengirim JSON data baru tersebut (misalnya data chat baru), dan tugas client dalam menerima data akan mengolah menjadi bentuk template HTML (bubble chat), lalu client kembali melakukan Request AJAX baru untuk 50 detik berikutnya. Fitur chatting kembali berjalan seacara realtime setelah mencetak data baru.
Pada penerapannya untuk menjalankan fitur chatting dengan algoritma kompresi file multimedia diperlukan 1 buah domain dengan 2 sub domain yaitu domain upakara.cf, subdomain
chat.upakara.cf, subdomain background.upakara. cf. Kompresi untuk file video dan audio tidak dapat dilakukan pada domain utama. Hal ini dikarenakan kompresi file video dan audio memerlukan proses lebih lanjut dalam mengubah file kedalam bentuk binary.
Setelah proes chatting dapat berjalan pada sistem, selanjutnya untuk menangani kompresi pada file multimedia yang dikirimkan oleh pengguna digunakan algoritma kompresi LZW. Saat pengguna ingin mengirimkan satu file pada halaman chatting, pengguna harus memilih file yang ingin dikirimkan dengan menekan tombol upload file. Setelah file tersebut dikirimkan, sistem akan mengenali format dari file tersebut. Semua file dapat dikirimkan pada fitur chatting ini, hanya saja file multimedia dengan format *.jpg, *.png, *.mp3, *.mp4 yang akan dikompresi dengan algoritma LZW. Alur kerja algoritma kompresi LZW pada chatting di gambarkan pada gambar 14.
File dikirim ke server dan
Client melakukan request
Gambar 14. Langkah-Langkah Kompresi LZW File Multimedia
Pada Gambar 15 dan 16 merupakan hasil dari file gambar dan file video setelah di kompresi dengan algoritma LZW pada fitur chatting. Hasil kompresi file audio tidak ditampilkan karena tidak dapat di visualisasikan.
Gambar 15. (a) File Gambar Sebelum di kompresi, (b) File Gambar Setelah Dikompresi
Gambar 16. (a) Frame Video Sebelum di kompresi, (b) Frame Video Setelah Dikompresi
-
4.3.4 Implementasi Antar Muka Sistem
Gambar 17. Interface Halaman Utama User
Gambar 18. Interface Halaman Utama Pembeli
Gambar 19. Interface Halaman Utama Penjual
Gambar 20. Interface Halaman Utama Admin
Tahap pengujian merupakan tahap untuk memastikan apakah sistem yang dibuat telah memenuhi tujuan yang ingin dicapai. Pada penelitian ini untuk pengujian sistem terdapat dua sisi pengujian yaitu pertama dari sisi performansi website e-marketplace yang melingkupi stres testing dan black box testing. Kedua dari sisi respon pengguna terhadap sistem yang melingkupi pengujian efisiensi penerapan kompresi dengan algoritma LZW dan pengujian terhadap respon pengguna dengan kuesioner.
Stress Testing
Pada pengujian Stress Testing, terdapat dua pengujian yang dilakukan meliputi
-
a. Performance Test
Hasil dari uji performace test menggunakan aplikasi Jmeter terdapat dalam tabel 4.1.
Tabel 2. Hasil Nilai Performance test
User |
Error (%) |
Avg.click time (ms) |
Throughput (kb/s) |
5 |
0 |
234 |
64.748 |
10 |
0 |
670 |
75.195 |
50 |
0 |
2984 |
220.534 |
200 |
0 |
3049 |
220.634 |
300 |
3.2 |
4748 |
789 |
500 |
5.3 |
6849 |
1267 |
800 |
7.2 |
9839 |
1829 |
Dapat dilihat bahwa semakin banyak user virtual yang melakukan akses pada website, maka semakin besar pula persentase nilai error / kegagalan akses yang dialami oleh pengguna saat membuka halaman pertama website. Jenis permasalahan performansi aplikasi salah satunya biasa terjadi pada waktu tunggu atau loading time yang sangat lama (long loading time). Dimana ditentukan bahwa Aplikasi/website tidak mungkin untuk melakukan loading di atas satu menit, load time harus di bawah 10 detik jika memungkinkan. Melalui test performansi menggunakan aplikasi Jmeter, dapat disimpulkan bahwa website upakara.cf akan mengalami waktu tunggu yang melebihi 3 detik saat diakses oleh lebih dari 200 user.
-
b. Stress Test
Tools yang digunakan pada stress test website berupa website online dengan alamat LoadStrom.com. Skenario stress test yaitu website akan diberikan beban berupa 10 user yang akan mengakses halaman dashboard website selama 10 menit secara bersamaan. Setiap user mengakses website tersebut secara terus menerus dengan interval waktu 1 menit. Dari hasil pengujian performance dan pengujian stress website upakara.cf, dapat disimpulkan bahwa performansi dan kecepatan website sudah sesuai dengan standar website pada umumnya. Namun untuk daya tampung user dari sisi e-marketplace, dapat disimpulkan belum memadai karena suatu website e-commerce harus dapat menampung akses lebih dari 10.000 users dalam waktu yang bersamaan. Maka dari itu diperlukan peningkatan kualitas dan kecepatan server untuk dapat mencapai angka tersebut.
Black Box Testing
Perhatian utama dalam pengujian black box adalah fungsionalitas program yang sering disebut functional testing yang merupakan sebuah metode pengujian yang fokus pada eksekusi fungsi dalam program dan kesesuaian data input dan output berdasarkan kebutuhan sistem. Hasil pengujian ini memberikan seluruh kebutuhan fungsional sistem berdasarkan tahap analisis kebutuhan yang berjalan sesuai dengan harapan dan memenuhi seluruh kebutuhan dari sisi pembeli, penjual dan admin.
Pengujian Efisiensi Penerapan Kompresi dengan Algoritma LZW
-
a. Pengujian Kesamaan Citra
Mean square error (MSE) merupakan rata-rata kuadrat nilai kesalahan antara citra sebelum di kompresi dengan citra hasil sesudah dikompresi. Jika nilai MSE semakin kecil pada hasil perbandingan citra, maka hasil citra setelah kompresi semakin mendekati citra sebelum di kompresi. Dari tabel 4.5 dan 4.6 rata – rata nilai MSE dari 44 data gambar dan 15 data frame pada video masing-masing sebesar 58,715 dan 90,000. Sedangkan untuk nilai PSNR dibawah 30 dB mengindikasikan kualitas yang cukup baik, dimana terdapat beberapa perbedaan gambar karena ketidaksesuaiin bit dari masing-masing data. Nilai PSNR didapatkan dari nilai MSE, jadi nilai PSNR dipengaruhi oleh nilai MSE. Rata – rata nilai PSNR yang didapat adalah 30.861 untuk kompresi gambar dan kompresi video sejumlah 29.749. Melalui nilai MSE dan PSNR dapat disimpulkan bahwa hasil kompresi dari algoritma kompresi LZW ditinjau dari sisi kesamaan citra pada file video dan audio menghasilkan kualitas gambar cukup baik. Hal ini dikarenakan besarnya ratio pemampatan dari file citra dan video.
-
b. Pengujian Rasio Kompresi
Pada pengujian ini dilakukan terhadap 20 file video dalam format MP4. Melalui pengujian tersebut dihasilkan jumlah rata-rata presentase kompresi dari 20 data video adalah 41.44%. Dari tabel 4.7, 4.8, dan 4.9 dapat disimpulkan bahwa rasio kompresi masing-masing file adalah 84.84% pada file gambar, 30.09 % pada file audio dan 41.44% dari file video. Melalui hasil presentase rasio kompresi, dapat disimpulkan bahwa algoritma kompresi LZW optimal pada file gambar kemudian dilanjutkan pada file video dan terakhir pada file audio. Hasil tersebut juga dapat mewakilkan bahwa dengan berjalanannya proses kompresi pada chatting, beban website menjadi lebih ringan ketika dilakukan pengiriman file multimedia pada fitur chatting.
Pengujian terhadap respon pengguna
Dari hasil kuisioner dari 10 pengguna dan setiap kuisioner terdiri dari 10 pertanyaan maka didapatkan hasil 72% customer merasa sangat setuju, 28% setuju, Pada sistem yang dibangun mampu memberikan kemudahan, hal ini dapat dilihat dari pertanyaan no 3 dan no 10 yang memiliki skor paling tinggi dengan nilai skor 39. Jadi dapat disimpulkan bahwa sistem ini mampu memberikan kemudahan bagi pengguna dalam berbelanja sarana upakara dan melakukan transaksi.
Berdasarkan pada penelitian yang telah dilakukan, maka dapat diambil kesimpulan meliputi
-
1. Hasil survey respon pengguna melalui kuesioner menyatakan bahwa 72% pengguna merasa sangat setuju dan 28% setuju dapat disimpulkan bahwa sistem ini mampu memberikan kemudahan bagi pengguna dalam berbelanja sarana upakara dan melakukan transaksi.
-
2. Pengujian nilai MSE dan PSNR terhadap citra sebelum dan sesudah kompresi berada pada rentang cukup baik dengan ratio pemampatan kompresi sejumlah 84.84% pada file gambar, 30.09 % pada file audio dan 41.44% pada file video maka dapat disimpulkan bahwa algoritma kompresi LZW dapat mengefisienkan fitur chatting website dengan ratio kompresi yang cukup besar.
-
3. Pengujian performansi website dan stress testing memberikan hasil dari nilai waktu tunggu (loading time) dimana website akan berjalan efektif apabila kurang dari 200 pengguna melakukan akses dalam waktu yang bersamaan.
References
Amijaya, I.M.D. 2016. Perancangan dan Implementasi E-Commerce Prasarana Bebantenan Berbasis Web. FMIPA UNUD: Laporan Akhir Tidak Diterbitkan
Hanson, Joe. 2014. “What is HTTP Long Polling?”. [Online] Tersedia : https://www.pubnub.com/blog/2014-12-01-http-long-polling [20 Mei 2018]
O’brien, James A and George M. Marakas. 2011. Introduction to Information xSystem. Mc companies.
Kenneth, Laudon, 2014. E-Commerce 2014 (10th Edition), Prentice Hall.
Linawati., Henry, P. 2004. “Perbandingan Kinerja Algoritma Kompresi Huffman, LZW, dan DMC pada Berbagai Tipe File ”. Jurnal Integral Vol. 9 No. 1, Maret 2004
Muhammad, A., Subandi, W. 2012. Studi Perbandingan Kinerja Metode LZW (Lempel-Ziv-Welch) dan Metode Huffman untuk Kompresi Data Video dan Audio Pada Aplikasi Kompresi Data. STIMIK GI MDP: Laporan Akhir Tidak Diterbitkan
Naovarat, Sirot dan Panitharn Juntongjin. (2015). Factor that affecting success of EMarketplace in Thailand. Makalah disampaikan dalam International
Conference on Computer Science and Information Systems (ICCSIS-15)
Pradana, F., Aditya. 2014. “Implementasi Bidirectional Http・Pada Aplikasi Chat Berbasis Web Menggunakan Protokol Bayeux ”. Institut Pertanian Bogor: Laporan Akhir Tidak Diterbitkan
Ramadijanti. N., Badriyah. T. 2002. Electronic Commerce (E-Commerce). ITS, Surabaya
Satyapratama. A., Widjianto., Yunus. M. 2015. “Analisis Perbandingan Algoritma LZW dan
Huffman pada Kompresi File Gambar BMP dan PNG”. Jurnal Teknologi Informasi Vol. 6 No. 2
Suardana, I.B.R. 2016. Manajemen Kreatif Yadnya. Artikel [Online]Tersedia:http://phdi.or.id/artikel/manajemen-kreatif-yadnya [19 Mei 2018 ]
Sunarto, Andi SEI. 2009. Seluk Beluk Ecommerce. Garailmu, Jogjakarta.
Wijaya. A., Widodo .S. 2009. “Kinerja dan Performa Algoritma Kompressi Lossless Terhadap
Objek Citra Digital”. [Online] Tersedia:
http://repo.pens.ac.id/37/1/1129e663e92cb5514f4dcf3e1461.pdf. [19 November 2017]
82
Discussion and feedback