The refresh_pattern directive controls the disk cache only indirectly. It helps Squid decide whether or not a given request can be a cache hit or must be treated as a miss. Liberal settings increase your cache hit ratio but also increase the chance that users receive a stale response. Conservative settings, on the other hand, decrease hit ratios and stale responses.
The refresh_pattern rules apply only to responses without an explicit expiration time. Origin servers can specify an expiration time with either the Expiresheader, or the Cache-Control: max-age directive.
You can put any number of refresh_pattern lines in the configuration file. Squid searches them in order for a regular expression match. When Squid finds a match, it uses the corresponding values to determine whether a cached response is fresh or stale. The refresh_pattern syntax is as follows:
refresh_pattern [-i] regexp min percent max [options]
For example:
refresh_pattern -i \.jpg$ 30 50% 4320 reload-into-ims
refresh_pattern -i \.png$ 30 50% 4320 reload-into-ims
refresh_pattern -i \.htm$ 0 20% 1440
refresh_pattern -i \.html$ 0 20% 1440
refresh_pattern -i . 5 25% 2880
The regexp parameter is a regular expression that is normally case-sensitive. You can make them case-insensitive with the -i option. Squid checks the refresh_pattern lines in order; it stops searching when one of the regular expression patterns matches the URI.
The min parameter is some number of minutes. It is, essentially, a lower bound on stale responses. A response can’t be stale unless its time in the cache exceeds the minimum value. Similarly, max is an upper limit on fresh responses. A response can’t be fresh unless its time in the cache is less than the maximum time.
Responses that fall between the minimum and maximum are subject to Squid’s last-modified factor(LM-factor) algorithm. For such responses, Squid calculates the response age and the LM-factor and compares it to the percent value. The response age is simply the amount of time passed since the origin server generated, or last validated, the response. The resource age is the difference between the Last-Modified and Date headers. The LM-factor is the ratio of the response age to the resource age.
Figure 7-2 demonstrates the LM-factor algorithm. Squid caches an object that is 3 hours old (based on the Date and Last-Modified headers). With an LM-factor value of 50%, the response will be fresh for the next 1.5 hours, after which the object expires and is considered stale. If a user requests the cached object during the fresh period, Squid returns an unvalidated cache hit. For a request that occurs during the stale period, Squid forwards a validation request to the origin server.
Figure 7-2. Calculating expiration times based on LM-factor
It’s important to understand the order that Squid checks the various values. Here is a simplified description of Squid’s refresh_pattern algorithm:
- The response is stale if the response age is greater than the refresh_pattern max value.
- The response is fresh if the LM-factor is less than the refresh_pattern percent value.
- The response is fresh if the response age is less than the refresh_pattern min value.
- Otherwise, the response is stale.
The refresh_pattern directive also has a handful of options that cause Squid to disobey the HTTP protocol specification. They are as follows:
override-expire
When set, this option causes Squid to check the min value before checking the Expires header. Thus, a non-zero min time makes Squid return an unvalidated cache hit even if the response is preexpired.
override-lastmod
When set, this option causes Squid to check themin value before the LM-factor percentage.
reload-into-ims
When set, this option makes Squid transform a request with a no-cache directive into a validation (If-Modified-Since) request. In other words, Squid adds an If-Modified-Since header to the request before forwarding it on. Note that this only works for objects that have a Last-Modifiedtimestamp. The outbound request retains the no-cache directive, so that it reaches the origin server.
ignore-reload
When set, this option causes Squid to ignore the no-cache directive, if any, in the request.
Sumber: etutorials.org
Baik saya coba jelaskan mekanisme refresh_pattern tapi sepengetahuan saya lho, siapa tahu penjelasannya meleset jauh, he he he … Silahkan dikomentari jika informasinya salah, maaf …. ha ha ha …
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 ….
Halo gan
Ane paling inget soal regular expressionnya, jadi ane terangkan soal itu aja yah …
^http:\/\/apps.facebook.com.*\/
kita break down sebagai berikut:
^ –> matching di awal…. jadi maksudnya, jika ada regex (regular expression) tanpa ^ semisal “*hoho*” maka dia akan match dengan kata “hehoho” juga “hohoho”, tapi kalau ^hoho* maka harus depannya hoho contoh hohohehe atau hohohoho
\/\/–> ini sebenarnya mau ngomong tanda //, cuma kita gak bisa langsung nulis demikian. Kenapa? karena tanda / punya makna khusus. Jadi supaya dianggap sebagai karakter biasa, maka di “escape” dengan\. Jadilah \/\/
tanda * yang mengikuti “com.”, artinya terserah kata apapun mengikuti “apps.facebook.com”, misal “apps.facebook.com/doel” dst
jadi secara lengkap, ini artinya untuk memberikan suatu aturan kapan harus refresh bagi website dari domain facebook.com, lebih khususnya aplikasinya (game misalnya).
ane lupa maknya parameter sisanya, tapi ane bisa artikan secara umum, itu maksudnya agar isi website dari apps.facebook.com dicache selama mungkin dan bahkan mengabaikan permintaan refresh dari user. Inilah yang dimaksud oleh manual si squid sebagai “hal berbahaya” Berbahaya karena ya ini melanggar protokol HTTP yang mengurusi soal browsing.
Semoga membantu