Apache HTTP Sunucusu Sürüm 2.4
Bu belge mod_cache
,
mod_cache_disk
, mod_file_cache
modülleri ve htcacheclean
için bir başvuru kılavuzu niteliğindedir. HTTP sunucusu ve vekil
olarak çalışmada işlemleri hızlandırmak için bilinen sorunlar ve
yanlış yapılandırmalardan kaçınarak Apache HTTPD sunucusunun önbellekleme
özelliklerinin nasıl kullanılacağı açıklanmıştır.
Apache HTTP sunucusu, sunucunun başarımını çeşitli yollarla arttırmak üzere tasarlanmış bir dizi önbellekleme özelliğine sahiptir.
mod_cache
ve destek modülü
mod_cache_disk
akılcı ve HTTP'ye uygun
önbellekleme sağlar. İçeriğin kendisi önbellekte saklanır ve
mod_cache
, RFC2616'nın 13. bölümünde açıklandığı gibi, içeriğin
önbelleklenebilirliğini denetleyen çeşitli HTTP başlıklarının ve
seçeneklerinin tümünü onurlandırmayı hedefler.
Devingen yerel içerik veya vekalet edilen içerik ile ilgilendiğiniz
durumda veya muhtemel bir yavaş disk üzerinde yerel dosyalara
erişimi hızlandırmak ihtiyacında olduğunuz durumda
mod_cache
hem basit hem de karmaşık önbellekleme
yapılandırmalarını hedefler.
mod_file_cache
dosyaların sunucunun başlatılması
sırasında belleğe yüklenmesi ile ilgilenir. Böylece dosyalara
erişim zamanını kısaltabilir, sıkça erişilen dosyaların dosya
tanıtıcılarını kaydedebilir, her istekte diske gitme ihtiyacını
ortadan kaldırır.
Bu belgeden azami yararı sağlayabilmek için temel bir HTTP bilginizin olması ve URL’lerin Dosya Sistemine Eşlenmesi ile İçerik Uzlaşımı belgelerini okumuş olmanız gerekir.
İlgili Modüller | İlgili Yönergeler |
---|---|
HTTP protokolü
RFC2616'nın 13. bölümünde açıklanan satıriçi önbellekleme
mekanizması için yerleşik bir destek içerir ve bunun getirilerinden
yararlanmak için mod_cache
modülü kullanılabilir.
İçeriğin taze olmadığı durumda içeriğin kaybolmasına sebep olan basit iki durumlu anahtar/değer önbelleklemesinin tersine, HTTP önbelleği eskimiş içeriği tutan ve bu eski içeriğin değişip değişmediğini özgün sunucuya soran ve duruma göre onu tekrar taze duruma getiren bir mekanizma içerir.
HTTP önbelleğinde bulunan bir girdi şu üç durumdan birinde olabilir:
İçerik çok eski (tazelik ömründen daha yaşlı) ise bayat sayılır. Bir HTTP önbelleği böyle bir içeriği istemciye sunmadan önce özgün sunucuya bağlanıp bayat içeriğin hala yeterince taze olup olmadığına bakmalıdır. Özgün sunucu, içerik geçersizse yenisini gönderecektir, aksi takdirde, (ideal olanı budur) içeriğin hala geçerli olduğunu belirten bir kod ile yanıt verecektir. İçerik tekrar taze hale gelince süreç kaldığı yerden devam eder.
HTTP protokolü belli koşullar altında önbelleğin bayat içeriği
sunmasına izin vermez. Örneğin, bir içeriği özgün sunucuda tazeleme
çabasının bir 5xx hatasıyla başarısız olması veya başka bir tazeleme
isteğinin henüz sonuçlanmamış olması bu çeşit koşullardandır. Bu
durumlarda yanıta bir Warning
başlığı eklenir.
htcacheclean
elle veya bir artalan süreci
olarak çalıştırılabilir. Böylece önbelleğin boyutunun belirtilen
boyutta veya belirtilen dosya düğümü sayısında kalması sağlanabilir.
Araç içeriği silerken bayat içeriğe öncelik verir.
HTTP önbelleklemesinin çalışması ile ilgili bütün ayrıntılar RFC2616'nın 13. bölümünde bulunabilir.
mod_cache
modülü
CacheQuickHandler
yönergesinin
değerine bağlı olarak iki olası yerde sunucuya bağlanır:
Bu aşama çok erken gerçekleşen bir aşama olup isteğin işlenmesi sırasında isteğin çözümlenmesinin hemen sonrasıdır. İçerik önbellekte mevcutsa hemen sunulur ve geri kalan istek işleme işlemi iptal edilir.
Bu senaryoda önbellek sunucunun önüne vidalanmış gibi davranır.
Sunucuda gerçekleşecek bir dizi işlemin büyük çoğunluğunun yapılmadan geçilmesi nedeniyle bu en yüksek başarımlı kiptir. Bu kip ayrıca, sunucu işlemlerinin kimlik doğrulama ve yetkilendirme aşamalarının da yapılmadan geçilmesini sağlar. Bu bakımdan bu kip seçilirken bu durum dikkate alınmalıdır.
"Authorization" başlığı içeren istekler (örneğin, HTTP Temel
Kimlik Kanıtlaması gibi) mod_cache
bu kipte
çalışırken önbelleğe alınmadıkları gibi önbellekten bir işleme de
sokulmazlar.
Bu aşama geç bir aşama olup, isteğin tamamen işlenmesinin sonrasıdır.
Bu senaryoda önbellek sunucunun arkasına vidalanmış gibi davranır.
Bu kip en esneğidir. Önbelleğin, süzme zincirinin hassas olarak denetlenen bir noktasında oluşması sağlanabilir ve önbelleklenen içerik istemciye gönderilmeden önce süzülüp kişiselleştirilebilir.
URL önbellekte yoksa mod_cache
modülü yanıtı
önbelleğe kaydetme aşamasında süzgeç yığıtına bir
süzgeç ekler ve geri çekilerek normal istek
işlemlerinin devam etmesine izin verir. İçeriğin önbelleklenebilir
olduğu saptanırsa içerik gelecekte sunulmak üzere önbelleğe
kaydedilir, aksi takdirde içerik yok sayılır.
Önbellekteki içerik bayatsa, mod_cache
modülü
isteği bir koşullu istek haline getirir. Özgün
sunucu normal bir yanıt verirse bu yanıt mevcut içeriğin yerine
önbelleklenir. Özgün sunucu bir 304 Not Modified
yanıtı
verirse içerik tekrar taze olarak imlenir ve önbellekteki içerik
süzgeç tarafından kaydedilmeden sunulur.
Bir sanal konak birçok farklı sunucu takma adından biri olarak
bilindiği takdirde UseCanonicalName
yönergesine On
değeri atanmışsa önbellekten sunulan sayfa sayısında büyük bir artış
olduğu görülür. Bunun sebebi içeriği sunan sanal konağın isminin
önbellek anahtarının içinde kullanılmasıdır. Yönergeye
On
değerini atamak suretiyle çok isimli ve rumuzlu sanal
konaklar için farklı önbellek girdileri oluşturulmaz, bunun yerine her
meşru sanal konak için ayrı bir önbellek tutulur.
Önbelleklenmek üzere tasarlanmış iyi biçimli bir içerik tazelik ömrünü
Cache-Control
başlığının max-age
veya
s-maxage
alanlarıyla ya da bir Expires
başlığını içererek bildirmelidir.
Aynı zamanda, özgün sunucunun tanımladığı tazelik ömrü, bir istemci
tarafından istekte bir Cache-Control
başlığı kullanılarak
geçersiz kılınmak istenebilir. Bu durumda hangi tazelik ömrü daha
kısaysa o geçerli olur.
Tazelik ömrü istekte veya yanıtta mevcut değilse öntanımlı bir tazelik
ömrü kullanılır. Öntanımlı tazelik ömrü önbellekli içerik için bir saat
olmakla birlikte CacheDefaultExpire
yönergesi
kullanılarak kolayca değiştirilebilir.
Bir yanıt Expires
başlığını değil de
Last-Modified
başlığını içeriyorsa
mod_cache
tazelik ömrünü CacheLastModifiedFactor
yönergesine
bakarak saptar.
Yerel içerik için, ya da kendi Expires
başlığını
tanımlamayan uzak içerik için tazelik ömrünü max-age
ve
Expires
ekleyerek hassas olarak ayarlamak
için mod_expires
kullanılabilir.
Tazelik ömrünün üst sınırı CacheMaxExpire
yönergesi ile
belirlenebilir.
Önbellekteki içeriğin zaman aşımına uğrayıp bayat hale gelmesi, httpd’nin özgün isteği aktarmak yerine isteği değişikliğe uğratarak şartlı bir istek yapması sonucunu doğurur.
Özgün önbellekli yanıtta bir ETag
başlığı mevcutsa,
mod_cache
modülü özgün sunucuya yapılan isteğe
bir If-None-Match
başlığı ekler.
Özgün önbellekli yanıtta bir Last-Modified
başlığı
mevcutsa, mod_cache
modülü özgün sunucuya yapılan
isteğe bir If-Modified-Since
başlığı ekler. Bunlardan
birinin varlığı isteği koşullu yapar.
Bir koşullu istek özgün sunucu tarafından alındığında, özgün sunucu
ETag
veya Last-Modified
başlığının isteğe
uygun olarak değişip değişmediğine bakmalıdır. Değişmemişse, özgün
sunucu kısa ve öz bir "304 Not Modified" yanıtı ile yanıt vermelidir.
Bunun önbellekteki anlamı şudur: Eskimiş içerik hala tazedir ve içerik
yeni tazelik ömrüne ulaşıncaya kadar sonraki isteklerde
kullanılmalıdır.
İçerik değişmişse, bir şartlı istek yapılmamış gibi içeriğin kendisi sunulur.
Şartlı istekler çifte yarar sağlar. Birinci olarak, böyle bir istek özgün sunucuya yapılıyorsa ve iki içerik de aynıysa bunu saptamak kolay olur ve özkaynağın tamamını aktarma külfetinden kurtulunur.
İkinci olarak, iyi tasarlanmış bir özgün sunucu, koşullu istekler tam
bir yanıt üretmekten önemli ölçüde ucuz olacak şekilde tasarlanmış
olacaktır. Durağan dosyalar için bu genellikle
stat()
veya benzeri bir sistem çağrısıyla dosya
boyutları ve değişiklik zamanına bakmak şeklinde gerçekleşir.
Böylelikle, yerel içeriği bir değişiklik olmadığı takdirde önbellekten
sunmak daha hızlı olacaktır.
Özgün sunucular koşullu istekleri desteklemek için her türlü çabayı göstermelidir. Ancak, koşullu istekler desteklenmiyorsa, özgün sunucu istek koşullu değilmiş gibi yanıt vermeli, önbellek ise, içerik değişmiş ve yani içerik önbelleğe kaydedilmiş gibi yanıt vermelidir. Bu durumda, önbellek basit bir iki durumlu (içerik ya tazedir ya da silinmiş) önbellek gibi davranacaktır.
HTTP önbelleğin tarafından önbelleklenebilecek içerik RFC2616 Section 13.4 Response Cacheability belgesinde tanımlanmış olup, bunlar şöyle özetlenebilir:
CacheEnable
ve CacheDisable
yönergelerine bakınız.CacheIgnoreNoLastMod
yönergesinin kullanımını gerektiren bir durum olmadıkça 200 durum
koduna sahip bir yanıtın "Etag", "Last-Modified" ve "Expires"
başlıklarından birini veya "Cache-Control:" başlığının "max-age" veya
"s-maxage" yönergelerinden birini (en azından) içermesi gerekir.CacheStorePrivate
yönergesinin kullanımını gerektiren bir durum olmadıkça yanıt
"private" değerli bir "Cache-Control:" başlığı içerdiği takdirde
yanıtın içeriği önbelleğe alınmayacaktır.CacheStoreNoStore
yönergesi kullanılmamışsa yanıt
"no-store" değerli bir "Cache-Control:" başlığı içeriyorsa yanıt
içeriği önbelleğe alınmayacaktır.İçerik zamana bağımlıysa ya da istek kısmen bile olsa HTTP uzlaşımıyla
bağdaşmıyorsa önbelleğe alınmamalıdır. Bu içerik önbelleklenemeyeceğini
Cache-Control
başlığını kullanarak sunucuya
bildirmelidir.
İçerik sıkça değişiyorsa, tazelik ömrü dakikalar veya saniyelerle ifade ediliyorsa, içerik yine de önbelleklenebilir. Ancak, tam yanıtların düzenli olarak üretilmemesinin temini için özgün sunucunun koşullu istekleri doğru olarak desteklemesi sağlanmalıdır.
İstemcinin sağladığı istek başlıklarına dayanarak değişen içerik,
Vary
yanıt başlığının akıllıca kullanımıyla
önbelleklenebilir.
Özgün sunucu, istekteki başlık değerlerine dayanarak farklı içeriklerle yanıt vermeye ayarlandığı takdirde, örneğin aynı URL'de farklı dillerde içerik sunmak gibi, HTTP'nin önbellekleme mekanizması aynı URL'de aynı sayfanın değişik sürümlerini önbelleklemeyi mümkün kılar.
Bu özgün sunucu tarafından bir Vary
başlığı eklenerek
yapılır. Bir sayfanın farklı sürümleri arasındaki farkları saptarken
önbellek tarafından hangi başlıkların hesaba katılacağını
Vary
başlığı belirler.
Örneğin, bir yanıt şöyle bir başlık ile alınmışsa,
Vary: negotiate,accept-language,accept-charset
mod_cache
sadece accept-language ve accept-charset
başlıkları özgün istekle eşleşen önbellekli içeriği sunacaktır.
İçeriğin farklı sürümleri yan yana önbelleklenebilir.
mod_cache
modülü Vary
başlığını
kullanarak başlıkta listelenmiş istek başlıklarının uygun değerlerini
saptar ve istemciye hangi sürümle yanıt verileceğine karar verir.
İlgili Modüller | İlgili Yönergeler |
---|---|
mod_cache
modülü önbelleği yönetmek için çeşitli
depolama ortamlarına özgü gerçeklenimleri kullanır. Diske önbellekleme
desteğini mod_cache_disk
sağlar.
Tipik olarak modül şöyle yapılandırılır:
CacheRoot "/var/cache/apache/" CacheEnable disk / CacheDirLevels 2 CacheDirLength 1
En önemlisi önbelleklenen dosyaların yerel olarak saklanması olup işletim sisteminin sağladığı bellekiçi önbelleklemeden de ayrıca faydalanılmış olur. Bu bakımdan, dosyalar disk üzerinde saklansa bile sıkça erişilen dosyalar işletim sistemi sayesinde aslında bellekten sunulmuş olacaklardır.
mod_cache_disk
öğeleri önbellekte saklamak için
istek yapılan URL’nin 22 karakterlik özetini oluşturur. Bu özet, çok
sayıda URL’nin aynı özeti oluşturmaması için konak ismi, protokol,
port ve varsa CGI argümanlarından başka Vary
başlığında
tanımlı elemanlardan oluşur.
Özeti oluşturan karakterler 64 karakterlik bir karakter kümesinden
seçildiğinden oluşturulması olası farklı özet sayısı 64^22’dir.
Örneğin, bir URL’nin xyTGxSMO2b68mBCykqkp1w
gibi bir
özeti olabilir. Bu özet, bu URL ile erişilen dosyalar önbellek içinde
saklanırken dosya ismi öneki olarak kullanılır. Ancak bununla
yetinilmez ve içerik CacheDirLevels
ve CacheDirLength
yönergelerinin
değerlerine göre önce dizinlere ayrılır.
CacheDirLevels
yönergesi kaç alt seviye dizin olacağını ve CacheDirLength
her dizinde kaç
karakter olacağını belirler. Örneğin, yukarıdaki
özete sahip bir dosyanın isminin başına yukarıdaki yapılandırma
örneğine uygun olarak
/var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w
gibi bir önek
getirilebilirdi.
Bu tekniğin asıl amacı belli bir dizin içinde bulunabilecek
dosyaların ve alt dizinlerin sayısını düşük tutmaktır. Bu sayının
büyük olması çoğu işletim sisteminde başarımın düşmesine sebep olur.
CacheDirLength
yönergesi "1" değeriyle kullanıldığında her dizin altında en fazla 64
alt dizin veya dosya açılabilir. "2" değeriyle kullanıldığında ise bu
sayı 64^2’ye yükselir ve böyle artarak gider. İyi bir sebebiniz
olmadıkça CacheDirLength
için değer olarak
"1" belirtmenizi öneririz.
CacheDirLevels
yönergesine atanacak değer önbellekte saklamayı düşündüğünüz olası
dosya sayısı ile ilgilidir. Yukarıdaki örnekte olduğu gibi "2"
değerini belirtirseniz, toplamda en fazla 4096 dizin oluşturulabilir.
1 milyon dosyanın önbelleklendiği bir durumda bu, her dizinde yaklaşık
olarak 245 önbelleklenmiş URL demektir.
Her URL için önbellekte en az iki dosya saklanır. Biri genellikle URL hakkındaki temel verilerden oluşan ".header" dosyasıdır, diğeri ise sunulacak içeriğin bire bir kopyası olan ".data" dosyasıdır.
"Vary" başlığı üzerinden içeriğin uzlaşıldığı durumda URL için bir ".vary" dizini oluşturulur. Bu dizin her biri farklı bir uzlaşıma ait çok sayıda ".data" dosyası içerebilir.
mod_cache_disk
zaman aşımına uğrayan önbellekli
içeriği silse de önbelleğin toplam boyu ve ne kadar boş bellek kaldığı
hakkında bilgi vermez.
Bunun yerine httpd önbellek içeriğini düzenli aralıklarla
temizleyebilmeniz için htcacheclean
adında bir araç
içerir. Önbellek için azami ne kadar yer kullanılacağının ve bunun
üzerinde htcacheclean
’i hangi sıklıkta
çalıştırılacağının tespiti biraz karmaşık bir işlem olup uygun değerler
genellikle deneme yanılma yoluyla bulunur.
htcacheclean
iki işlem kipine sahiptir. Kalıcı bir
artalan süreci olarak çalışabileceği gibi cron üzerinden belli
aralıklarla da çalıştırılabilir. Çok büyük (onlarca GB) önbelleklerde
htcacheclean
’in işini bitirmesi 1 saatten fazla
sürebileceğinden, cron ile çalıştırma durumunda aynı anda birden fazla
kopyanın çalışıyor durumda olmaması için
htcacheclean
’in çalıştırılma aralığını iyi
belirlemek gerekir.
Ayrıca, htcacheclean
için uygun bir "nice" seviyesi
seçilmesi önerilr. Böylece, sunucu çalışırken aracın ölçüsüz disk g/ç
yapmasına sebebiyet verilmemiş olur.
Şekil 1:
Önbelleğin büyümesi ve düzenli aralıklarla temizlenmesi.
mod_cache_disk
ne kadar bellek kullanıldığı hakkında
bilgi vermediğinden, htcacheclean
'in bir temizliğin
ardından yeterli bir büyüme alanı kalacak şekilde yapılandırılması
temin edilmelidir.
mod_cache_socache
modülünü kullanarak,
mod_cache
çeşitli gerçeklenimlerden (diğer adıyla:
"sağlayıcılar"dan) gelen veriyi önbellekleyebilir.
mod_socache_memcache
modülü kullanılarak, örneğin,
artalan saklama mekanizması olarak
memcached kullanıldığı
söylenebilir.
Genelde modül şöyle yapılandırılır:
CacheEnable socache / CacheSocache memcache:memcd.example.com:11211
İlave memcached
sunucular
CacheSocache memcache:
satırının ardına virgüllerle
ayrılarak eklenebilir:
CacheEnable socache / CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
Bu biçim diğer mod_cache_socache
sağlayıcıları için de kullanılabilir:
CacheEnable socache / CacheSocache shmcb:/path/to/datafile(512000)
CacheEnable socache / CacheSocache dbm:/path/to/datafile
İlgili Modüller | İlgili Yönergeler |
---|---|
Apache HTTP sunucusu, SSL oturumları, kimlik doğrulama bilgileri gibi önbelleklenebilen özel bilgiler için socache arayüzü içinde düşük seviyeli bir paylaşımlı nesne önbelleğine sahiptir.
Her gerçeklenime uygun ek modüller de sağlanmıştır:
mod_socache_dbm
mod_socache_dc
mod_socache_memcache
mod_socache_shmcb
İlgili Modüller | İlgili Yönergeler |
---|---|
mod_authn_socache
modülü kimlik doğrulama araçlarının
yükünün hafifletilmesini, kimlik doğrulama sonucunun önbelleklenmesini
sağlar.
İlgili Modüller | İlgili Yönergeler |
---|---|
mod_ssl
modülü, oturum önbelleği ve önbellek
zımbalaması sağlamak için socache
arayüzünü kullanır.
İlgili Modüller | İlgili Yönergeler |
---|---|
Dosya sisteminin yavaş olabildiği veya dosya tanıtıcılarının kullanımının pahalıya mal olduğu sistemlerde, sunucunun başlatılması sırasında dosyaların belleğe yüklenmesi seçeneği vardır.
Dosyaların açılmasının yavaş olduğu sistemlerde, dosyaların sunucunun başlatılması sırasında açılması ve dosya tanıtıcısını önbelleklenmesi seçeneği vardır. Bu seçeneklerin duruk dosyalara erişimin yavaş olduğu sistemlere de bir yardımı olabilir.
Bir dosyanın açılması işlemi, özellikle de ağ dosya sistemlerinde bulunan dosyalar için önemli bir gecikme kaynağı olabilir. Önbellekte, çok sunulan dosyaların kendilerinin değil, açık dosya tanıtıcılarının saklanması httpd’yi bu tür gecikmelerden koruyabilir. httpd’de tek türde dosya tanıtıcı önbelleklemesi yapılabilmektedir.
CacheFile
yönergesi ilehttpd’de mevcut önbelleklemenin en temel şekli
mod_file_cache
tarafından sağlanan dosya tanıtıcı
önbelleklemesidir. Bu önbellek türü dosyaların kendilerini değil açık
dosya tanıtıcılarının bir listesini saklar. Dosyaların bu anlamda
önbelleklenmesi, CacheFile
yönergesi yapılandırma dosyasında belirtilerek
sağlanabilir.
CacheFile
yönergesi
belirtilen dosyanın httpd başlatıldığında açılmasını ve dosya için
yapılan sonraki her istekte bu dosya tanıtıcısının kullanılmasını
sağlar.
CacheFile /usr/local/apache2/htdocs/index.html
Büyük miktarda dosyayı bu anlamda önbelleklemeyi tasarlıyorsanız işletim sisteminizin açık dosya tanıtıcılarının sayısı ile ilgili sınırlamasını uygun bir değere ayarlamanız gerekebilir.
CacheFile
yönergesini
kullandığınız takdirde dosya içeriğindeki değişiklikleri anında
isteğe yansıtamazsınız. httpd dosyayı ilk başlatıldığındaki haliyle
sunar.
Eğer httpd çalışırken dosya silinmişse httpd ilk başlatıldığındaki haline ilişkin dosya tanıtıcıyı sağlamaya ve dolayısıyla dosya içeriğini sunmaya devam edecektir. Yani, dosya silinmiş ve artık dosya sisteminde görünmüyor olsa bile httpd durdurulup dosya tanıtıcıları kapanmadıkça dosyaların silinmesiyle açılan yer serbest kalmayacaktır.
İçeriğin sistem belleğinden sunulması içerik sunmanın evrensel olarak en hızlı yoludur. Dosyaların bir disk denetleyiciden okunması ya da daha kötüsü uzak bir ağdan okunması bellekten okumayla karşılaştırılamayacak ölçüde yavaş işlemlerdir. Disk denetleyiciler genellikle fiziksel süreçleri denetlerler. Ağ erişimi ise band genişliği sınırlamalarından etkilenir. Halbuki bellek erişimi sadece nano saniyeler mertebesinde gerçekleşir.
Sistem belleği en pahalı saklama ortamı olması sebebiyle en verimli şekilde kullanımı önemlidir. Dosyaları sistem belleğinde saklamakla sistemin kullanabileceği bellek miktarını azaltmış olursunuz. İşletim sistemi önbelleklemesinde göreceğiniz gibi bu öyle basit bir konu değildir. httpd’nin kendi kullandığı belleğin bir kısmını önbellek olarak ayırırken çok fazla bellek kullanmamak önemlidir. Aksi takdirde işletim sistemi belleğin yetmediği noktada belleği diske takaslayacağından istenen başarım artışı sağlanamayacaktır.
Günümüz iştetim sistemlerinin hemen hemen tamamında bellek içi dosya/veri saklama işlemlerini çekirdek yönetir. Bu güçlü bir özelliktir ve işletim sistemlerinin büyük çoğunluğu bunu böyle yapar. Örneğin, Linux’ta bir dosyanın ilk defa okunduğunda ve ikinci kez okunduğunda işlemcinin ne kadar meşgul edildiğine bakalım:
colm@coroebus:~$ time cat testfile > /dev/null
real 0m0.065s
user 0m0.000s
sys 0m0.001s
colm@coroebus:~$ time cat testfile > /dev/null
real 0m0.003s
user 0m0.003s
sys 0m0.000s
Küçük bir dosya için bile okuma süresi bakımından büyük fark ortaya çıkmaktadır. Bunun sebebi çekirdeğin dosya içeriğini bellek daha güncel amaçlar için lazım olana dek bellek içinde saklamasıdır.
Sisteminizde yeterince yedek bellek olduğundan eminseniz, bu önbellekte daha fazla dosya saklanacağından emin olabilirsiniz. Bundan, önbelleğin sistem belleğinde verimli biçimde tutulması için httpd’de ek bir yapılandırmaya gidilmesinin gerekmediği sonucu çıkarılabilir.
Bundan başka, işletim sistemi dosyaların değiştiği ve silindiği zamanları bildiğinden bu tür dosyaların içerikleri gerektiğinde önbellekten kendiliğinden silinmiş olur. Bellek içinde dosya saklarken dosyaların değiştirilme zamanlarını bilme olanağı olmadığından bu durum httpd’ye büyük yarar sağlar.
İşletim sisteminin dosyaların önbelleklenmesi için sağladığı bunca yarara ve başarım artışına karşın bellek içinde dosya önbelleklemenin httpd tarafından yerine getirilmesinin daha iyi olacağı bazı durumlar vardır.
MMapFile
yönergesi ilemod_file_cache
modülü, bir durağan dosyanın
içeriğini sunucunun başlatılması sırasında (mmap sistem çağrısıyla)
belleğe eşlenmesini mümkün kılmak için MMapFile
yönergesini sağlar.
httpd bu dosyaya gelecek sonraki istekler için dosyanın bellekiçi
içeriğini kullanacaktır.
MMapFile /usr/local/apache2/htdocs/index.html
CacheFile
yönergesinde olduğu gibi bu dosyalarda httpd başlatıldıktan sonra
yapılacak bir değişiklikten httpd’nin haberi olmayacaktır.
MMapFile
yönergesi
ayırdığı belleğin toplam miktarı ile ilgilenmez, dolayısıyla
yönergenin aşırı kullanımından kaçınmalısınız. httpd’nin çocuk
süreçlerinin her biri bu belleğin kendilerine ait birer kopyasını
yapacağından belleğe eşlenen dosyaların çok yer kaplamaması büyük
önem taşımaktadır; aksi takdirde işletim sistemi belleği diske
takaslayacağından beklenen fayda sağlanamayacaktır.
CacheQuickHandler
yönergesine On
değerinin atandığı öntanımlı durumda
mod_cache
kullanımı, daha çok sunucunun önüne
vidalanmış önbelleklemeli bir karşı vekile sahip olmak gibidir. Özgün
sunucunun bir harici önbellekmiş gibi sorgulanmasını gerektirmeyen tüm
istekler önbellekleme modülü tarafından karşılanacaktır. Bu durum
httpd'nin güvenlik modelini büyük ölçüde değiştirir.
Olası .htaccess
dosyalarının dosya sisteminin tamamında
taranması çok pahalı bir işlem olduğundan mod_cache
,
(işlemi hızlandırmak için) önbelleğe almanın temel amacını kısmen
gözardı ederek, önbellekteki içeriğin sunumu için gerekli
yetkilendirmenin olup olmadığı konusunda bir karar üretmez. Başka bir
deyişle, eğer mod_cache
bir kısım içeriği önbelleğe
almışsa içerik zaman aşımına uğramadığı sürece bu içerik önbellekten
sunulacaktır.
Örneğin, yapılandırmanız bir özkaynağa IP adresine göre erişime izin
veriyorsa bu içeriğin önbelleğe alınmayacağından emin olmalısınız.
Bunu CacheDisable
yönergesini veya mod_expires
modülünü kullanarak
yapabilirsiniz. Bunu yapmaz, olayı kendi haline bırakırsanız
mod_cache
bir karşı vekil gibi çalışarak sunulan her
içeriği önbelleğe alacak ve hangi IP adresinden gelirse gelsin her
istemciye bunu sunacaktır.
CacheQuickHandler
yönergesine Off
atandığı takdirde, istek işleme
aşamalarının tamamı yerine getirilir ve güvenlik modeli değişmeden
kalır.
Son kullanıcılarıın isteklerine önbellekten hizmet sunulduğundan önbelleğin kendisi içerikle etkileşime geçmek isteyenlerin veya içeriği tahrif etmek isteyenlerin hedefi haline gelebilir. httpd’yi çalıştıran kullanıcı tarafından her zaman önbelleğe yazılabileceğini akıldan çıkarmamak önemlidir. Bu durumda alışılmışın tersine tüm içeriğin Apache kullanıcısı tarafından yazılamamasının sağlanması önerilir.
Eğer Apache kullanıcısı, örneğin bir CGI sürecindeki açık nedeniyle
tehlikeye atılırsa, önbellek hedef alınabilir.
mod_cache_disk
kullanılırken önbellekteki bir öğeyi
değiştirmek veya önbelleğe yeni bir öğe eklemek görece daha
kolaydır.
Bu risk, Apache kullanıcısını kullanan diğer saldırı türleriyle
karşılaştırıldığında daha yüksektir. mod_cache_disk
kullanıyorsanız şunları aklınızdan çıkarmayın: (1) httpd güvenlik
güncellemelerini takip edin ve sunucunuzu buna göre güncelleyin. (2)
Mümkünse suEXEC kullanarak CGI süreçlerini
Apache kullanıcısı olmayan bir kullanıcının aidiyetinde çalıştırın.
httpd bir önbellekli vekil sunucu olarak çalıştığında önbellek zehirlenmesi adı verilen sorunla karşılaşılma olasılığı vardır. Önbellek zehirlenmesi, vekil sunucunun özgün sunucudan yanlış (ve genellikle istenmeyen) içerik almasına sebep olan bir saldırı türünü betimlemek için yaygın olarak kullanılan bir terimdir.
Örneğin httpd’nin çalıştığı sistemin kullandığı DNS sunucuları DNS önbellek zehirlenmesinden etkilenebilecek durumdaysa, bir saldırgan httpd’nin istekleri almak için başvuracağı kaynak sunucunun yerini değiştirebilir. Diğer bir örnek, HTTP istek kaçakçılığı adı verilen bir saldırı türüdür.
Bu belge HTTP istek kaçakçılığını derinliğine incelenmesi için uygun yer değildir (böyle kaynaklara arama motorunuzla erişebilirsiniz). Bununla birlikte, vekil tarafından kaynak sunucudan alınan içeriği tamamen denetim altına almak amacıyla kaynak sunucudaki bir açığı istismar etmeye yönelik bir dizi istek yapılabileceğinin olasılık dahilinde olduğunu bilmenizde yarar vardır.
Vary mekanizması aynı URL'nin çok sayıda sürümünün yan yana
önbelleklenmesini mümkün kılar. İstemci tarafından sağlanan başlık
değerlerine bağlı olarak, önbellek istemciye gönderilecek doğru yanıtı
bulacaktır. Normal kullanımda olası değerlerin çok geniş olduğunun
bilindiği durumda bir başlığı (örn, User-Agent
)
değişikliğe uğratma çabası bu mekanizmayı bir sorun haline getirebilir.
Sitenin tanınırlığına bağlı olarak aynı URL'nin binlerce hatta
milyonlarca önbellek girdisi oluşabilir ve bunlar önbellekteki diğer
girdilerin yerini alabilir.
Diğer yandan, belli bir özkaynağın URL'sinin her istekte
değiştirilmesi ihtiyacı ortaya çıkabilir. Bu normalde URL dizgesine bir
"cachebuster" dizgesi eklenerek yapılır. Bu içerik sunucu tarafından
anlamlı bir tazelik ömrüyle önbelleklenebilir olarak imlenmişse bu
girdiler kısa zamanda önbellekteki meşru girdilerin yerini alabilir.
mod_cache
modülü bunun önlenmesi için CacheIgnoreURLSessionIdentifiers
yönergesine sahipse de bu yönerge, yoldaki vekillerin veya tarayıcı
önbelleklerinin aynı hizmet reddi saldırısına maruz kalmamaları için
dikkatle kullanılmalıdır.