-
Kompresi Data dengan Algoritma LZW
pada REST Web Service
Artikel Ilmiah
Peneliti:
Ardy Mathias Jadera (672010112)
Magdalena A. Ineke Pakereng, M.Kom.
Program Studi Teknik Informatika
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Salatiga
Juli 2016
-
Kompresi Data dengan Algoritma LZW
pada REST Web Service
Artikel Ilmiah
Diajukan kepada
Fakultas Teknologi Informasi
untuk memperoleh Gelar Sarjana Komputer
Peneliti:
Ardy Mathias Jadera (672010112)
Magdalena A. Ineke Pakereng, M.Kom.
Program Studi Teknik Informatika
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Salatiga
Juli 2016
-
Kompresi Data dengan Algoritma LZW pada REST Web Service
1) Ardy Mathias Jadera, 2) Magdalena A. Ineke Pakereng
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Jl. Diponegoro 52-60, Salatiga 50711, Indonesia
Email: 1) [email protected], 2) [email protected]
Abstract REST Web Service is becoming more popular is used as a
medium of exchange of
data between the mobile device with the server. Mobile devices
such as phones based on
Android to Windows-based tablets even have a data plan or WiFi
internet paid for access
to the service from the server. The larger the data transmitted,
the longer the process for
sending and receiving. It would also make the network becomes
busy, and also the
amount of toll charges incurred, if the data packet internet
use. The data transmitted can
be reduced in size without losing the meaning of information in
it, using compression
algorithms. In this study, the LZW compression algorithm
implemented on a REST Web
Service. In this study analyzed the advantages and disadvantages
in terms of the
implementation of this compression. The results showed that
compression can reduce the
size of the text data up to 11% of actual size. So that can
directly save the use of data
packets on the mobile device. The larger the file, the smaller
the percentage of added time
due to the process of compression / decompression. Deficiencies
found is the presence of
extra time compression and decompression processes that can
affect the total time.
Keywords: Data Compression, LZW, REST Web Service
Abstrak REST Web Service semakin popular digunakan sebagai media
pertukaran data
antara perangkat mobile dengan server. Perangkat mobile seperti
ponsel berbasis Android
sampai bahkan tablet berbasis Windows menggunakan paket data
internet yang berbayar
atau WiFi untuk dapat mengakses layanan dari server. Semakin
besar data yang
ditransmisikan, semakin lama proses untuk mengirim dan menerima.
Hal ini juga akan
mengakibatkan jaringan menjadi lebih sibuk, dan juga banyaknya
biaya pulsa yang
dikeluarkan, jika paket data internet digunakan. Data yang
dikirimkan dapat diperkecil
ukurannya tanpa menghilangkan makna informasi di dalamnya,
dengan menggunakan
algoritma kompresi. Pada penelitian ini diimplementasikan
algoritma kompresi LZW
pada REST Web Service. Pada penelitian ini dianalisis keuntungan
dan kerugian dalam
hal implementasi kompresi ini. Hasil penelitian menunjukkan
bahwa kompresi dapat
memperkecil ukuran data teks sampai dengan 11% dari ukuran
sebenarnya. Sehingga
secara langsung dapat menghemat penggunaan paket data pada
perangkat mobile.
Semakin besar file, maka semakin kecil persentase tambahan waktu
akibat proses
kompresi/dekompresi. Kekurangan yang ditemukan adalah adanya
waktu tambahan
proses kompresi dan dekompresi yang dapat mempengaruhi total
waktu.
Kata Kunci: Kompresi Data, LZW, REST Web Service
1)Mahasiswa Program Studi Teknik Informatika, Fakultas Teknologi
Informasi, Universitas Kristen Satya
Wacana 2)Staf Pengajar Fakultas Teknologi Informasi, Universitas
Kristen Satya Wacana.
-
1
1. Pendahuluan
REST Web Service semakin popular digunakan sebagai media
pertukaran
data antara perangkat mobile dengan server [1]. Perangkat mobile
seperti ponsel
berbasis Android sampai bahkan tablet berbasis Windows
menggunakan paket
data internet yang berbayar atau WiFi untuk dapat mengakses
layanan dari server.
Semakin besar data yang ditransmisikan, semakin lama proses
untuk mengirim
dan menerima. Hal ini juga akan mengakibatkan jaringan menjadi
lebih sibuk, dan
juga banyaknya biaya pulsa yang dikeluarkan, jika paket data
internet digunakan.
REST Web Service berjalan pada protokol HTTP, yang berarti data
yang
dikirimkan berupa teks. Data yang dikirimkan dapat diperkecil
ukurannya tanpa
menghilangkan makna informasi di dalamnya, dengan menggunakan
algoritma
kompresi. Algoritma LZW [2] merupakan salah satu algoritma
kompresi yang
bersifat lossless. Lossless berarti antara isi data sebelum
kompresi dengan isi data
setelah dekompresi, tidak ada data yang hilang.
Pada penelitian ini diimplementasikan algoritma kompresi LZW
pada
REST Web Service. Tujuan dari implementasi ini adalah untuk
memperkecil
ukuran data yang ditransmisikan antara server dengan client.
Pada sisi server
maupun client terdapat proses kompresi dan dekompresi. Server
melakukan
kompresi data kemudian mengirimkan ke client, kemudian data
tersebut dilakukan
dekompresi untuk mendapatkan informasi sebenarnya. Proses ini
juga berlaku
ketika client mengirim data ke server.
2. Tinjauan Pustaka
Pada penelitian berjudul “Data Compression Techniques on Text
Files: A
Comparison Study”, dibahas mengenai perbandingan performa empat
algoritma
kompresi, yaitu LZW, Huffman, HFLC dan FLC. Pada penelitian
tersebut
disimpulkan bahwa LZW memberikan rasio hasil kompresi yang lebih
besar
daripada tiga algoritma yang lain, terutama pada file yang
berukuran besar [3].
Pada penelitian Muhammad dan Subandi [4] dibandingkan antara
kompresi Huffman dan LZW pada file dengan format video dan
audio. Indikator
perbandingan kompresi ini adalah waktu (kecepatan) kompresi,
ukuran file hasil
kompresi dan persentase pemampatan file setelah dilakukan
kompresi data.
Berdasarkan perbandingan yang telah dilakukan, didapat hasil
bahwa rata-rata
dari persentase pemampatan file audio adalah 98,6% (LZW) dan 99%
(Huffman).
Sedangkan rata-rata dari persentase pemampatan file video adalah
98,3% (LZW)
dan 99,46% (Huffman). Sedangkan kecepatan rata-rata untuk
kompresi file audio
adalah 55.03 Kb/detik (LZW) dan 1058,78 KB/detik (Huffman).
Sedangkan
kecepatan rata-rata untuk kompresi file video adalah 51.25
Kb/detik (LZW) dan
825,41 Kb/detik (Huffman). Sehingga dapat disimpulkan bahwa
metode LZW
lebih efektif digunakan dalam pengkompresian audio dan video
dibandingkan
dengan metode Huffman.
Penelitian tentang implementasi algoritma LZW salah satunya
dilakukan
oleh Hidayat, Zarman, dan Pamungkas [5]. Penelitian tersebut
membahas
mengenai implementasi LZW pada database server. Hal ini
dilakukan untuk
-
`2
memperkecil ukuran data yang akan disimpan di database server.
Algoritma LZW
yang dirancang menggunakan bahasa pemrograman PHP dan sistem
manajemen
basis data MySQL. Proses kompresi dilakukan pada saat data akan
disimpan ke
database dan didekompresi setiap data tersebut akan dibaca.
Hasil implementasi
algoritma LZW pada server yaitu penyimpanan artikel menjadi
bertambah
banyak, terlihat dari nilai persentase penghematan penyimpanan
setiap artikel
berkisar antara 11,67% sampai dengan 16,67% untuk perhitungan
nilai rata-rata
persentase penghematan 200 sampai dengan 1.000 karakter pertama
dari sepuluh
buah artikel acak.
Berdasarkan penelitian yang pernah dilakukan tentang
pemanfaatan
kompresi dan algoritma LZW, maka dalam penelitian ini dilakukan
penelitian
yang memanfaatkan kompresi dengan algoritma LZW pada transmisi
data antara
REST Web Service dengan perangkat mobile berbasis Android.
Perbedaan
penelitian ini dengan penelitian-penelitian sebelumnya adalah,
pada penelitian ini
kompresi diterapkan pada data teks yang pada umumnya dilewatkan
pada jalur
komunikasi REST Web Service. REST Web Service menggunakan
HTTP
(Hypertext Transfer Protocol) untuk berkomunikasi, dengan kata
lain data teks
yang dilewatkan pada jalur protokol tersebut. Data teks dapat
berupa file teks, atau
data string.
Algoritma LZW yang merupakan dictionary based compression
sangat
efektif mengkompresi data teks yang memiliki banyak pola huruf,
kata ataupun
kalimat yang berulang, semakin banyak pembendaharaan gabungan
string dalam
dictionary tambahan pada suatu plaintext maka semakin baik hasil
kompresi
plaintext tersebut [5]. LZW (Lempel-Ziv-Welch) merupakan
algoritma kompresi
lossless universal yang dibuat oleh Abraham Lempel, Jacob Ziv,
dan Terry
Welch. Kelebihan algoritma ini yaitu cepat dalam implementasi
dan
kekurangannya 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 dibandingkan string aslinya [6].
Konsep dari
algoritma LZW secara sederhana mengganti string dari karakter
dengan kode
tunggal dan tidak melakukan analisa apapun pada teks yang masuk.
Tetapi hanya
menambahkan setiap string dari karakter baru yang ditemuinya ke
tabel string
(dictionary). Kompresi terjadi ketika ditemui string berulang,
algoritma ini
menghasilkan kode tunggal dan menggantikan string-string
berulang yang
ditemui selama proses kompresi [2].
REST (Representational State Transfer) Web Service adalah
suatu
arsitektur perangkat lunak untuk pendistribusian sistem
hipermedia seperti
WWW. Secara spesifik, REST merujuk pada suatu prinsip arsitektur
jaringan
yang menggariskan pendefinisian dan pengalamatan sumber daya.
Istilah ini
sering digunakan untuk mendeskripsikan semua interface sederhana
yang
mengirimkan data melalui HTTP tanpa ada tambahan lapisan pesan
seperti SOAP.
Keuntungan lain dari antarmuka REST adalah request dan respon
dapat
-
`3
dipendekkan. Prinsip dasar desain REST adalah membuat pemetaan
one-to-one
antara operasi create, read, update, dan delete yang menggunakan
method sebagai
POST untuk membuat sebuah resource pada server. GET untuk
menerima sebuah
resource. PUT untuk proses update state dari resource. DELETE
untuk
menghapus resource. Dalam konsep arsitektur REST web service,
membuat
panggilan ke suatu HTTP API secara signifikan lebih mudah
daripada ke SOAP
API, karena membutuhkan library client, membutuhkan pengenalan,
dan
kebiasaan. Sedangkan HTTP API adalah asli dari semua bahasa
pemrograman dan
hanya melibatkan HTTP request dengan parameter sesuai yang
ditambahkan,
sehingga lebih memudahkan dalam melakukan proses pemanggilan.
HTTP API
mudah untuk testing dan troubleshoot, karena dapat membangun
panggilan
dengan tidak lebih dari sekedar browsing dan memeriksa respon
dalam jendela
browser itu sendiri. Karena berbasis HTTP/RESTful, API dapat
dikonsumsi
menggunakan request GET sederhana, dan server
proxy/reverse-proxy dapat
melakukan cache atas respon tersebut dengan mudah. Untuk
mengakses RESTful
web service digunakan sebuah URI (Uniform Resource Identifiers)
yang
merupakan nama dan alamat dari sebuah resource. RESTful web
service tidak
menggunakan WSDL. Pesan yang dikirim, dikemas dalam format XML
dan
JSON. Berbeda dengan SOAP web service yang menggunakan protokol
khusus
untuk pengiriman pesan [7][8].
3. Metode dan Perancangan Sistem
Penelitian yang dilakukan, diselesaikan melalui tahapan
penelitian yang
terbagi dalam empat tahapan, yaitu: (1) Identifikasi masalah dan
studi literatur, (2)
Perancangan sistem, (3) Implementasi sistem yaitu perancangan
aplikasi/program,
dan (4) Pengujian sistem serta analisis hasil pengujian.
Identifikasi Masalah dan Studi Literatur
Perancangan Sistem
Implementasi Sistem
Pengujian Sistem dan Analisis Hasil Pengujian
Gambar 1 Tahapan Penelitian
Tahapan penelitian pada Gambar 1, dapat dijelaskan sebagai
berikut.
Tahap pertama: identifikasi masalah, yaitu masalah penghematan
data yang
ditransmisikan antara REST Web Server dengan client yang berupa
perangkat
mobile. Studi literatur dilakukan untuk mencari metode
penghematan data yang
-
`4
dapat diterapkan, serta penelitian-penelitian terdahulu yang
dapat digunakan
sebagai acuan. Tahap kedua: perancangan sistem yang meliputi
perancangan
proses kompresi dan proses dekompresi. Perancangan kedua proses
tersebut juga
dilakukan pada sisi client. Algoritma kompresi yang digunakan
adalah LZW.
Tahap ketiga: implementasi sistem, yaitu membuat aplikasi sesuai
perancangan
proses pada tahap kedua. Sistem yang dibuat terdiri dari dua
aplikasi, yaitu server
dan client. Aplikasi yang dikembangkan bertujuan untuk
mensimulasikan hasil
kompresi yang dikirim dan diterima oleh kedua sisi. Tahap
keempat: pengujian
sistem dan analisis hasil pengujian, yaitu dilakukan pengujian
terhadap proses
yang telah dirancang. Pengujian memiliki tujuan utama yaitu
melihat keuntungan
dan kerugian dengan adanya implementasi kompresi pada komunikasi
REST Web
Service dengan client.
Gambar 2 Desain Sistem Komunikasi dari
Client ke Server [1]
Gambar 3 Desain Sistem Komunikasi dari
Server ke Client [1]
Proses kompresi dan dekompresi dengan algoritma LZW (Lempel
Ziv
Welch), dapat dijelaskan sebagai berikut, proses kompresi data
secara sederhana
mengganti string dari karakter dengan kode tunggal dan tidak
melakukan analisa
apapun pada teks yang masuk. Tetapi hanya menambahkan setiap
string dari
karakter baru yang ditemuinya ke tabel string (dictionary).
-
`5
Gambar 4 Proses Algoritma Kompresi
LZW [6] Gambar 5 Proses Algoritma Dekompresi
LZW [6]
Kompresi terjadi ketika ditemui string berulang, algoritma ini
menghasilkan
kode tunggal dan menggantikan string-string berulang yang
ditemui selama
proses kompresi. Panjang kode yang dihasilkan algoritma LZW
dapat berubah-
ubah, tetapi jumlah bit yang dimiliki kode tersebut harus lebih
banyak dari pada
sebuah karakter tunggal. Proses dekompresi pada LZW dilakukan
dengan prinsip
yang sama seperti proses kompresi. Proses kompresi dan
dekompresi dengan
algoritma LZW, dalam bentuk flowchart, ditunjukkan pada Gambar 4
dan Gambar
5.
Contoh proses kompresi dijelaskan dengan menggunakan pesan.
BABAABAAA. Pesan tersebut memiliki ukuran 9 byte (9 x 8 bit = 72
bit), satu
karakter ASCII berukuran 1 byte. Tabel 1 Contoh Proses
Kompresi
S C S+C
S+C
ada di
kamus?
output S tambah S+C ke
kamus
nilai S
selanjutnya
S Kode S+C Kode rumus nilai S
-
`6
B A BA tidak B 66 BA 256 S=C A
A B AB tidak A 65 AB 257 S=C B
B A BA ya
S=S+C BA
BA A BAA tidak BA 256 BAA 258 S=C A
A B AB ya
S=S+C AB
AB A ABA tidak AB 257 ABA 259 S=C A
A A AA tidak A 65 AA 260 S=C A
A A AA ya
S=S+C AA
A adalah karakter terakhir 260
66 65 256 257 65 260
Hasil kompresi adalah 66, 65, 256, 257, 65, 269, dengan ukuran 6
x 8 = 48
bit. Karena jumlah isi kamus lebih dari 256 (0 s/d 255), maka
nilai binary untuk
tiap kode dinaikkan dari 8 bit, menjadi 9 bit, sehingga dapat
mengakomodasi nilai
bilangan lebih dari 255. Sehingga hasilnya berukuran 54 bit.
66 65 256 257 65 260
001000010 001000001 100000000 100000001 001000001 100000100
4. Hasil dan Pembahasan
Pada penelitian ini dikembangkan aplikasi yang digunakan
sebagai
pengujian penggunaan kompresi LZW. Aplikasi dikembangkan dalam
bentuk
aplikasi mobile Android.
Gambar 6 Tampilan Download Data 18 KB
Gambar 7 Tampilan Download Data 99 KB
-
`7
Pada Gambar 6 dan Gambar 7 ditunjukkan tampilan pada aplikasi
Android
yang digunakan untuk menguji proses download file terkompresi.
Gambar 6
digunakan file teks berukuran 18 KB, dan Gambar 7 digunakan file
teks 99 KB.
File yang diunduh oleh aplikasi adalah file terkompresi, ukuran
ini ditunjukkan
pada kolom “Ukuran Download”. Lama waktu proses download
ditunjukkan pada
kolom “Waktu Download”. Setelah diterima, dilakukan proses
dekompresi.
Waktu proses dekompresi ditampilkan pada kolom “Waktu
Dekompresi”, dan
ukuran file setelah dekompresi ditampilkan pada kolom “Ukuran
Dekompresi”.
Pengujian dilakukan untuk mengukur waktu proses kompresi,
waktu
proses dekompresi, rasio hasil kompresi, waktu kirim, dan
integritas data.
Pengujian yang pertama adalah pengujian waktu proses.
Tabel 2 Hasil Pengujian Kompresi di Server
No Nama
File Text
Ukuran
Asli/Normal
(KB)
Ukuran setelah
kompresi
(KB)
Rasio
Lama Waktu
Kompresi
(detik)
Lama Waktu
Dekompresi (detik)
1 File1.txt 18 4 22% 0,60003 0,58091
2 File2.txt 26 5 19% 0,70004 0,67014
3 File3.txt 35 6 17% 0,80005 0,70020
4 File4.txt 70 9 13% 2,00012 0,14002
5 File5.txt 99 11 11% 2,90017 0,20050
Tabel 3 Hasil Pengujian Kompresi di Aplikasi Android
No Nama
File Text
Ukuran
Asli/Normal
(KB)
Ukuran setelah
kompresi
(KB)
Rasio
Lama Waktu
Kompresi
(detik)
Lama Waktu
Dekompresi (detik)
1 File1.txt 18 4 22% 4.35003 4.98091
2 File2.txt 26 5 19% 2.10004 4.12014
3 File3.txt 35 6 17% 2.60005 3.7502
4 File4.txt 70 9 13% 4.85012 3.14002
5 File5.txt 99 11 11% 5.20017 3.2505
Waktu proses kompresi dan dekompresi di Aplikasi Android
memakan
waktu lebih lama dari pada di server. Hal ini karena kemampuan
komputasi
perangkat mobile lebih kecil daripada computer server.
Pengujian integritas data dilakukan untuk membuktikan bahwa
tidak ada
informasi yang rusak akibat proses kompresi dan dekompresi.
Hasil pengujian ini
ditunjukkan pada Tabel 4.
Tabel 4 Pengujian Keutuhan File
Nama File Ukuran Nornal
Data
Sesudah
Kompresi
Sesudah
Dekompresi
Perbandingan Checksum
(MD5)
File1.txt 18 KB 4 KB 18 KB Sama
File2.txt 26 KB 5 KB 26 KB Sama
File3.txt 35 KB 6 KB 35 KB Sama
File4.txt 70 KB 9 KB 70 KB Sama
File5.txt 99 KB 11 KB 99 KB Sama
Berdasarkan hasil pengujian pada Tabel 4, ukuran file yang
telah
dikompresi tidak mengalami perubahan ukuran. Algoritma LZW
menggunakan
teknik kompresi lossless yang menjamin bahwa berkas yang
dikompresi dapat
selalu dikembalikan ke bentuk aslinya
-
`8
Pengujian terakhir adalah total waktu antara pengiriman data
dari server
ke aplikasi Android dan sebaliknya. Hasil pengujian ditunjukkan
pada Tabel 5 dan
Tabel 6. Memory pada Android emulator di pengujian ini dibatasi
sampai dengan
256 MB. Jika digunakan data lebih dari kapasitas memory, maka
aplikasi menjadi
error dan ditutup secara paksa (terminate) oleh sistem operasi
Android.
Tabel 5 Waktu Kirim File dengan Kompresi dari Server ke
Android
Ukuran
Asli/Normal
(MB)
Ukuran
setelah kompresi
(MB)
Kompresi (detik) Terjadi di Server
Waktu
Kirim
Dekompresi
(detik) Terjadi di
Android(MB)
Total (detik)
16 3 4.54 1.34 26.95 32.83
32 6 6.71 2.68 35.12 44.51
64 18 7.82 8.04 40.23 56.09
128 34 8.01 15.19 52.42 75.62
256 100 9.01 44.67 61.42 115.10
Tabel 6 Waktu Kirim File tanpa Kompresi dari Server ke
Android
Ukuran
Asli/Normal(MB)
(tidak
ada
kompresi) (MB)
Kompresi (detik)
Terjadi di Server
(tidak ada kompresi)
Waktu Kirim
(tidak ada
dekompresi) Total (detik)
16 16 0 7.15 0 7.15
32 32 0 15.29 0 15.29
64 64 0 27.59 0 27.59
128 128 0 59.17 0 59.17
256 256 0 115.35 0 115.35
Berdasarkan Tabel 5 dan Tabel 6, lama waktu pengiriman data
yang
terkompresi lebih cepat daripada waktu kirim data tanpa
kompresi. Ada
kelemahan dari penggunaan kompresi, yaitu adanya tambahan waktu
kompresi
dan dekompresi yang terjadi di Server dan di Android. Sehingga
pada akhirnya
total waktu yang tercepat adalah waktu tanpa kompresi.
0,00
20,00
40,00
60,00
80,00
100,00
120,00
140,00
16 32 64 128 256
WA
KTU
(D
ETIK
)
UKURAN DATA (MB)
Perbandingan Waktu PengirimanDengan Kompresi Tanpa Kompresi
-
`9
Gambar 8 Grafik Perbandingan Waktu Pengiriman dari Server ke
Android
Gambar 9 Grafik Perbandingan Waktu Total dari Server ke
Android
Berdasarkan Gambar 8 dilihat bahwa dengan kompresi dapat
memberikan
penghematan dalam hal kecepatan pengiriman data. Jika komponen
waktu
komputasi (proses kompresi dan dekompresi), ditambahkan pada
waktu kirim
(Gambar 9), maka secara total, proses kirim tanpa kompresi lebih
cepat daripada
dengan kompresi.
Tabel 7 Waktu Kirim File dengan Kompresi dari Android ke
Server
Ukuran
Asli/Normal
(MB)
Ukuran
setelah kompresi
(MB)
Kompresi (detik) Terjadi di Android
Waktu
Kirim
Dekompresi (detik)
Terjadi di
Server (MB)
Total (detik)
16 3 26.91 1.36 4.60 32.95
32 6 35.45 2.77 7.11 44.12
64 18 41.56 8.54 7.99 52.20
128 34 53.33 15.98 8.20 63.93
256 100 62.12 44.89 9.04 74.08
Tabel 8 Waktu Kirim File tanpa Kompresi dari Android ke
Server
Ukuran Asli/Normal
(MB)
(tidak ada kompresi)
(MB)
Kompresi (detik) Terjadi di Android
(tidak ada kompresi)
Waktu Kirim
(tidak ada
dekompresi) Total (detik)
16 16 0 7.15 0 7.15
32 32 0 15.77 0 15.77
64 64 0 28.90 0 28.90
128 128 0 63.66 0 63.66
256 256 0 116.02 0 116.02
0,00
20,00
40,00
60,00
80,00
100,00
120,00
140,00
16 32 64 128 256
WA
KTU
(D
ETIK
)
UKURAN DATA (MB)
Perbandingan Total WaktuDengan Kompresi Tanpa Kompresi
-
`10
Seperti halnya pada proses dari Server ke Android, pada Tabel 7
dan Tabel
8, secara keseluruhan, waktu pengiriman dengan kompresi menjadi
lebih lama
karena ada tambahan waktu proses. Perbandingan waktu kirim dan
waktu total
ditunjukkan pada Gambar 10 dan Gambar 11.
Gambar 10 Grafik Perbandingan Waktu Pengiriman dari Android ke
Server
Gambar 11 Grafik Perbandingan Waktu Total dari Android ke
Server
Hal ini bukan berarti kompresi tidak memberikan keuntungan
apapun.
Keuntungan yang jelas tampak adalah berkurangnya ukuran file
yang dikirimkan.
Hal ini menjadikan paket yang dikirimkan lewat jaringan komputer
LAN maupun
internet menjadi lebih kecil. Sehingga lebih dapat menghemat
biaya pulsa internet
jika diakses menggunakan koneksi mobile network. Waktu untuk
komputasi
(kompresi/dekrompresi) dipengaruhi oleh memory dan kecepatan
prosesor pada
0,00
20,00
40,00
60,00
80,00
100,00
120,00
140,00
16 32 64 128 256
WA
KTU
(D
ETIK
)
UKURAN DATA (MB)
Perbandingan Waktu PengirimanDengan Kompresi Tanpa Kompresi
0,00
50,00
100,00
150,00
200,00
16 32 64 128 256
WA
KTU
(D
ETIK
)
UKURAN DATA (MB)
Perbandingan Total WaktuDengan Kompresi Tanpa Kompresi
-
`11
server dan Android. Sehingga semakin tinggi spesifikasi
perangkat keras, maka
waktu untuk komputasi ini akan semakin terpangkas.
Tabel 9 Tambahan Waktu Kompresi/Dekompresi
Server ke Android Android ke Server
Ukuran
File
Dengan
Kompresi
Tanpa
Kompresi
Tambahan
waktu
Dengan
Kompresi
Tanpa
Kompresi
Tambahan
waktu
16 32.83 7.15 359.41% 32.87 7.15 359.72%
32 44.51 15.29 191.06% 45.33 15.77 187.44%
64 56.09 27.59 103.33% 58.09 28.90 101.00%
128 75.62 59.17 27.79% 77.51 63.66 21.76%
256 126.10 115.35 9.32% 175.49 116.02 51.26%
Pada Tabel 9 dapat dilihat bahwa persentase tambahan waktu
(bukan total
waktu) berbanding terbalik dengan ukuran file. Semakin besar
file, maka semakin
kecil persentase tambahan waktu.
5. Simpulan
Berdasarkan hasil penelitian dan pengujian yang telah dilakukan,
dapat
disimpulkan sebagai berikut: (1) Kompresi LZW dapat dimanfaatkan
untuk
mengkompresi file-file atau data yang ditransmisikan antara
server dengan
perangkat mobile; (2) Waktu proses kompresi dan dekompresi akan
menambah
total waktu yang berbanding terbalik dengan ukuran file yang
ditransmisikan.
Namun lama waktu proses ini dipengaruhi oleh hardware server
maupun
perangkat mobile. Semakin kuat kemampuan hardware, maka akan
semakin
terpangkas waktu proses kompresi dan dekompresi; (3) Keuntungan
yang jelas
tampak adalah penghematan biaya paket data karena data yang
diunduh maupun
diunggah menjadi lebih kecil. Saran yang dapat diberikan untuk
penelitian lebih
lanjut adalah: (1) Perlu dilakukan analisis perbandingan
pengiriman data dari
berbagai jenis jaringan, seperti LAN, WAN, maupun Internet; (2)
Perlu dianalisis
pengaruh kompresi pada berbagai jenis tipe data, seperti gambar,
audio, dan
video.
6. Daftar Pustaka
[1]. Rodriguez, A., 2015. RESTful Web services: The basics.
http://www.ibm.com/developerworks/library/ws-restful/. Diakses
10 Mei
2016.
[2]. Nelson, M., 1989. LZW Data Compression. Dr Dobbs J Software
Tools 14,
29–37. (doi:10.1146/annurev-genet-102108-134255)
[3]. Altarawneh, H., & Altarawneh, M., 2011. Data
Compression Techniques
on Text Files: A Comparison Study. International Journal of
Computer
Applications 26, 975–8887.
[4]. 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. STMIK GI MDP
-
`12
[5]. Hidayat, H., Pamungkas, T., & Zarman, W., 2015.
Implementasi Algoritma
Kompresi LZW pada Database Server. Jurnal Komputer dan
Informatika 2.
[6]. Linawati, H. P. P., 2004. Perbandingan Kinerja Algoritma
Kompressi
Huffman, LZW dan DMC pada Berbagai Tipe File. Universitas
Katholik
Parahyangan Bandung
[7]. Hamad, H., Saad, M., & Abed, R., 2010. Performance
Evaluation of
RESTful Web Services for Mobile Devices. Int. Arab J. e-Technol.
1, 72–78.
[8]. Wagh, K., & Thool, R., 2012. A comparative study of
soap vs rest web
services provisioning techniques for mobile host. Journal of
Information
Engineering and Applications 2, 12–16.