Mekanisme umum akses internet via web browser utk menguji validitas (‘freshness’) obyek yg tersimpan adl dg ‘menjenguk’ obyek tsb ke server asal/sumber dan membandingkannya dg obyek yg sama yg sudah tersimpan di lokal. Jadi memang ‘boros’ walaupun belum tentu setiap saat obyek tersebut diambil lho, jadi hanya sekedar di’tanyai’ saja ‘tgl lahirnya’ (dan ada beberapa info yg lain yg penting juga, tapi kita fokus di ‘umur’nya saja). Dg demikian saran utk teman-teman yg mengelola warnet adl dg memperbesar cache lokal web browser (internet temporary files-nya utk IE dan tidak salah default-nya 10% dari ukuran partisinya ya?). 

Kenapa kok ‘umur’ obyek (atau halaman web) diuji? Ya kira2 jawabannya supaya informasinya selalu yg terbaru dan tidak salah (kalau tidak mau yg terbaru dan selalu hanya mengakses yg sudah tersimpan di lokal cache web browser ya di-set saja mode ‘offline, dijamin akses akan sangat lebih cepat dan sangat hemat bandwidth, tapi dg konsekuensi ekstrim spt halaman tsb di server sudah dihapus, di sisi klien bakalan tidak tahu lho). Kepingin mjd ’super boros’ dg asumsi tanpa Squid atau cache server (bukan lokal cache lho)? ya cache di web browser dimatikan saja shg setiap saat akses internet akan selalu mengambil obyek/halaman langsung dari server asal/sumbernya (tapi irit tempat di hardisk lokal, hanya ini keuntungannya). Jelas dari sisi latensi akan naik drastis. Kira2 sudah bisa dibayangkan ya? hi hi hi … (makanya beberapa ISP secara diam2 akan men’transparan’kan cache server dg maksud mau membantu ekstrimis yg ’super boros’ ini tadi, he he he … apa hanya sekedar alasan buat mereka menghemat bw ya?)

Baik skrg masuk peran Squid yg pada dasarnya bersifat ’shared’ obyek lokal dalam konteks 1 domain. Secara garis besar mekanisme kerjanya mirip dg ‘temporary cache’ lokal web browser itu tadi cuma bedanya dipakai bersama dg user yg lain. Yg membedakan dalam kaitannya dg refresh_pattern adl Squid tidak tidak akan ‘bertanya’ validitas obyek jika ternyata ‘umur’nya masih dalam durasi refresh_pattern-nya (default minimum Squid 120 menit atau 2 jam, kalau tidak salah). Jadi jika ‘umur’ obyek sejak di’lahir’kan belum mencapai 2 jam (utk contoh) maka Squid tidak akan mengakses server asal/sumber utk mengambil info ‘umur’nya, dg kata lain obyek akan dianggap masih valid selama durasi waktu tadi (2 jam, misalnya), alias penghematan bw dan peningkatan responsivitas akses.

Kerugian jika refresh_pattern minimum (min) terlalu lama, misalnya kita set 1 hari, jelas jika ternyata dalam waktu kurang dari 1 hari obyek di ujung server asal berubah, di sisi klien dan Squid-nya masih akan tetap dianggap valid, atau dg kata lain, informasinya salah/tidak akurat, lha halaman web-nya memang tidak sama dg yg di server. Bagi web desainer, contoh saja lho tanpa ada masuk diskriminasi, he he he … akan tidak suka krn ada kebutuhan ‘instan’ setiap kali mengubah atau memperbaiki halaman web di ujung server utk keperluan evaluasi (ya jelas tidak akan mau menunggu 1 hari utk melihat perubahannya, ha ha ha … benar ya?). Jadi intinya min refresh_pattern adalah keterangan kapan waktu ‘tersegera’ utk menguji validitas obyek. Jika obyek teruji masih valid, Squid akan mengambil dari lokal cache swap-nya, jika obyek sudah tidak valid ya jelas Squid akan mengambil obyek dari server asal. Sekarang masalahnya, bagaimana jika obyek tidak memiliki ‘umur’ atau info ‘tgl lahir’? (tidak semua web itu memiliki info ini lho, tergantung si web programernya).

Kapan menguji atau mengambil langsung dari server asal obyek ‘tak berumur’ ini, toh validitasnya tidak bisa diuji? Persentase dan nilai maksimum-lah yg akan menentukan (percentage max). Obyek tanpa umur ini tadi akan dianggap valid oleh Squid selama umur minimumnya 50% dari umur maksimumnya, misalnya. Utk contoh 50% 120 akan berarti obyek tanpa umur valid selama ‘umur’nya masih kurang dari 1 jam (50% dari 120 menit). Menurut pengalaman perubahan obyek2 HTTP di internet itu relatif ‘lamban’, maka kebiasaan saya pribadi demi Squid yg ‘agresif’ adalah antara 80% s/d 95% dg nilai maksimum hingga 1 bulan (berapa menit ya, sori lupa) dan utk FTP krn semakin jarang berubah bisa lebih lama lagi bisa hingga 3 bulan atau 6 bulan. Tentunya ini tergantung profil pengguna internet anda lho, hanya contoh ekstrim saja. Jadi saat ‘umum’ maksimum yg sudah didefinisikan di refresh_pattern tercapai, jelas Squid akan ‘menjenguk’ obyek tsb ke asal servernya. Dg asumsi obyek masih sama maka Squid akan mengambil dari loka cache swap-nya. Jika ternyata obyek sudah berbeda, misalnya dari ukuran file atau saat file obyek tsb berbeda, maka Squid akan mengambil dari server tsb.

Opsi override-lastmod dan reload-into-ims kepanjangannya adalah ‘override last modification’ dan ‘reload into if-modified-since’. Override-lastmod akan meng’override’ perubahan yg terjadi di server asal obyek dg mengabaikan validitasnya hingga minimum refresh_pattern-nya tercapai. Efeknya obyek di lokal Squid bisa berbeda dg obyek yg di server asal. Tapi opsi ini masih mengijinkan si user ‘memaksa’ menguji validitasnya dg menekan tomboh ‘reload’ atau ‘refresh’ di web browser. Opsi ini, kalau saya memandangnya ‘agak menipu sedikit’, he he he … Sbg contoh di atas, saya yakin obyek di ujung server sudah berubah walaupun terakhir saya akses baru 10 menit yg lalu (min refresh_pattern=120 menit, misalnya), maka dg menekan tombol ‘reload’ di browser saya akan bisa menguji validitas obyek tsb dg yg di server asal, dan jika ternyata ya benar obyek tsb sudah berubah, jelas Squid akan langsung mengambil obyek lebih baru dari server asal. Jika saya biarkan saja akses ke obyek tsb tanpa menekan tombol ‘reload’ di browser maka mekanisme uji validitas mempergunakan min refresh_pattern akan berlaku biasa. (kadang saya punya pemikiran bgmana jika ada mesin klien yg ‘usil’ membangkitkan ‘reload’ atau ‘refresh’ dg intensif sekali shg Squid kewalahan, apakah bisa DoS semacam ini ya?, he he he … “boys and girls, please don’t try this at home”, ha ha ha).

Opsi reload-into-ims akan mengubah atau memodifikasi ‘umur’ obyek sehingga seakan-akan ‘dilahirkan’ kembali atau ‘direset’. Misalnya saya pernah mengakses suatu obyek suatu obyek 1,5 jam yg lalu, dan saya akses lagi obyek yg sama sekarang, maka ‘umur’ obyek yg sama ini akan dianggap ‘fresh’ atau obyek baru dan sudah tidak berumur 1,5 jam yg lalu. Keuntungan opsi ini adalah mekanisme ‘penyegaran’ umur obyek populer sehingga tidak pernah mjd ‘tua’ hingga nilai percentage dan maksimumnya tercapai, sekali lagi ‘agak menipu’, he he he … Kendali penuh tetap di user utk menekan tombol ‘reload’ atau ‘refresh’ jika tidak yakin obyek ‘fresh’.

Jadi kira2 dan sepemahanan saya mekanisme refresh_pattern Squid spt ini. Utk konfigurasi yg ‘pas’ utk keperluan anda ya silahkan bereksperimen sendiri krn keperluan dan profil user plus kemampuan h/w juga berbeda. Begitu saja, semoga bermanfaat dan masuk akal ya, yg paling penting tidak menambah kebingungan, hi hi hi ….