Partial Cache di Squid

Seingat saya, tahun ’88 sudah ada DOS tuch…. Anda benar. Ada referensi sejarah DOS

Kembali ke topik, apa gara-gara ini ya log di proxy (squid) penuh dengan Windows Update? Gawatnya, proses download ini dengan Range / Partial Content yang kecil-kecil, misalnya 6 KByte, 10K, 20K, dan seterusnya. Bila 820 MByte dibuat pecahan 10K, ada 82rb-an baris. Ini baru 1 PC, lha kalo 100 PC ada 8jt-an baris. Lumayan makan tempat + IO.

Sayangnya pula squid tidak cerdas dengan urusan Range header ini, sehingga cache miss semua. Setting range_offset_limit kurang membantu (lha kalo didownlotin dulu semua kelamaan). Logikanya, pecahan-pecahan tadi bisa dikumpulkan dan direkonstruksi untuk permintaan serupa lainnya. Apalagi download accelerator, yang potensial menyedot bandwidth, cara kerjanya juga serupa. Ada yang punya solusi atau bahkan (membuat) patch khusus soal ini? TIA.

Masalahnya Si A, B, dan C bisa menggunakan range yang berbeda.

Itu yang saya bilang squid tidak cerdas. Bila file yang dituju sama, range yang pernah didownload tidak perlu didownload lagi. Ketika A minta 1 – 11, selesai, lalu B Minta 2 – 12, sudah ada 2 – 11, tinggal minta lagi 12. Lebih lanjut lagi, bila suatu file dengan range yang tumpang-tindih selesai semua, file ini bisa direkonstruksi menjadi 1.

Bila trend download file ke depan seperti ini, mekanisme di atas harus ada. Jika tidak penghematan bandwidth dengan proxy semakin minim. Saya lihat ada draft tentang ini:
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-04 . Tapi ketimbang menunggu disetujui, toh mekanismenya mirip, squid bisa menggunakan yang sekarang umum dipakai. Masalahnya 1, ada di satu milis, konon developer squid kian hari kian sedikit (CMIIW).

sampai terputus kan yang sudah didownload tidak bisa jadi pedoman.

Mekanisme ini sudah dijelaskan di HTTP/1.1 RFC2616, diperjelas lagi di draft yang sedang diusulkan. Pada intinya serupa dengan file, misalnya Last-Modified: xxx, hanya ini per bagian file / range.

(asumsi semua klien download dengan range eksplisit), tetap saja ini sangat kompleks, karena harus update checkpoint/db setiap kali

Kompleks? Sederhana saja. Hanya masalah read-ahead. Saat ini squid hanya mendukung per file read-ahead (range_offset_limit), tidak per blok. Bagaimana menyimpannya? 1 blok (misalnya 64 KByte) = 1 file, boleh digabung belakangan (reconstruction) boleh tidak. Btw, range pasti eksplisit, bila tidak disebutkan maka per file.

memang selalu saja ada trade-off ya. ok deh, good luck

Cache partial ini sudah disinggung di RFC2616, secara singkat squid tidak full HTTP/1.1 compliant. Moga-moga nantinya iya. Soal kepake, menurut saya ini mendesak. File kian hari kian besar, besaar, dan besaaarrrrr. OK-lah, PR buat squid.

Kalau yang saya amati, Microsoft sengaja membuat agar windows update sulit di-cache. Nama file sengaja dibuat random. Akhirnya

Hasil pengamatan log dari beberapa host, saya tidak melihat begitu, nama filenya adalah sama. Bila kesannya random, memang filenya berbeda (mungkin versi updatenya). Toh bila polanya jelas, bisa dilakukan url_rewrite / sejenis.

YaST Online Update yang saya gunakan di openSUSE. File-nya namanya sama. Jadi pada hit semua. Kalau tidak percaya, coba instal 100

Saya tidak tahu cara kerja openSUSE YOU, tapi bila terjadi mapping
file di client maupun server (jadi range pada file bisa diakses dengan nama berbeda) hal ini bisa mengefektikan cache pada proxy.

Kalau download accelerator yang mendownload barang yang sama,
biasanya akan ter-cache dengan baik oleh squid. Ada 100 PC yang
mendownload barang yang sama, ya 100 x hit.

Saya coba prg downloader yang bisa multiple connection, yaitu axel ( http://axel.alioth.debian.org/) , hasilnya cache-miss semua. Agar lebih fair, bagaimana bila anda uji coba suatu downloader sejenis (jangan YOU), dan beritahu saya hasilnya bila cache-hit.

tapi kalau misal A request 200-400, kemudian setelah itu, B request 300-600, kalau tidak direconstruksi, lantas gimana. ini

Agar lebih jelas, bagaimana bila pecahan file ini dianalogikan dengan cluster di FAT? Setiap akses dari client di-mapping sesuai besar cluster. Bila blok cluster = 512, request 200-400 itu akan
diterjemahkan menjadi 0 s/d 511 (ke server). Request B akan melibatkan 2 cluster. Setiap cluster disimpan menjadi 1 file, katakan fff_cl_1, fff_cl_2, dst. Dengan demikian rekonstruksi sifatnya opsional, yang dibutuhkan adalah mapping range to file.

Mengapa dibutuhkan read-ahead per blok? Alasan pertama tentu waktu. Implementasi squid saat ini, butuh 100 byte dari 1 GByte, maka akan dibaca dulu 1 GByte baru diserahkan 100 byte (range_offset_limit). Aneh tapi nyata. Alasan kedua tentu efisiensi penyimpan. Hanya blok-blok yang pernah diminta yg disimpan. Range implisit seperti 9500- bila diterjemahkan per blok juga tidak masalah.

kalau squid mendapat range-requests maka sama sekali tidak dicache

Bisa dengan setting range_offset_limit, tapi dengan masalah di atas.

oleh Master Oogway: nothing is impossible

Sayang sekali Master Oogway bukan developer squid.

1 Komentar »

  1. […] https://oguds.wordpress.com/2008/11/06/partial-cache-di-squid/ […]

RSS feed for comments on this post · TrackBack URI

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s