BAB III ANALISA Pada bab ini akan dilakukan analisa terhadap bagaimana infrastruktur teknologi informasi dapat mendukung aktivitas riset di lingkungan ITB, dan bagaimana penerapan cooperative web cache pada jaringan ITB. Gambar III-1 menunjukkan skema analisa yang akan dilakukan.
Perencanaan Penentuan lingkup dan tujuan analisis
Identifikasi Kebutuhan ITB menuju Universitas Riset
Identifikasi penerapan cooperative web cache saat ini
Analisis & Evaluasi
Identifikasi web cache ITB
Analisis model cooperative web cache ITB
Identifikasi hirarki web cache ITB
Evaluasi Kinerja cooperative web cache ITB
Identifikasi model web cache ITB
Identifikasi model cooperative web cache ITB
Kesimpulan Analisis dan Evaluasi Kinerja cooperative web cache ITB, terkait dengan universitas riset Saran Perbaikan Model cooperatve web cache
Gambar III-1. Skema analisa
III.1 Lingkup dan Tujuan Analisa Analisa yang dilakukan bertujuan untuk : a. Mengidentifikasi kebutuhan ITB menuju universitas riset. b. Mengidentifikasi model cooperative web cache yang saat ini diterapkan di ITB. c. Melakukan analisa atas model cooperative web cache tersebut. d. Menghitung kinerja penerapan model cooperative web cache tersebut.
24
e. Membentuk kesimpulan atas analisa dan evaluasi yang telah dilakukan, dikaitkan dengan visi ITB menuju universitas riset. f. Memberikan saran perbaikan model yang dapat dilakukan untuk mendukung visi ITB menuju universitas riset. Lingkup analisa dilakukan berdasarkan data dan fakta yang terjadi di ITB, yaitu: a. Fakta kebutuhan ITB menuju universitas riset. b. Fakta penerapan cooperative web cache di ITB.
III.2 Identifikasi Kebutuhan Universitas Riset III.2.1 Strategi Bisnis Dalam konsep strategi organisasi pada bab II.7, visi ITB menuju universitas riset dapat dinyatakan sebagai strategi bisnis ITB. Terkait dengan infrastruktur teknologi, ITB mendefinisikan universitas riset yang memiliki karakteristik yaitu memiliki fasilitas riset yang memadai mencakup infrastruktur teknologi informasi dan komunikasi, serta pemeliharaannya. Strategi bisnis ini dapat diuraikan sebagai berikut: a. Posisi saat ini: Kapasitas teknologi informasi belum memadai, dengan indikator jumlah bandwith per mahasiswa adalah 0,47 Kbps/mahasiswa. (Institut Teknologi Bandung, 2005). b. Posisi yang diinginkan: Tersedianya fasilitas teknologi informasi dan komunikasi dengan indikator capaian jumlah bandwith per mahasiswa adalah 10.00 Kbps/mahasiswa(Institut Teknologi Bandung, 2005). c. Cara mencapai: ITB perlu mengadakan sarana teknologi informasi yang baru, atau memaksimalkan penggunaan sarana yang ada, untuk mendukung kegiatan riset dan pendidikan(Institut Teknologi Bandung, 2005). III.2.2 Strategi Sistem Informasi Strategi sistem informasi menyatakan informasi dan sistem yang dibutuhkan untuk mendukung strategi bisnis secara keseluruhan. Hasil dari strategi sistem
25
informasi menyatakan value yang diperoleh perusahaan atas informasi dan sistem yang dikelola. Strategi sistem informasi harus menyatakan informasi dan sistem yang dibutuhkan agar fasilitas teknologi informasi dan komunikasi mencapai indikator yang ditentukan yaitu jumlah bandwith per mahasiswa. Untuk itu, perlu dilakukan analisa fungsi kegunaan bandwith bagi mahasiswa terkait dengan aktivitas penelitian. Setelah diketahui fungsinya, maka perlu dilakukan identifikasi informasi dan sistem apa saja yang diperlukan untuk mengelola bandwith. Pada penelitian ini, strategi sistem informasi dibatasi pada dukungan terhadap strategi bisnis untuk memaksimalkan penggunaan sarana yang ada. III.2.2.1 Fungsi Akses Internet bagi Universitas Riset Salah satu karakteristik universitas riset menurut (The Boyer Commission on Educating Undergraduates in the Research University, 1998) yang tercantum pada bab II.6.1 adalah memiliki lingkungan penelitian yang mendukung yang salah satunya adalah akses internet. Akses internet memungkinkan peneliti meraih berbagai kesempatan penelitian yang ditawarkan. Internet bagi penelitian dapat berfungsi sebagai: a. Tempat untuk mencari, mengunduh, dan berbagi pengetahuan dan materi pembelajaran. b. Tempat untuk mempublikasikan dan
menyimpan progres dan hasil
penelitian. c. Fasilitator
hubungan
dan
kolaborasi
antar
peneliti
sehingga
memungkinkan untuk melakukan diskusi maupun ceramah ilmiah yang membahas permasalahan bersama. Namun, selain dari manfaat tersebut, koneksi internet juga mendukung beberapa aplikasi maupun tingkah laku yang menghabiskan bandwith, seperti: a. Memungkinkan tersebarnya spam dan virus.
26
b. Memungkinkan teraksesnya situs-situs yang mendukung hobi yang terkait dengan hiburan, misalnya musik. c. Memungkinkan teraksesnya situs poronografi. d. Memungkinkan
hacker
untuk
melatih
kemampuannya
dengan
menggunakan fasilitas internet yang ada. e. Memungkinkan software, agent, dan worms untuk melakukan proses indexing atas proses dan konten yang ada pada sebuah komputer. Seluruh tindakan tersebut dapat dikatakan sebagai penyalahgunaan akses internet. Penyalahgunaan akses internet tersebut telah menghabiskan sebagian dari bandwith yang tersedia di ITB. Akibatnya, response time akan menurun yang dapat menyebabkan proses penelitian menjadi terhambat. III.2.2.2 Identifikasi Informasi untuk Pengelolaan Bandwith Untuk memaksimalkan penggunaan sarana yang ada, informasi yang dibutuhkan untuk pengelolaan bandwith adalah: a. Informasi kebutuhan bandwith per pengguna. b. Informasi bandwith yang dapat disediakan oleh ITB. c. Informasi penggunaan bandwith yang sedang berjalan. d. Informasi kebijakan penggunaan bandwith bagi pengguna. III.2.2.3 Identifikasi Sistem untuk Pengelolaan Bandwith Untuk memaksimalkan penggunaan sarana yang ada, sistem yang dibutuhkan untuk pengelolaan bandwith a. Sistem akses internet yang memungkinkan pengguna dapat mengakses internet dengan aman, nyaman, dan terkontrol.
27
b. Sistem monitoring penggunaan bandwith per pengguna. c. Sistem monitoring penggunaan bandwith secara umum terkait dengan total bandwith yang dapat disediakan oleh ITB. III.2.3 Strategi Teknologi Informasi Strategi teknologi informasi menyatakan bagaimana kebutuhan organisasi akan informasi dan sistem dapat didukung oleh teknologi informasi. Strategi teknologi menyediakan infrastruktur dan layanan yang dibutuhkan oleh strategi sistem informasi. Artinya strategi teknologi informasi menyatakan biaya yang harus dikeluarkan oleh organisasi untuk memperoleh value yang dihasilkan dari strategi sistem informasi. Strategi teknologi informasi dapat berupa hardware, software, telekomunikasi, dan layanan, seperti operasi IT, pengembangan sistem, dan dukungan pengguna. Strategi teknologi informasi yang akan dibicarakan dalam penelitian ini adalah yang terkait dengan pengembangan sistem. Karena strategi teknologi informasi menyatakan biaya, maka strategi teknologi informasi harus difokuskan pada penyediaan infrastruktur dan layanan yang mengoptimalkan biaya. Untuk dapat memaksimalkan penggunaan sarana yang ada sehingga indikator bandwith per mahasiswa dapat dicapai, maka strategi teknologi informasi harus ditujukan pada penghematan penggunaan bandwith tanpa mengurangi nilai manfaat atas akses internet bagi universitas riset. Strategi teknologi informasi yang diusulkan pada penelitian ini adalah penerapan cooperative web cache. Web cache menyimpan salinan objek yang baru saja diakses maupun objek yang sering diakses. Selain itu, web cache juga dapat menyimpan log aktivitas situssitus yang sering dikunjungi, sehingga memungkinkan pengelola jaringan internet untuk mengetahui penggunaan internet dan jumlah konsumsi bandwith untuk setiap pengguna, dan dapat melakukan tindakan atas penyalahgunaan akses internet.
28
Web cache dapat menghemat penggunaan bandwith karena beberapa objek yang sering diakses telah tersimpan di dalam cache, atau karena bandwith yang tersedia untuk kepentingan penelitian menjadi lebih besar karena adanya proses web caching. Keuntungan web cache dapat ditingkatkan dengan melakukan penerapan cooperative web cache. Cooperative web cache memanfaatkan objek dari sibling web cache untuk memenuhi permintaan objek yang tidak dapat dipenuhi oleh web cache. Karena asumsi bahwa sibling web cache letaknya lebih dekat daripada web server aslinya, maka trafik internet dapat diturunkan dan responses times juga dapat ditingkatkan. Terkait dengan strategi sistem informasi yang telah ditetapkan sebelumnya, cooperative web cache dapat memberikan dukungan berupa: a. Informasi penggunaan bandwith per pengguna, khusus untuk penggunaan akses internet via protokol HTTP. Web cache memungkinkan pencatatan akses internet via protokol HTTP per pengguna. Sehingga hasil pencatatan tersebut dapat memberikan informasi penggunaan bandwith per pengguna. b. Sistem akses internet yang memungkinkan pengguna dapat mengakses internet dengan aman, nyaman, dan terkontrol. Web
cache
dapat
memfasilitasi
metode
akses
internet
dengan
mensyaratkan penggunaan username dan password sehingga proses pengaksesan internet dapat dilakukan secara aman. Selain itu web cache memungkinkan terjadinya content filtering terhadap situs-situs web yang tidak sesuai dengan kebijakan ITB, sehingga pengaksesan internet dapat dilakukan secara nyaman dan terkontrol. d. Sistem monitoring penggunaan bandwith per pengguna. Web cache mencatat penggunaan bandwith per pengguna secara realtime sehingga sistem monitoring penggunaan bandwith dapat dilakukan.
29
e. Sistem monitoring penggunaan bandwith secara umum terkait dengan total bandwith yang dapat disediakan oleh ITB. Web cache mencatat penggunaan bandwith secara realtime sehingga sistem monitoring penggunaan bandwith total khusus untuk protokol HTTP dapat dilakukan.
III.3 Identifikasi Penerapan Cooperative Web Cache ITB Saat Ini Cooperative web cache terdiri atas beberapa web cache yang terhubung secara logis dan saling berbagi akses terhadap objek yang dimiliki oleh masing-masing web cache. Untuk mengidentifikasi cooperative web cache, maka perlu diidentifikasi terlebih dahulu bagaimana penerapan web cache di ITB. Sehingga identifikas terhadap penerapan cooperative web cache dapat didasarkan pada penerapan web cache. Cooperative didefinisikan sebagai paradigma yang memanfaatkan komunikasi untuk membuat node bekerja sama. Proses komunikasi dilakukan secara terdistribusi untuk memperoleh keuntungan bersama (Liu dkk., 2009). Artinya di setiap lingkungan kooperatif terdapat beberapa aktor yang saling berkomunikasi untuk mencapai sebuah tujuan bersama. Setiap aktor yang terlibat dalam lingkungan kooperatif pasti memiliki peran dan tanggung jawab. Menurut (Cabitza dkk., 2009), pada proses cooperative, dibutuhkan artifak yang dapat digunakan oleh aktor yang kompeten/koordinator untuk mengetahui apa yang telah dan apa yang sedang terjadi dalam proses cooperative. Selain itu artifak tersebut juga dapat digunakan untuk melihat konteks cooperative terkait dengan tujuan dan ekspektasi bersama. Artifak tersebut adalah templates, maps, dan scripts. Oleh karena itu, identifikasi penerapan cooperative web cache di ITB akan dilakukan dengan mempertimbangkan lingkup sebagai berikut: a. Aktor yang terlibat dalam cooperative web cache. 30
b. Fungsi web cache. c. Trafik komunikasi yang dibutuhkan untuk melakukan proses cooperative untuk menentukan biaya komunikasi. d. Artifak untuk melakukan proses cooperative. III.3.1 Web Cache ITB ITB memiliki empat buah web cache yaitu cache1.itb.ac.id, cache2.itb.ac.id, cache3.itb.ac.id, dan cache4.itb.ac.id. Masing-masing web cache dapat melayani penggunanya langsung. Cache1 dan cache2 melayani pengguna yang berada di kampus ITB yang menggunakan koneksi dengan protokol IPv4. Cache4 melayani seluruh pengguna menggunakan koneksi dengan protokol IPv6. Sedangkan cache3 melayani pengguna yang berada di kantor rektorat yang menggunakan koneksi dengan protokol IPv4. III.3.2 Hirarki Web Cache ITB Berdasarkan dokumen konfigurasi web cache ITB, maka hirarki web cache ITB dapat digambarkan seperti pada gambar III-2. Child akan meneruskan request yang berstatus cache miss kepada parent-nya. Parent kemudian akan memberikan respon baik dari cache-nya sendiri, web server aslinya, maupun dari web cache yang lain. Karena parent dapat memberikan respon yang berasal dari web cache yang lain, maka penetapan parent harus mempertimbangkan delay yang mungkin terjadi pada kondisi terburuk. Kondisi terburuk tersebut dicapai jika request selalu menghasilkan cache miss, sehingga request harus diteruskan ke seluruh hirarki web cache sampai objek yang diinginkan diperoleh dari web server aslinya. Delay pada kondisi terburuk harus dijaga nilainya agar lebih kecil dari delay yang dihasilkan jika objek langsung diambil di web server aslinya. Request yang dikirimkan ke sibling harus menghasilkan cache hit. Jika tidak memiliki objek yang diminta, sibling tidak akan meneruskan request tersebut ke parent-nya. Sehingga, kemungkinan terjadinya forwarding loop atas sebuah request dapat dihindari. Tabel III-1 menyatakan hubungan child-sibling-parent dari web cache yang ada di ITB.
31
Tabel III-1. Hirarki web cache ITB Web Cache
Sibling
Parent
(Child) Cache1
Cache2, Cache3, Cache4, 202.51.232.226,
Sfc-cache,
202.51.232.227, 202.51.224.5, 152.118.24.10,
UC.ircache.net,
152.118.148.218
SD.ircache.net, RTP.ircache.net
Cache2
Cache3
Cache1, Cache3, Cache4, 202.51.232.226,
UC.ircache.net,
202.51.232.227, 202.51.224.5, 152.118.24.10,
SD.ircache.net,
152.118.148.218
RTP.ircache.net
Cache2, Cache3, Cache4, 202.51.232.226,
Sfc-cache,
202.51.232.227, 202.51.224.5, 152.118.24.10,
UC.ircache.net,
152.118.148.218
SD.ircache.net, RTP.ircache.net
Cache4
Cache2, Cache3, Cache4, 167.205.22.103,
Sfc-cache,
202.51.232.226, 202.51.232.227, 202.51.224.5,
UC.ircache.net,
152.118.24.10, 152.118.148.218
SD.ircache.net, RTP.ircache.net
32
Web Server Original
Web Server
Parent Child User
Sfc-cache 202.249.25.26
Uc.ircache.net 141.142.30.135
SD.ircache.net 192.172.226.121
RTP.ircache.net
128.109.131.47
2001:d30:101:1::5
Sibling Cache 1
Cache 2
Cache 3
167.205.22.104
167.205.22.105
167.205.23.15
Cache 4
Cache
202.51.232.226
202.51.232.227
202.51.224.5
152.118.24.10
152.118.148.218
167.205.22.103
167.205.23.5
Cache ITB
Cache Jawalave
Gambar III-2. Hirarki web cache ITB
33
Cache UI
III.3.3 Model Web Cache Untuk mempermudah pemahaman terhadap web cache di ITB, maka dibentuklah model web cache ITB. Implementasi web cache di ITB menggunakan Squid. Untuk menggambarkan model web cache, maka dilakukan studi terhadap aplikasi Squid. Studi dilakukan dengan mengidentifikasi aktor dan peran yang terlibat, serta siklus hidup web cache yang digambarkan dalam sequence diagram. Berdasarkan hasil identifikasi tersebut, maka dibuatlah model diagram. Metode ini terangkum dalam gambar III-3.
Gambar III-3. Pembentukan model III.3.3.1 Aktor dan Peran Berdasarkan penjelasan pada bab 2.5, dinyatakan bahwa Squid memiliki dua fungsi utama yaitu sebagai proxy dan sebagai cache. Proxy akan menerima request dari client, memproses request dan meneruskannya ke web server aslinya jika cache tidak memiliki objek yang diminta. Tabel III-2 menjelaskan aktor dan peran yang terlibat dalam web cache ITB.
34
Tabel III-2. Aktor dan peran dalam web cache Aktor
Peran
Client
-
Mengirimkan request HTTP
-
Menerima response kembali dari proxy.
-
Menerima request HTTP dari client.
-
Memproses request ke cache jika cache memiliki objek yang
Proxy
diminta -
Meneruskan ke web server aslinya jika cache tidak memiliki objek yang diminta
Cache
-
Menerima request HTTP dari proxy.
-
Mengirimkan response kembali ke proxy.
-
Menyimpan objek web yang merupakan respon dari web server.
Web Server -
Menerima request HTTP dari client (proxy) Mengirimkan response kembali ke client (proxy).
III.3.3.2 Siklus hidup Gambar III-4 berikut menunjukkan Sequence diagram dari siklus hidup web cache. Siklus hidup menyatakan proses yang dilakukan oleh web cache dalam menerima request dari client, sampai client menerima response atas permintaannya tersebut. Response dapat berupa objek yang diinginkan maupun pesan error atas request yang diberikan.
35
Ada dua buah skenario yang tertera dalam gambar III-4, yaitu: 1. Cache HIT, dicapai jika cache memiliki objek yang diinginkan client. 2. Cache MISS, dicapai jika cache tidak memiliki objek yang diinginkan client, sehingga objek harus diambil langsung dari web server.
Gambar III-4. Siklus hidup web cache III.3.3.3 Model Web Cache ITB Berdasarkan bab 3.2.3.1 dan bab 3.2.3.2 dibentuklah sebuah model web cache ITB yang dapat dilihat pada gambar III-5. Skenario Cache HIT dicapai melalui jalur 1-2-3-8. Sedangkan skenario cache MISS dicapai melalui jalur 1-2-4-6-7-8-5 jika objek ingin disimpan dalam cache atau melalui jalur 1-2-4-6-7-8 jika objek tidak perlu disimpan dalam cache.
36
Gambar III-5. Model web cache ITB saat ini. III.3.4 Model Cooperative Web Cache Metode yang digunakan untuk memperoleh gambaran mengenai model cooperative web cache ITB dilakukan seperti pada gambar III-3. III.3.4.1 Aktor dan Peran Tabel III-3 menyatakan aktor dan peran yang terlibat pada cooperative web cache di ITB. Pada cooperative web cache ada tambahan aktor yaitu sibling web cache. Sibling web cache merupakan web cache yang terletak pada satu level yang sama. Web cache akan melakukan proses cooperative dengan sibling-nya. Selain itu, diperkenalkan aktor local cache, yang perannya seperti cache pada gambar III-5, namun sengaja dibedakan namanya untuk memperjelas perbedaannya dengan sibling web cache. Local cache, merupakan cache yang dimiliki oleh sebuah proxy. Gabungan antara local cache dan proxy membentuk web cache. Proses cooperative dilakukan untuk mencari objek yang diinginkan oleh client.
37
Tabel III-3. Aktor dan peran pada cooperative web cache Aktor
Peran
Client
-
Mengirimkan request HTTP
-
Menerima response kembali dari proxy.
-
Menerima request HTTP dari client.
-
Mencari objek ke local cache.
-
Jika objek tidak ditemukan pada local cache, membentuk
Proxy
pesan ICP untuk identifikasi objek di web cache sibling. -
Menerima respon ICP dari web cache sibling.
-
Memproses request ke sibiling web cache jika sibling web cache memiliki objek yang diminta.
-
Meneruskan ke web server aslinya atau ke parent web cache jika local cache atau sibling web cache tidak memiliki objek yang diminta.
Local Cache
-
Menerima request HTTP dari proxy.
-
Mengirimkan response kembali ke proxy.
-
Menyimpan objek web yang merupakan respon dari web server.
Parent Web Cache -
Menerima request HTTP dari proxy
/ Web Server
Mengirimkan response kembali ke proxy.
-
Sibling Web Cache -
Menerima pesan request ICP dari web cache sibling. Mengirimkan pesan response ICP ke web cache sibling
38
III.3.4.2 Siklus Hidup Cooperative Web Cache Gambar III-6 berikut menunjukkan Sequence diagram dari siklus hidup cooperative web cache. Siklus hidup menyatakan proses yang dilakukan oleh web cache dalam menerima request dari client, sampai client menerima response atas permintaannya tersebut. Response dapat berupa objek yang diinginkan maupun pesan error atas request yang diberikan.
Client
Cache Lokal
Proxy
HTTP: GET
Sibling Web Cache
Parent/Web Server
HTTP: GET Yes
HTTP: RESPONSE HTTP: RESPONSE
Is it Stored? Is it Fresh?
No
CACHE_MISS ICP_OP_QUERY Yes
ICP_OP_HIT
Is it Stored? Is it Fresh?
No
HTTP: GET HTTP: RESPONSE HTTP: RESPONSE ICP_OP_MISS HTTP: GET HTTP: RESPONSE HTTP: RESPONSE Store Copy?
Yes
Store
Gambar III-6. Siklus hidup cooperative web cache ITB Ada tiga buah skenario yang tertera dalam gambar III-6, yaitu: 1. Local HIT, dicapai jika cache lokal memiliki objek yang diinginkan client. 2. Sibling HIT, dicapai jika sibling memiliki objek yang diinginkan client. 3. Sibling MISS, dicapai jika sibling tidak memiliki objek yang diinginkan cliefnt sehingga objek harus diambil dari web server aslinya atau ke parent. 39
III.3.4.3 Model Cooperative Web Cache ITB Berdasarkan bab 3.2.3.1 dan bab 3.2.3.2 dibentuklah sebuah model cooperative web cache ITB yang dapat dilihat pada gambar III-5. Skenario yang terjadi pada gambar III-5 adalah sebagai berikut: a. Skenario Local HIT dicapai melalui jalur 1-2-3-12. b. Skenario Sibling HIT dicapai melalui jalur 1-2-4-6-7-8-9-12, jika objek tidak ingin disimpan dalam cache atau dicapai melalui jalur 1-2-4-6-7-8-912-5, jika objek ingin disimpan dalam cache. c. Skenario Sibling MISS dicapai melalui jalur 1-2-4-6-7-10-11-12-5 jika objek ingin disimpan dalam cache atau melalui jalur 1-2-4-6-7-10-11-12 jika objek tidak perlu disimpan dalam cache.
Gambar III-7. Model cooperative web cache ITB saat ini.
III.4 Analisa dan Evaluasi III.4.1 Fungsi Dasar Cooperative Web Cache Pada cooperative web cache, ada tiga jenis komunikasi yang mungkin terjadi. Komunikasi tersebut bertujuan untuk menemukan dan mengirimkan objek yang diinginkan oleh client. Ketiga jenis komunikasi tersebut adalah
40
a. Komunikasi dengan cache lokal b. Komunikasi dengan sibling web cache, jika cache lokal tidak memiliki objek yang diinginkan client. c. Komunikasi dengan parent web cache atau dengan web server, jika sibling web cache tidak memiliki objek yang diinginkan client. Cooperative web cache juga memiliki empat fungsi dasar, seperti yang tertera pada bagian 2.2.3, yaitu a. Discovery Proses discovery objek di cache lokal dilakukan dengan menggunakan protokol HTTP. Proses discovery objek di sibling web cache dengan menggunakan protokol ICP. Proses discovery objek di parent web cache atau web server dilakukan dengan menggunakan protokol HTTP. b. Dissemination Pada proses dissemination akan ditentukan apakah sebuah objek akan disimpan atau tidak. Penentuan ini dilakukan berdasarkan apakah sebuah objek dari response dinyatakan cacheable atau tidak. Sebuah responses dinyatakan cachable jika memenuhi salah satu kondisi berikut: i.
URL tidak mengandung string yang mengindikasikan bahwa sebuah request akan menghasilkan response sebuah objek dinamik. Tabel III-4 menyatakan beberapa string yang dapat dijadikan penanda kemungkinan terjadinya response dinamik:
41
Tabel III-4. String penanda uncachable pada URL String
Penjelasan
/cgibin/
Kemunculan string ini menyatakan bahwa response dibentuk oleh CGI
atau .cgi
script.
/servlet/
Kemunculan string ini menyatakan bahwa response biasanya dibentuk oleh eksekusi sebuah Java servlet pada web server.
.asp
Kemunculan string ini menyatakan bahwa response dibentuk oleh ASP script.
.shtml
Kemunculan string ini menyatakan bahwa web server akan melakukan interpretasi dan menggantinya dengan beberapa content yang dibentuk secara dinamik.
?
Kemunculan string ini menyatakan bahwa URL merupakan sebuah query yang pasti akan menghasilkan response dinamik
ii.
HTTP server response code termasuk dalam salah satu daftar yang tercantum pada tabel III-5:
Tabel III-5. Response code yang cachable Code Deskripsi
Penjelasan
200
OK
Request diproses dengan sukses
203
Non-
Request diproses dengan sukses, tetapi sender yakin bahwa
Authoritative
header berbeda dengan yang akan dikirimkan oleh web
Information
server
Partial Content
Request diproses dengan sukses, tetapi hanya cachable jika
206
web cache mendukun g range request (memperbolehkan client untuk me-request bagian tertentu dari sebuah objek ) 300
Multiple Choices
Response berisi beberapa pilihan dimana client harus memilihnya.
301
410
Moved
Objek yang diminta telah dipindahkan ke lokasi baru. URL
Permanently
baru dituliskan pada response header.
Gone
Objek yang diminta telah dihapus secara permanen dari web server
42
iii.
Metode request yang digunakan adalah GET.
iv.
Header dari request dan response mengandung salah satu cachecontrol yang tercantum pada tabel III-6:
Tabel III-6. Cache control yang cachable Cache
Penjelasan
Control smaxage
s-maxage menyatakan waktu kadaluarsa sebuah objek. Adanya informasi ini di dalam header membuat sebuah objek menjadi cachable.
Proxy
Adanya informasi proxy-revalidate membuat sebuah objek
revalidate
menjadi cachable.
c. Validation Proses validation dilakukan berdasarkan informasi waktu kadaluarsa dari sebuah response yang eksplisit dinyatakan oleh web server melalui informasi expires pada header, maupun melalui cache-control:max-age. Jika response tidak memiliki informasi eksplisit waktu kadaluarsa, maka proses validation menggunakan menggunakan refresh_pattern untuk menentukan apakah sebuah response dinyatakan valid atau tidak. Validitas menyatakan apakah sebuah response cukup fresh atau sudah kadaluarsa. Refresh_pattern memiliki parameter minimal dan maksimal dalam satuan menit. Parameter minimal merupakan batas atas sebuah response dinyatakan fresh. Parameter maksimal merupakan batas bawah sebuah response dinyatakan kadaluarsa. Response yang berada di antara nilai parameter minimal dan maksimal akan divalidasi menggunakan
43
algoritma LM-factor. Proses validasi tersebut digambarkan pada gambar III-8.
Gambar III-8. Ilustrasi proses validasi response dengan menggunakan refresh_pattern Jika response age merupakan jeda sejak web server memberikan response atau sejak memberikan last validated response, dan resource age merupakan selisih antara nilai Last-modified dan date pada informasi header, maka LM-factor merupakan perbandingan antara response age dengan resource age. Refresh pattern juga memiliki parameter percent. Parameter percent ini akan dibandingkan dengan nilai LM-factor. Sebuah response dinyatakan fresh jika LM-factor lebih kecil dari nilai parameter percent pada refresh_ pattern. d. Replacement Replacement merupakan proses yang terjadi ketika cache penuh, sehingga objek yang sudah lama harus dihapus untuk memberikan tempat baru bagi objek baru yang ingin disimpan. Proses replacement objek pada web cache ITB menggunakan algortima LRU (Least Recently Accessed). LRU akan menghapus objek yang sudah tidak pernah diakses lagi. Implementasi dari algoritma ini dapat menggunakan sebuah list. Setiap kali objek diakses, objek akan dipindah ke list yang paling atas. Sehingga, objek yang paling jarang diakses akan berada pada list yang paling bawah. LRU akan menghapus objek yang letaknya termasuk dalam kategori anggota list terbawah. 44
III.4.2 Artifak Proses Cooperative Proses cooperative membutuhkan artifak yang akan digunakan oleh koordinator dalam memantau dan mengetahui apa yang telah dan apa yang sedang terjadi dalam proses cooperative. Pada cooperative web cache di ITB, peran koordinator pada model cooperative web cache pada gambar III-7 dilakukan oleh proxy. Proxy memutuskan bagaimana
request dari client diproses sehingga
menghasilkan response yang sesuai dan dapat dikirimkan ke client. Artifak pada cooperative web cache tersebut adalah: a. Templates: properti hasil dari kerja cooperative. Tujuan cooperative web cache adalah sebagai berikut: i.
Menemukan informasi keberadaan sebuah objek yang berada pada sibling web cache. Untuk menemukan informasi keberadaan sebuah objek, web cache harus mengirimkan pesan query ICP ke seluruh sibling web cache. Sibling web cache akan mengirimkan reply kembali ke web cache. Web cache akan memilih reply tercepat yang mengembalikan hit, kemudian mengirimkan request HTTP menuju sibling web cache.
ii.
Efisiensi tempat penyimpanan objek web. Karena pada cooperative web cache dapat saling berbagi web object, maka objek yang sudah tersimpan pada sibling web cache tidak perlu disimpan ulang pada cache lokal. Sehingga cache lokal dapat digunakan untuk menyimpan objek lain yang belum disimpan pada sibling web cache.
b. Maps: spesifikasi interdependensi antar task maupun sumber daya dalam skenario cooperative. Maps pada cooperative web cache dinyatakan dengan hirarki hubungan child, sibling dan parent. Pada hubungan sibling, web cache dapat melakukan query untuk mengetahui keberadaan sebuah objek pada sibling web cache. Namun, jika objek tidak ditemukan pada sibling web cache, sibling web cache tidak perlu mencarikan objek tersebut di tempat lain.
45
Pada hubungan parent, web cache sebagai child dapat meminta parent untuk mencarikan objek yang diingkan sampai ditemukan response yang sesuai, jika objek tidak dapat ditemukan pada sibling web cache. Hirarki hubungan telah digambarkan pada gambar III-2. c. Scripts: spesifikasi protokol mengenai artikulasi sebuah task dan interaksi sumber daya. Scripts pada cooperative web cache dinyatakan dalam sebuah file konfigurasi yaitu squid.conf. Tabel A-1 pada lampiran A menyatakan beberapa konfigurasi penting yang menyatakan task dan interaksi sumber daya yang digunakan dalam cooperative web cache. III.4.3 Penghitungan Kinerja Cooperative Web Cache Salah satu tahapan analisa yang akan dilakukan adalah untuk melakukan evaluasi kinerja. Seperti yang telah diungkapkan pada bagian 2.2.5, bahwa kinerja web cache dapat diukur dari throughput, response time, dan hit rate. Karena nilai throughput sangat dipengaruhi keberadaan bandwith, dan bandwith merupakan sumber daya yang dianggap tetap pada penelitian ini, maka throughput tidak digunakan untuk menghitung kinerja cooperative web cache. Response time didefinisikan sebagai interval waktu dari request dikirimkan oleh client sampai client menerima response dari web cache. Terkait dengan salah satu tujuan web cache yaitu pengurangan delay, maka response time penerapan model cooperative web cache harus lebih kecil daripada response time jika akses dilakukan langsung ke web server aslinya. Hit rate didefinisikan sebagai presentase perbandingan antara jumlah request yang menghasilkan hit dengan total request. Hit terjadi jika objek yang diinginkan dapat diperoleh dari web cache dan bukan dari web server aslinya. Hal ini terkait dengan fungsi dissemination dan penghapusan objek. Nilainya dipengaruhi dari bagaimana menentukan tempat penyimpanan, kapasitas penyimpanan dan algoritma yang diterapkan untuk melakukan penghapusan objek. Jika algoritma penghapusan objek dan kapasitas penyimpanan dianggap tetap, maka nilai hit rate akan sangat dipengaruhi oleh bagaimana menentukan tempat penyimpanan. 46
Perbedaan akses via cooperative web cache dan tidak adalah adanya penambahan trafik untuk komunikasi ke web cache tetangganya yang bertujuan untuk mengidentifikasi keberadaan sebuah objek web yang diminta. Besarnya trafik komunikasi yang dibutuhkan untuk melakukan proses cooperative, tidak boleh menyebabkan response time menjadi lebih besar daripada response time akses langsung ke web server original. Adanya penambahan trafik komunikasi untuk menjalankan proses cooperative, menjadikan hit rate tidak tepat digunakan sebagai alat ukur kinerja pada cooperative web cache. Pada kasus sibling web cache yang terletak lebih jauh dari web server aslinya, meskipun menghasilkan sibling hit, secara biaya komunikasi nilai efisiensinya dapat dipertanyakan. Ole karena itu, hit rate tidak dijadikan sebagai metode utama yang digunakan untuk menghitung kinerja cooperative web cache. Penambahan trafik komunikasi untuk menjalankan proses cooperative dapat dihitung sebagai biaya komunikasi. Biaya komunikasi dengan menerapkan cooperative web cache sedapat mungkin harus lebih murah daripada jika hanya menerapkan web cache saja. Semakin kecil biaya komunikasi, maka response time aksesnya juga akan menjadi semakin kecil. Oleh karena itu, response time tidak digunakan sebagai alat ukur kinerja cooperative web cache, karena dianggap sudah diwakili oleh biaya komunikasi. III.4.4 Analisa Kuantitatif Penerapan Cooperative Web Cache di ITB Analisa kuantitatif dilakukan untuk mengetahui titik optimal penerapan cooperative web cache. Kriteria optimal ditentukan melalui identifikasi biaya komunikasi yang dibutuhkan untuk menjalankan proses cooperative. Biaya komunikasi pada cooperative web cache harus lebih kecil daripada biaya komunikasi pada web cache. III.4.4.1 Identifikasi dan Pernyataan Masalah Salah satu tujuan cooperative web cache adalah untuk mengurangi delay. Pengurangan delay terjadi jika trafik HTTP yang menuju internet juga berkurang. 47
Pada bagian II.2.4.3 telah dinyatakan bahwa ada tiga buah skenario yang terjadi pada cooperative web cache, yaitu skenario local hit, sibling hit, dan sibling miss. Jika local hit terjadi, maka diperoleh keuntungan karena local hit tidak mengeluarkan trafik antara web cache dengan web server. Jika terjadi local miss, maka web cache akan melakukan komunikasi dengan sibling web cache untuk mencari kemungkinan terjadinya sibling hit. Komunikasi tersebut dilakukan dengan mempertukarkan pesan ICP (request dan reply) melalui internet. Jika terjadi sibling hit, web cache hanya perlu mengeluarkan trafik request ke sibling web cache. Karena biasanya web cache memiliki jarak yang lebih dekat dengan sibling web cache daripada ke web server aslinya, maka trafik yang muncul antara web cache dengan sibling web cache akan lebih sedikit jumlahnya daripada trafik yang muncul antara web cache dengan parent web cache atau dengan web server aslinya. Jika terjadi sibling miss, maka tidak terjadi keuntungan karena jumlah trafik yang muncul antara web cache dengan web server tidak berkurang. Karena kompleksnya proses komunikasi yang dilakukan pada cooperative web cache, maka kinerja cooperative web cache tidak cukup dihitung hanya dari hit rate saja. Karena meskipun jumlah total hit rate meningkat akibat dari terjadinya sibling hit, perlu juga dikaji apakah jumlah trafik komunikasi untuk proses cooperative jumlahnya tidak melebihi total trafik yang berhasil dikurangi dari terjadinya sibling hit. Permasalahannya adalah belum diketahuinya secara pasti berapakah jumlah total trafik HTTP yang dihasilkan oleh penerapan cooperative web cache di ITB. Apakah terjadi pengurangan trafik internet jika dibandingkan dengan tidak menggunakan cooperative web cache? Berapakah penghematan yang berhasil dilakukan, sehingga penggunaan bandwith dapat dialokasikan untuk kepentingan riset yang membutuhkan akses internet sebagai sarana utama penelitian?
48
III.4.4.2 Pembatasan Lingkup Trafik pada jaringan dihitung dari jumlah paket maupun ukuran data yang melalui sebuah jalur komunikasi. Jalur komunikasi merupakan jalur antara client menuju server. Pada jalur antara client dan server terdapat beberapa router antara. Jarak antara client dengan router berikutnya, antara satu router dengan router berikutnya, dan antara router dengan web server disebut Hop. Jadi jarak antara client
dengan server sama dengan jumlah router ditambah 1.
Diasumsikan
bahwa pada satu satuan komunikasi data, sejumlah paket Jp dipertukarkan antara client dengan server. Skenario komunikasi ini diilustrasikan pada gambar III-9.
Gambar III-9. Skenario komunikasi dari client ke server. Dari gambar III-9, dirumuskan bahwa jika sejumlah paket Jp yang melewati satu jalur komunikasi dari client ke server dengan sejumlah hop H dapat dinyatakan sebagai biaya komunikasi PaketHop (PH), maka PH dapat dirumuskan menjadi rumus (1) PH = Jp × H
(1)
Karena dalam satu kali pengaksesan objek mungkin terdiri atas beberapa aktivitas pertukaran pesan ICP dan beberapa session HTTP, maka perumusan pada no (1) dapat disempurnakan lagi untuk satufan kerja akses sebuah objek, menjadi rumus (2): n
PHT = ∑ PH i
(2)
i =1
49
Dengan n = jumlah total aktivitas komunikasi data. Pada cooperative web cache, skenario local hit tidak menghasilkan trafik tambahan menuju ke internet. Skenario yang menghasilkan trafik internet adalah skenario sibling hit dan skenario sibling miss. Pada skenario sibling hit, trafik ke internet diperlukan untuk mengirimkan pesan ICP ke sibling web cache dan mengirim request HTTP ke sibling web cache untuk mengambil objek yang diperlukan. Pada skenario sibling miss, trafik ke internet diperlukan untuk mengirimkan pesan ICP ke sibling web cache untuk mencari objek pada sibling web cache, dan request HTTP ke parent web cache atau web server untuk mengambil objek yang diinginkan. Oleh karena itu, penghitungan jumlah komunikasi yang dihasilkan dari aktivitas cooperative web cache didasarkan pada dua skenario saja yaitu skenario sibling hit dan sibling miss.
Sibling Web Cache -1
Sibling Web Cache -2
Jarak = Jumlah Hop = Hs2 Router Hs1-1
Jarak = Jumlah Hop = Hs1
Router Hs2-1
Jarak = Jumlah Hop = Hsn
Router Hsn-1 Sibling Web Cache -n
Client
Router 1 Web Cache Local Hit = Lh Sibling Hit = Sh
Router Ha-1 Jarak = Jumlah Hop = Ha
Gambar III-10. Skenario cooperative web cache. 50
Parent Web Cache / Web Server
Diasumsikan bahwa jarak antara web cache dengan parent web cache / web server aslinya adalah sebesar Ha dan jarak antara web cache dengan sibling web cache adalah Hs. Dengan menjalankan skenario cooperative web cache tersebut diperoleh local hit sebesar Lh dan sibling hit sebesar Sh. Skenario cooperative web cache tersebut dapat diamati pada gambar III-10. Skenario pada gambar III-10 diturunkan dari gambar III-9. Sesuai dengan penjelasan pada bab II.5, Squid yang memiliki dua sisi fungsi yaitu sisi client yang berkomunikasi dengan web client seperti browser, dan sisi server yang berkomunikasi dengan web server. Oleh karena itu, pada gambar III-10, web cache berfungsi sebagai client dalam skenario cooperative web cache. Jumlah total komunikasi pada cooperative web cache pada kasus sibling hit ada dua, yaitu: a. Pertukaran pesan ICP, baik query maupun reply ke seluruh sibling web cache. b. Koneksi HTTP ke sibling web cache untuk mengambil objek yang diinginkan. Jumlah total komunikasi pada kasus sibling miss ada dua yaitu: a. Pertukaran pesan ICP, baik query maupun reply ke seluruh sibling web cache. b. Koneksi HTTP dengan parent web cache atau web server aslinya. III.4.4.3 Pemilihan Variabel yang akan Diamati Variabel yang akan diamati adalah a. Ukuran data (bytes) Variabel ini diamati untuk menentukan rata-rata ukuran objek yang ditangani untuk masing-masing skenario baik local hit, local miss, sibling hit, maupun sibling miss. 51
b. Jumlah paket Variabel ini diamati untuk menentukan rata-rata jumlah paket untuk data dengan ukuran objek tertentu pada masing-masing skenario baik local hit, local miss, sibling hit, dan sibling miss. Rata-rata jumlah paket ini akan menggambarkan nilai dari Jp pada rumus (1). c. Rata-rata Hit dan Miss Variabel ini akan diamati untuk melihat porsi rata-rata terjadinya hit dan miss untuk setiap skenario baik local hit, local miss, sibling hit, maupun sibling miss. d. Jumlah Hop Variabel ini akan diamati untuk melihat rata-rata jarak antara web cache menuju parent web cache maupun menuju web server aslinya. Hasil pengamatan terhadap variabel ini dapat menggambarkan nilai H pada rumus (1). III.4.4.4 Pemilihan Design Experiment Pengamatan dilakukan terhadap salah satu cooperative web cache yang ada di ITB, yaitu cooperative web cache yang dikoordinasikan oleh cache1. Cache1 melayani
sebanyak
8157
client
civitas
akademika
ITB
(http://logger-
ng.itb.ac.id/cache1). Berikut ini adalah aktivitas yang akan dilakukan dalam mengamati variabel yang telah dipilih pada bab III.4.4.3. a. Pengamatan ukuran objek dan rata-rata hit atau miss. Data pengamatan diperoleh dari data log akses yang dihasilkan oleh Squid. Pengamatan dilakukan selama 1 bulan dari tanggal 1 Mei 2009 sampai 31 Mei 2009. Data pengamatan dikumpulkan per hari dan dihitung berapa jumlah hit dan miss yang terjadi. Setiap kali terjadi hit dan miss, dihitung jumlah total data yang dipertukarkan. Untuk komunikasi pesan HTTP, jumlah data yang dipertukarkan untuk setiap pesan HTTP dapat mewakili ukuran objek web. Untuk komunikasi pesan ICP, ukuran pesannya tidak dapat terlihat dari data log akses. Oleh karena itu, untuk mengetahui ukuran pesan ICP, akan 52
dilakukan penghitungan terhadap jumlah pesan ICP yang dikirimkan dan besarnya pesan ICP yang dikeluarkan pada satuan waku tertentu. Satuan waktu pengamatannya dipilih 1 menit secara acak. Dari hasil pengamatan tersebut dapat ditentukan rata-rata ukuran pesan ICP per pesan ICP. b. Penentuan jumlah paket Setiap data yang akan dikirimkan melalui jalur komunikasi, akan dipecah menjadi beberapa paket data. Pemecahan paket data tergantung pada ukuran besarnya data dan nilai MTU. MTU (Maximum Transmission Unit) merupakan besaran maksimal ukuran paket data dalam satuan bytes yang dapat ditransimisikan melalui jaringan komunikasi. Jadi setiap pesan yang ukurannya melebihi MTU akan dipecah menjadi
ukuranpesan paket. MTU
MTU yang ditetapkan oleh ITB adalah 1400 bytes. c. Penentuan jumlah hop Untuk membantu menentukan berapa jumlah hop antara web cache dengan web server, maka digunakan program traceroute yang dijalankan dari cache1. Akan dipilih sejumlah lima pulu buah web server yang paling sering diakses selama bulan Mei 2009. III.4.4.5 Menjalankan Eksperimen Pada saat menjalankan observasi, ada kegagalan sistem squid pada tanggal 17, 19, 23, dan 24 Mei 2009. Akibatnya log pada tanggal tersebut tidak dapat dimasukkan sebagai bagian dari data pengamatan. Berikut adalah daftar data-data yang berhasil dikumpulkan. a. Data pengamatan request yang menghasilkan local hit dan local miss. Hasil pengamatan dapat dilihat pada tabel B-1 di lampiran B.1. b. Data pengamatan total ukuran objek per status local hit dan local miss Hasil pengamatan dapat dilihat pada tabel B-2 di lampiran B.2 c. Data pengamatan request yang menghasilkan sibling hit dan sibling miss Hasil pengamatan dapat dilihat pada tabel B-3 di lampiran B.3 d. Data pengamatan ukuran objek per status sibling hit dan sibling miss. Hasil pengamatan dapat dilihat pada tabel B-4 di lampiran B.4 53
e. Data ukuran objek web per status local hit, local miss, sibling hit, dan sibling miss Dari tabel B-1 pada lampiran B.1, tabel B-2 pada lampiran B.2, tabel B-3 pada lampiran B.3, dan tabel B-4 pada lampiran B.4 dapat dihitung besarnya ukuran objek web per status. Hasilnya dapat dilihat pada tabel III-7. Tabel III-7. Data ukuran objek web per status Status
Total Request
Total Objek (bytes)
42.297.214 73.867.232 5.261.683 68.605.549
270.401.099.191 1.224.236.193.805 41.090.173.236 1.188.499.161.811
Local HIT Local MISS Sibling HIT Sibling MISS
Ukuran Objek 6.393 16.573 7.809 17.324
f. Data ukuran pesan ICP Hasil pengamatan dapat dilihat pada tabel B-5 di lampiran B.5. g. Data jumlah paket Hasil pengamatan dapat dilihat pada tabel B-6 dan B-7 di lampiran B.6 h. Data jumlah Hop Hasil pengamatan dapat dilihat pada tabel B-8, B-9, dab B-10 di lampiran B.7 Median dari Ha adalah 15, dan median untuk Hs adalah 7. III.4.4.6 Analisa Statistik terhadap Data Untuk memudahkan proses analisa, dibuat tabel III-8 yang merupakan hasil rangkuman dari tabel III-7 dan tabel B-6. Tabel III-8 menyatakan rangkuman ratarata status request, rata-rata ukuran objek, dan jumlah paketnya. Tabel III-8. Rata-rata request, ukuran objek, dan jumlah paket Jumlah Paket ( Jp )
Local HIT ( Lh )
36,41
Ukuran Data (bytes) ( Jd ) 6.393
Local MISS ( Lm )
63,59
16.573
11,84
Sibling HIT ( Sh )
4,53
7.809
5,58
59,06
17.324
12,37
Status
Sibling MISS ( Sm )
% Request
54
4,57
Untuk mengetahui apakah cooperative web cache memang benar-benar mengurangi jumlah trafik yang menuju internet dan sampai batas mana keuntungan dari cooperative web cache melebihi batas biaya komunikasi, maka dirumuskan satuan kerja akses objek yang paling banyak membutuhkan biaya komunikasi. Satuan kerja akses objek tersebut adalah akses objek dari web cache ke web server aslinya. Akses langsung ke web server aslinya terjadi jika web cache tidak memiliki objek yang diinginkan client. Sehingga, rata-rata biaya komunikasi akses objek dari web cache ke web server aslinya dapat dinyatakan sebagai: PH ( Ha ) = Average( PHT )
(3)
Keuntungan cooperative web cache diperoleh jika biaya komunikasi yang dibutuhkan untuk mengakses sebuah objek lebih kecil daripada biaya komunikasi akses objek langsung ke web server aslinya. Untuk mengetahui keuntungan dari implementasi cooperative web cache maka rumus (3) akan diterapkan pada dua macam kasus, yaitu kasus web cache dan kasus cooperative web cache. a. Kasus web cache Pada kasus web cache artinya implementasi web cache digambarkan seperti pada gambar III-5, dimana setiap kali terjadi local miss maka request langsung diteruskan ke parent web cache atau web server aslinya. Sehingga, rumus (3) dapat diturunkan menjadi PH ( Ha ) = Lm × JpLm × Ha
(4)
Dengan JpLm = rata-rata jumlah total paket yang dilewatkan di jaringan pada kondisi local miss
Lm
= rata-rata jumlah local miss.
Ha
= jumlah hop dari web cache web server
55
b. Kasus cooperative web cache Pada kasus cooperative web cache artinya setiap kali terjadi local miss, maka pesan ICP akan dikirimkan ke seluruh sibling web cache. Sekali pesan ICP terdiri atas query dan reply, sehingga ada 2 paket data yang dikirimkan ke masing-masing sibling web cache sebesar 160 bytes. Karena saat ini cache1 memiliki 8 sibling, maka pesan ICP akan dikirimkan sekaligus ke 8 sibling web cache. ICP memunculkan kemungkinan terjadinya sibling hit sebesar Sh. Jika terjadi sibling hit, maka request HTTP akan diteruskan ke sibling web cache. Jika terjadi sibling miss, maka request HTTP akan diteruskan ke web server aslinya. Sehingga rumus (3) dapat diturunkan menjadi: PH ( Ha) = ( Lm × 2 × Jpicp × S × Hs) + ( Sh × Jp Sh × Hs) + ( Sm × Jp Sm × Ha)
Dengan JpLm = rata-rata jumlah total paket yang dilewatkan di jaringan pada kondisi local miss.
JpSh
= rata-rata jumlah total paket yang dilewatkan di jaringan pada kondisi sibling hit.
Jp Sm
= rata-rata jumlah total paket yang dilewatkan di jaringan pada kondisi local miss.
Jpicp
= rata-rata jumlah total paket ICP.
Lm
= rata-rata frekuensi local miss.
Sh
= rata-rata frekuensi sibling hit.
Sm
= rata-rata frekuensi sibling miss.
Ha
= jumlah hop dari web cache ke web server.
Hs
= jumlah hop dari web cache ke sibling web cache.
S
= jumlah sibling web cache.
56
(5)
Biaya komunikasi pada cooperative web cache untuk skenario terburuk, setidaknya harus sama dengan biaya komunikasi pada kasus web cache. Dengan menyamakan antara rumus (4) dengan rumus (5), maka akan diperoleh titik impas biaya komunikasi berdasarkan jumlah paket yang dilewatkan di jaringan. Persamaan yang dibentuk adalah persamaan (6).
Lm × Jp Lm × Ha = ( Lm × 2 × 0,11× 8 × Hs) + ( Sh × Jp Sh × Hs) + ( Sm × Jp Sm × Ha) (6) Dengan memasukkan nilai Lm , JpLm , Sm , JpSm , Sh , dan JpSh dari tabel III-8, menghasilkan persamaan (7). 0,64 × 11,84 × Ha = (0,64 × 1,76 × Hs ) + (0,04 × 5,58 × Hs ) + (0,59 × 12,37 × Ha ) Ha = 4,94 × Hs
(7)
Persamaan tersebut menyatakan bahwa, model cooperative web cache akan menguntungkan jika jarak antara web cache dengan web server aslinya lebih besar dari 4,94 x jarak antara web cache dengan sibling web cache. Artinya sibling web cache hanya boleh menyimpan objek dari web server yang jauhnya lebih dari 4,94 x jarak web cache ke parent web cache atau web server aslinya. Jika kurang dari jarak tersebut, maka sistem cooperative web cache dinilai kurang menguntungkan dari sisi biaya komunikasi. Untuk mengetahui berapa persen sibling hit yang dihasilkan dari model cooperative web cache, maka dilakukan penurunan rumus persamaan (6). Hasilnya adalah persamaan (8). Lm × Jp Lm × Ha = ( Lm × 2 × 0,11× 8 × Hs ) + ( Sh × Jp Sh × Hs ) + ( Sm × Jp Sm × Ha ) (1 − Lh) × Jp Lm × Ha = (1,76(1 − Lh) × Hs ) + ( Sh × Jp Sh × Hs ) + ((1 − Lh − Sh) × Jp Sm × Ha) (1 − Lh) × Jp Lm × Ha = (1,76(1 − Lh) × Hs ) + ( Sh × Jp Sh × Hs ) + ((1 − Lh) × Jp Sm × Ha) − ( Sh × Jp Sm × Ha) ((1 − Lh) × Ha)( Jp Lm − Jp Sm ) = (1,76(1 − Lh) × Hs) + Sh × (( Jp Sh × Hs ) − ( Jp Sm × Ha))
Sh =
(1 − Lh) × ((( Jp Lm − Jp Sm ) Ha) − (1,76 × Hs)) ( Jp Sh × Hs) − ( Jp Sm × Ha)
57
(8)
Dari tabel III-8, nilai Lh , JpLm , JpSm , dan JpSh dapat digunakan untuk menyederhanakan persamaan (8), sehingga hasilnya adalah persamaan (9) Sh =
0,64 × ((−0,54 × Ha) − (1,76 × Hs)) (5,58 × Hs) − (12,37 × Ha)
(9)
Dari persamaan (9), dapat diketahui pengaruh jarak antara web cache dengan web server ( Ha ) dan jarak antara web cache dengan sibling web cache ( Hs ) terhadap sibling hit ( Sh ). Dari tabel B-10, diketahui nilai maksimal Ha adalah 30. Dari tabel B-8, diperoleh bahwa nilai maksimal Hs adalah 7. Dengan memvariasikan nilai Ha dan Hs, maka diperoleh hasil penghitungan rumus (9). Hasil penghitungan rumus (9), dapat dilihat di tabel B-11 pada pada lampiran B.8. Dari hasil perhitungan tersebut diambil nilai yang hubungan antara Ha dan Hs memenuhi persamaan (7), sehingga diperoleh grafik batas bawah PH (Ha) seperti yang terlihat pada gambar III-11.
Gambar III-11. Batas impas biaya komunikasi ( PH )
58
Dari gambar III-11 dapat disimpulkan bahwa : a. Gambar III-11 menyatakan kondisi impas antara Ha, Hs dengan Sh , berdasarkan biaya komunikasi PH. b. Dengan menggunakan skema cooperative web cache tersebut, nilai sibling hit maksimalnya adalah 5,07%. Kemungkinan penyebabnya adalah karena kesamaan user yang dilayani oleh setiap web cache tersebut. Sehingga kemungkinan cache miss yang terjadi di sebuah web cache, juga tidak ditemukan objeknya di web cache yang lain. c. Sibling web cache yang menghasilkan sibling hit kurang dari 3,1%, tidak memberikan nilai keuntungan dari cooperative web cache yaitu pengurangan trafik ke internet. III.4.4.7 Kesimpulan dan Rekomendasi Analisa Kuantitatif Model Cooperative Web Cache Kesimpulan yang dapat ditarik atas skema cooperative web cache ITB saat ini adalah a. Skema cooperative web cache yang diterapkan di ITB telah mampu mengurangi trafik ke internet, karena mampu menghasilkan sibling hit rata-rata sebesar 4,53%. Jika dibandingkan dengan nilai Sh yang pada gambar III-11, maka nilai rata-rata sibling hit pada cooperative web cache ITB dapat dikatakan cukup bagus, karena nilainya hampir mendekati niliai sibling hit maksimal yaitu 5,07% b. Skema cooperative web cache ini mengharuskan web cache untuk selalu mengirimkan pesan ICP ke seluruh sibling web cache untuk memperoleh informasi keberadaan sebuah objek pada sibling. Artinya setiap terjadi cooperative, koordinator tidak menyimpan informasi keberadaan objek untuk pengaksesan objek selanjutnya. Informasi keberadaan objek pada sibling web cache tidak disimpan karena adanya kemungkinan penghapusan objek pada sibling web cache tanpa pemberitahuan terlebih dahulu.
59
Rekomendasi yang dapat dilakukan untuk meningkatkan keuntungan dari cooperative web cache adalah: a. Pengurangan trafik ke internet yang disebabkan oleh proses cooperative dapat dikurangi dengan meningkatkan peran koordinator sebagai penyimpan informasi keberadaan sebuah objek pada sibling web cache yang lain. b. Untuk mendukung rekomendasi pada butir a, maka proses cooperative harus ditambahkan mekanisme untuk mengetahui validitas keberadaan objek pada sibling web cache. c. Mekanisme untuk mengetahui validitas keberadaan objek harus dirancang sedemikian rupa agar tidak menambahkan trafik menuju internet yang tidak signifikan. d. Sibling web cache yang menghasilkan sibling hit kurang dari 3% sebaiknya dihapus dari keanggotaan cooperative web cache karena dianggap tidak memberikan nilai keuntungan dari cooperative web cache. Selain itu, mengurangi sibling web cache juga berarti mengurangi pesan ICP yang diperlukan dalam proses cooperative, sehingga dapat sedikit meningkatkan kinerja cooperative web cache ITB dari sisi banyaknya trafik ke internet yang digunakan untuk proses cooperative.
60
