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) ardymeland@gmail.com, 2) inekep200472@yahoo.com

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.