Apache’de Başarımın Arttırılması

Mevcut Diller: en | + fr | + ko | + tr

+ + +

Apache 2.x, esneklik, taşınabilirlik ve başarım arasında bir denge + sağlamak üzere tasarlanmış genel amaçlı bir HTTP sunucusudur. Başka + sunucularla kıyaslama denemelerinde öne geçmek üzere tasarlanmamış + olsa da Apache 2.x gerçek yaşamda karşılaşılan pek çok durumda oldukça + yüksek bir başarıma ulaşacak yetenektedir.

+ +

Apache 1.3 ile karşılaştırıldığında 2.x sürümleri toplam veri hızını + ve ölçeklenebilirliği arttırmak için pek çok en iyileme seçeneği + içerir. Bu iyileştirmelerin pek çoğu zaten öntanımlı olarak etkin + olmakla birlikte derleme ve kullanım sırasında başarımı önemli ölçüde + etkileyebilen yapılandırma seçenekleri de mevcuttur. Bu belgede, bir + Apache 2.x kurulumunda sunucu yöneticisinin sunucunun başarımını + arttırmak amacıyla yapılandırma sırasında neler yapabileceğinden + bahsedilmiştir. Bu yapılandırma seçeneklerinden bazıları, httpd’nin + donanımın ve işletim sisteminin olanaklarından daha iyi + yararlanabilmesini sağlarken bir kısmı da daha hızlı bir sunum için + yöneticinin işlevsellikten ödün verebilmesini olanaklı kılar.

+ +

Donanım ve İşletim Sistemi ile İlgili Konular
Çalışma Anı Yapılandırması ile İlgili Konular
Derleme Sırasında Yapılandırma ile İlgili Konular
Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi

Ayrıca bakınız:

Yorumlar

Donanım ve İşletim Sistemi ile İlgili Konular

+ + + +

HTTP sunucusunun başarımını etkileyen en önemli donanım bellektir + (RAM). Bir HTTP sunucusu asla takaslama yapmamalıdır. Çünkü takaslama, + kullanıcının "yeterince hız" umduğu noktada sunumun gecikmesine sebep + olur. Böyle bir durumda kullanıcılar yüklemeyi durdurup tekrar + başlatma eğilimindedirler; sonuçta yük daha da artar. MaxRequestWorkers yönergesinin değerini + değiştirerek takaslamaya sebep olabilecek kadar çok çocuk süreç + oluşturulmasını engelleyebilirsiniz ve böyle bir durumda bunu mutlaka + yapmalısınız. Bunun için yapacağınız işlem basittir: top + benzeri bir araç üzerinden çalışan süreçlerinizin bir listesini alıp + Apache süreçlerinizin ortalama büyüklüğünü saptayıp, mevcut bellekten + bir kısmını diğer süreçler için ayırdıktan sonra kalan miktarı bu + değere bölerseniz yönergeye atayacağınız değeri bulmuş olursunuz.

+ +

Donanımın diğer unsurları için kararı siz verin: Daha hızlı işlemci, + daha hızlı ağ kartı, daha hızlı disk; daha hızlının ne kadar hızlı + olacağını deneyimlerinize bağlı olarak tamamen sizin ihtiyaçlarınız + belirler.

+ +

İşletim sistemi seçimi büyük oranda yerel ilgi konusudur. Fakat yine + de, genelde yararlılığı kanıtlanmış bazı kurallar bu seçimde size + yardımcı olabilir:

+ +

+
Seçtiğiniz işletim sisteminin (çekirdeğin) en son kararlı + sürümünü çalıştırın. Bir çok işletim sistemi, son yıllarda TCP + yığıtları ve evre kütüphaneleri ile ilgili belirgin iyileştirmeler + yapmışlar ve yapmaktadırlar.
+
+
İşletim sisteminiz sendfile(2) sistem çağrısını + destekliyorsa bunun etkinleştirilebildiği sürümün kurulu olması + önemlidir. (Örneğin, Linux için bu, Linux 2.4 ve sonraki sürümler + anlamına gelirken, Solaris için Solaris 8’den önceki sürümlerin + yamanması gerektirdiği anlamına gelmektedir.) + sendfile işlevinin desteklendiği sistemlerde Apache 2 + duruk içeriği daha hızlı teslim etmek ve işlemci kullanımını + düşürmek amacıyla bu işlevselliği kullanacaktır.
+

+ +

Çalışma Anı Yapılandırması ile İlgili Konular

İlgili Modüller	İlgili Yönergeler
`mod_dir` `mpm_common` `mod_status`	`AllowOverride` `DirectoryIndex` `HostnameLookups` `EnableMMAP` `EnableSendfile` `KeepAliveTimeout` `MaxSpareServers` `MinSpareServers` `Options` `StartServers`

+ + + + + +

`HostnameLookups` ve DNS ile ilgili diğer konular

+ + + +

Apache 1.3 öncesinde, HostnameLookups yönergesinin öntanımlı değeri + On idi. İstek yerine getirilmeden önce bir DNS sorgusu + yapılmasını gerektirmesi sebebiyle bu ayarlama her istekte bir + miktar gecikmeye sebep olurdu. Apache 1.3’ten itibaren yönergenin + öntanımlı değeri Off yapılmıştır. Eğer günlük + dosyalarınızda konak isimlerinin bulunmasını isterseniz, Apache ile + birlikte gelen logresolve programını + kullanabileceğiniz gibi günlük raporlarını çözümleyen Apache ile + gelmeyen programlardan herhangi birini de kullanabilirsiniz.

+ +

Günlük dosyaları üzerindeki bu işlemi sunucu makinesi dışında + günlük dosyasının bir kopyası üzerinde yapmanızı öneririz. Aksi + takdirde sunucunuzun başarımı önemli ölçüde etkilenebilir.

+ +

Allow veya + Deny + yönergelerinde IP adresi yerine bir konak veya alan ismi + belirtirseniz, iki DNS sorguluk bir bedel ödersiniz (biri normal, + diğeri IP taklidine karşı ters DNS sorgusu). Başarımı en iyilemek + için bu yönergelerde mümkün olduğunca isim yerine IP adreslerini + kullanınız.

+ +

HostnameLookups + yönergelerinin <Location "/server-status"> gibi + bölüm yönergelerinin içinde de yer alabileceğini unutmayın. Bu gibi + durumlarda DNS sorguları sadece istek kuralla eşleştiği takdirde + yapılacaktır. Aşağıdaki örnekte .html ve + .cgi dosyalarına yapılan istekler hariç DNS sorguları + iptal edilmektedir:

+ +

HostnameLookups off
+<Files ~ "\.(html|cgi)$">
+  HostnameLookups on
+</Files>

+ + +

Yine de bazı CGI’lerin DNS isimlerine ihtiyacı olursa bu CGI’lerin + bu ihtiyaçlarına yönelik olarak gethostbyname çağrıları + yapabileceğini gözardı etmeyiniz.

+ + + +

`FollowSymLinks` ve + `SymLinksIfOwnerMatch`

+ + + +

URL uzayınızda geçerli olmak üzere bir Options + FollowSymLinks yoksa veya Options + SymLinksIfOwnerMatch yönergeleri varsa, Apache her sembolik + bağın üzerinde bazı sınamalar yapmak için ek bir sistem çağrısından + başka istenen her dosya için de ayrı bir çağrı yapacaktır.

+ +

DocumentRoot "/siteler/htdocs"
+<Directory />
+  Options SymLinksIfOwnerMatch
+</Directory>

+ + +

Bu durumda /index.html için bir istek yapıldığında + Apache, /siteler, /siteler/htdocs ve
+ /siteler/htdocs/index.html üzerinde + lstat(2) çağrıları yapacaktır. lstat + sonuçları önbelleğe kaydedilmediğinden bu işlem her istekte + yinelenecektir. Amacınız gerçekten sembolik bağları güvenlik + açısından sınamaksa bunu şöyle yapabilirsiniz:

+ +

DocumentRoot "/siteler/htdocs"
+<Directory "/">
+  Options FollowSymLinks
+</Directory>
+
+<Directory "/siteler/htdocs">
+  Options -FollowSymLinks +SymLinksIfOwnerMatch
+</Directory>

+ + +

Böylece DocumentRoot altındaki + dosyalar için fazladan bir çağrı yapılmasını engellemiş olursunuz. + Eğer bazı bölümlerde Alias, RewriteRule gibi yönergeler üzerinden belge kök + dizininizin dışında kalan dosya yollarına sahipseniz benzer + işlemleri onlar için de yapmalısınız. Sembolik bağ koruması yapmamak + suretiyle başarımı arttırmak isterseniz, FollowSymLinks + seçeneğini her yerde etkin kılın ve + SymLinksIfOwnerMatch seçeneğini asla + etkinleştirmeyin.

+ + + +

`AllowOverride`

+ + + +

Genellikle .htaccess dosyaları üzerinden yapıldığı + gibi URL uzayınızda geçersizleştirmelere izin veriyorsanız, Apache + her dosya bileşeni için bu .htaccess dosyalarını açmaya + çalışacaktır.

+ +

DocumentRoot "/siteler/htdocs"
+<Directory "/">
+  AllowOverride all
+</Directory>

+ + +

Bu durumda /index.html sayfasına yapılan bir istek için + Apache, /.htaccess, /siteler/.htaccess ve + /siteler/htdocs/.htaccess dosyalarını açmaya + çalışacaktır. Çözüm Options FollowSymLinks durumunun + benzeridir; başarımı arttırmak için dosya sisteminizin her yerinde + AllowOverride None olsun.

+ + + +

Dil Uzlaşımı

+ + + +

Başarımı son kırıntısına kadar arttırmak istiyorsanız, mümkünse + içerik dili uzlaşımı da yapmayın. Dil uzlaşımından yararlanmak + isterken büyük başarım kayıplarına uğrayabilirsiniz. Böyle bir + durumda sunucunun başarımını arttırmanın tek bir yolu vardır.

+ +

DirectoryIndex index

+ + +

Yukarıdaki gibi bir dosya ismi kalıbı kullanmak yerine, aşağıdaki + gibi seçenekleri tam bir liste halinde belirtin:

+ +

DirectoryIndex index.cgi index.pl index.shtml index.html

+ + +

Buradaki sıralama öncelik sırasını belirler; yani, + öncelikli olmasını istediğiniz seçeneği listenin başına + yazmalısınız.

+ +

İstenen dosya için MultiViews kullanarak dizini + taratmak yerine, gerekli bilgiyi tek bir dosyadan okutmak suretiyle + başarımı arttırabilirsiniz. Bu amaçla türeşlem + (type-map) dosyaları kullanmanız yeterli olacaktır.

+ +

Sitenizde içerik dili uzlaşımına gerek varsa, bunu Options + MultiViews yönergesi üzerinden değil, türeşlem dosyaları + kullanarak yapmayı deneyin. İçerik dili uzlaşımı ve türeşlem + dosyalarının oluşturulması hakkında daha ayrıntılı bilgi edinmek + için İçerik Uzlaşımı + belgesine bakınız.

+ + + +

Bellek Eşlemleri

+ + + +

Apache’nin SSI sayfalarında olduğu gibi teslim edilecek dosyanın + içeriğine bakma gereği duyduğu durumlarda, eğer işletim sistemi + mmap(2) ve benzerlerini destekliyorsa çekirdek normal + olarak dosyayı belleğe kopyalayacaktır.

+ +

Bazı platformlarda bu belleğe eşleme işlemi başarımı arttırsa da + başarımın veya httpd kararlılığının zora girdiği durumlar + olabilmektedir:

+ +

+
Bazı işletim sistemlerinde işlemci sayısı artışına bağlı + olarak, mmap işlevi read(2) kadar iyi + ölçeklenmemiştir. Örneğin, çok işlemcili Solaris sunucularda + mmap iptal edildiği takdirde içeriği sunucu + tarafından işlenen dosyalar üzerinde bazen daha hızlı işlem + yapılabilmektedir.
+
+
Belleğe kopyalanacak dosya NFS üzerinden bağlanan bir dosya + sistemindeyse ve dosya başka bir NFS istemcisi makine tarafından + silinmiş veya dosyanın boyutu değiştirilmişse sunucunuz dosyaya + tekrar erişmeye çalıştığında bir hata alabilecektir.
+

+ +

Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriği + sunucu tarafından işlenecek dosyaların belleğe kopyalanmaması için + yapılandırmanıza EnableMMAP off satırını ekleyiniz. + (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen + yönergelerdendir.)

+ + + +

`sendfile`

+ + + +

Apache’nin duruk dosyalarda olduğu gibi teslim edilecek dosyanın + içeriğine bakmadığı durumlarda, eğer işletim sistemi + sendfile(2) desteğine sahipse çekirdek normal olarak bu + desteği kullanacaktır.

+ +

Bazı platformlarda sendfile kullanımı, okuma ve yazma + işlemlerinin ayrı ayrı yapılmamasını sağlasa da + sendfile kullanımının httpd kararlılığını bozduğu bazı + durumlar sözkonusudur:

+ +

+
Bazı platformlar derleme sisteminin saptayamadığı bozuk bir + sendfile desteğine sahip olabilir. Özellikle + derleme işleminin başka bir platformda yapılıp + sendfile desteği bozuk bir makineye kurulum + yapıldığı durumlarda bu desteğin bozuk olduğu + saptanamayacaktır.
+
+
Çekirdek, NFS üzerinden erişilen ağ dosyalarını kendi önbelleği + üzerinden gerektiği gibi sunamayabilir.
+

+ +

Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriğin + sendfile desteğiyle teslim edilmemesi için + yapılandırmanıza EnableSendfile off satırını ekleyiniz. + (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen + yönergelerdendir.)

+ + + +

Süreç Oluşturma

+ + + +

Apache 1.3 öncesinde MinSpareServers, MaxSpareServers ve StartServers ayarları, başka sunucularla kıyaslama + denemelerinde olağanüstü kötü sonuçlar alınmasına sebep olmaktaydı. + Özellikle uygulanan yükü karşılamaya yetecek sayıda çocuk süreç + oluşturulması aşamasında Apache’nin elde ettiği ivme bunlardan + biriydi. Başlangıçta StartServers yönergesiyle belli sayıda süreç + oluşturulduktan sonra her saniyede bir tane olmak üzere MinSpareServers sayıda çocuk süreç + oluşturulmaktaydı. Örneğin, aynı anda 100 isteğe yanıt vermek için + StartServers + yönergesinin öntanımlı değeri olarak başta 5 süreç + oluşturulduğundan kalan süreçler için 95 saniye geçmesi gerekirdi. + Sık sık yeniden başlatılmadıklarından dolayı gerçek hayatta + sunucuların başına gelen de buydu. Başka sunucularla kıyaslama + denemelerinde ise işlem sadece on dakika sürmekte ve içler acısı + sonuçlar alınmaktaydı.

+ +

Saniyede bir kuralı, sunucunun yeni çocukları oluşturması sırasında + sistemin aşırı meşgul duruma düşmemesi için alınmış bir önlemdi. + Makine çocuk süreç oluşturmakla meşgul edildiği sürece isteklere + yanıt veremeyecektir. Böylesi bir durum Apache’nin başarımını + kötüleştirmekten başka işe yaramayacaktır. Apache 1.3’te saniyede + bir kuralı biraz esnetildi. Yeni gerçeklenimde artık bir süreç + oluşturduktan bir saniye sonra iki süreç, bir saniye sonra dört + süreç oluşturulmakta ve işlem, saniyede 32 çocuk süreç oluşturulur + duruma gelene kadar böyle ivmelenmektedir. Çocuk süreç oluşturma + işlemi MinSpareServers + değerine ulaşılınca durmaktadır.

+ +

Bu, MinSpareServers, + MaxSpareServers ve + StartServers ayarlarıyla + oynamayı neredeyse gereksiz kılacak kadar iyi sonuçlar verecek gibi + görünmektedir. Saniyede 4 çocuktan fazlası oluşturulmaya + başlandığında hata günlüğüne bazı iletiler düşmeye başlar. Bu + iletilerin sayısı çok artarsa bu ayarlarla oynama vakti gelmiş + demektir. Bunun için mod_status çıktısını bir + kılavuz olarak kullanabilirsiniz.

+ +

Süreç oluşturmayla ilgili olarak süreç ölümü MaxConnectionsPerChild değeri ile + sağlanır. Bu değer öntanımlı olarak 0 olup, çocuk süreç + başına istek sayısının sınırsız olduğu anlamına gelir. Eğer + yapılandırmanızda bu değeri 30 gibi çok düşük bir + değere ayarlarsanız bunu hemen kaldırmak zorunda kalabilirsiniz. + Sunucunuzu SunOS veya Solaris’in eski bir sürümü üzerinde + çalıştırıyorsanız bellek kaçaklarına sebep olmamak için bu değeri + 10000 ile sınırlayınız.

+ +

Kalıcı bağlantı özelliğini kullanıyorsanız, çocuk süreçler zaten + açık bağlantılardan istek beklemekte olacaklardır. KeepAliveTimeout yönergesinin öntanımlı + değeri 5 saniye olup bu etkiyi en aza indirmeye yönelik + süredir. Burada ağ band genişliği ile sunucu kaynaklarının kullanımı + arasında bir seçim yapmak söz konusudur. Hiçbir şey umurunuzda + değilse + çoğu ayrıcalığın yitirilmesi pahasına bu değeri rahatça + 60 saniyenin üzerine çıkarabilirsiniz.

+ + +

Derleme Sırasında Yapılandırma ile İlgili Konular

+ + +

MPM Seçimi

+ + +

Apache 2.x, Çok Süreçlilik Modülleri + (MPM) adı verilen eklemlenebilir çok görevlilik modellerini + destekler. Apache’yi derlerken bu MPM’lerden birini seçmeniz + gerekir. MPM’lerden bazıları platformlara özeldir: + mpm_netware, mpmt_os2 ve + mpm_winnt. Unix + benzeri sistemler için ise seçebileceğiniz modül sayısı birden + fazladır. MPM seçiminin httpd’nin hızında ve ölçeklenebilirliğinde + bazı etkileri olabilir:

+ +

worker modülü her biri çok evreli çok sayıda + çocuk süreç kullanımını destekler. Her evre aynı anda tek bir + bağlantıya hizmet sunar. Aynı hizmeti daha az bellek harcayarak + vermesi nedeniyle yüksek trafiğe sahip sunucularda + prefork modülüne göre daha iyi bir seçimdir.
event modülü worker modülü gibi + çok evreli bir modüldür, fakat aunı anda dahafazla isteğe yanıt + verecek şekilde tasarlanmıştır. Bunu, evreleri destekleyen bazı + işlemleri yapmamak suretiyle yeni isteklerle çalışacak ana evreleri + serbestleştirerek sağlar.
prefork modülü her biri tek bir evreye sahip + çok sayıda çocuk süreç kullanımını destekler. Her süreç aynı anda + tek bir bağlantıya hizmet sunar. Çoğu sistemde daha hızlı olması + nedeniyle worker modülüne göre daha iyi bir seçim + olarak görünürse de bunu daha fazla bellek kullanarak sağlar. + prefork modülünün evresiz tasarımının + worker modülüne göre bazı yararlı tarafları + vardır: Çok evreli sistemlerde güvenilir olmayan üçüncü parti + modülleri kullanabilir ve evrelerde hata ayıklamanın yetersiz + kaldığı platformlarda hatalarını ayıklamak daha kolaydır.

+ +

Bu modüller ve diğerleri hakkında daha ayrıntılı bilgi edinmek için + Çok Süreçlilik Modülleri belgesine + bakınız.

+ + + +

Modüller

+ + + +

Bellek kullanımı başarım konusunda önemli olduğundan gerçekte + kullanmadığınız modülleri elemeye çalışmalısınız. Modülleri birer DSO olarak derlediyseniz LoadModule yönergesinin bulunduğu satırı + açıklama haline getirmeniz modülden kurtulmanız için yeterli + olacaktır. Modülleri bu şekilde kaldırarak onların yokluğunda + sitenizin hala işlevlerini yerine getirdiğini görme şansına da + kavuşmuş olursunuz.

+ +

Ancak, eğer modülleri Apache çalıştırılabilirinin içine + gömmüşseniz istenmeyen modülleri kaldırmak için Apache'yi yeniden + derlemeniz gerekir.

+ +

Bu noktada bir soru akla gelebilir: Hangi modüller gerekli, + hangileri değil? Bu sorunun yanıtı şüphesiz siteden siteye değişir. + Ancak, olmazsa olmaz moüller olarak mod_mime, + mod_dir ve mod_log_config + modüllerini sayabiliriz. Bunlardan mod_log_config + olmadan da bir sitenin çalışabileceğinden hareketle bu modülün + varlığı isteğe bağlı olsa da bu modülü kaldırmanızı önermiyoruz.

+ + + +

Atomik İşlemler

+ + + +

Worker MPM'nin en son geliştirme sürümleri ve + mod_cache gibi bazı modüller APR'nin atomik API'sini + kullanırlar. Bu API, düşük ayarlı evre eşzamanlamasında atomik + işlemler yapar.

+ +

Öntanımlı olarak, APR bu işlemleri hedef işletim sistemi/işlemci + platformunda kullanılabilecek en verimli mekanizmayı kullanarak + gerçekleştirir. Günümüz işlemcilerinin çoğu, örneğin, bir atomik + karşılaştırma ve takas (CAS) işlemini donanımda gerçekleştirmektedir. + Bazı platformlarda APR'nin atomik işlemler için öntanımlı olarak daha + yavaş olan mutekslere dayalı gerçeklenimi kullanmasının sebebi eski + işlemcilerde bu tür makine kodlarının yokluğudur. Apache'yi bu tür + platformalarda günümüz işlemcileriyde çalıştırmayı düşünüyorsanız + Apache'yi derlemek için yapılandırırken en hızlı atomik işlemin + seçilebilmesi için --enable-nonportable-atomics + seçeneğini kullanın:

+ +

+ ./buildconf + ./configure --with-mpm=worker --enable-nonportable-atomics=yes +

+ +

--enable-nonportable-atomics seçeneği şu platformlar + için uygundur:

+ +

SPARC üzerinde Solaris
+ APR öntanımlı olarak, SPARC/Solaris üzerinde mutekslere dayalı + atomik işlemleri kullanır. Ancak, + --enable-nonportable-atomics yapılandırmasını + kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas + için uygun SPARC v8plus kodunu kullanacak şekilde kod üretilir. + Apache'yi bu seçenekle yapılandırırsanız atomik işlemler daha + verimli olacak fakat derlenen Apache çalıştırılabiliri sadece + UltraSPARC kırmığı üzerinde çalışacaktır. +
x86 üzerinde Linux
+ APR öntanımlı olarak, Linux üzerinde mutekslere dayalı atomik + işlemleri kullanır. Ancak, + --enable-nonportable-atomics yapılandırmasını + kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas + için uygun 486 kodunu kullanacak şekilde kod üretilir. Apache'yi + bu seçenekle yapılandırırsanız atomik işlemler daha verimli + olacak fakat derlenen Apache çalıştırılabiliri (386 üzerinde + değil) sadece 486 ve sonrası kırmıklarda çalışacaktır. +

+ + + +

`mod_status` ve `ExtendedStatus On` +

+ + + +

mod_status modülünü derlemiş ve Apache'yi + yapılandırır ve çalıştırırken ExtendedStatus On satırını + da kullanmışsanız Apache her istek üzerinde + gettimeofday(2) (veya işletim sistemine bağlı olarak + time(2)) çağrısından başka (1.3 öncesinde) fazladan + defalarca time(2) çağrıları yapacaktır. Bu çağrılarla + durum raporununun zamanlama bilgilerini içermesi sağlanır. Başarımı + arttırmak için ExtendedStatus off yapın (zaten öntanımlı + böyledir).

+ + + +

`accept` dizgilemesi ve çok soketli işlem

+ + + +

Uyarı:

Bu bölüm, Apache HTTP sunucusunun 2.x sürümlerinde yapılan + değişikliklere göre tamamen güncellenmemiştir. Bazı bilgiler hala + geçerliyse de lütfen dikkatli kullanınız.

+ +

Burada Unix soket arayüzü gerçeklenirken ihmal edilen bir durumdan + bahsedeceğiz. HTTP sunucunuzun çok sayıda adresten çok sayıda portu + dinlemek için çok sayıda Listen yönergesi kullanmakta olduğunu varsayalım. Her + soketi çalıştığını görmek için denerken Apache bağlantı için + select(2) kullanacaktır. select(2) çağrısı + bu soketin üzerinde sıfır veya en azından bir + bağlantının beklemekte olduğu anlamına gelir. Apache'nin modeli çok + sayıda çocuk süreç içerir ve boşta olanların tümünde aynı anda yeni + bağlantılar denenebilir. Gerçekte çalışan kod bu olmasa da meramımızı + anlatmak için kodun şöyle bir şey olduğunu varsayabiliriz:

+ +

        for (;;) {
+          for (;;) {
+            fd_set accept_fds;
+
+            FD_ZERO (&accept_fds);
+            for (i = first_socket; i <= last_socket; ++i) {
+              FD_SET (i, &accept_fds);
+            }
+            rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+            if (rc < 1) continue;
+            new_connection = -1;
+            for (i = first_socket; i <= last_socket; ++i) {
+              if (FD_ISSET (i, &accept_fds)) {
+                new_connection = accept (i, NULL, NULL);
+                if (new_connection != -1) break;
+              }
+            }
+            if (new_connection != -1) break;
+          }
+          process_the(new_connection);
+        }

+ + +

Bu özet gerçeklenim bir takım açlık sorunlarına sebep olur. Bu + döngünün çalışması sırasında aynı anda çok sayıda çocuk süreç yeniden + çağrılır ve istekler arasında kalan çoğu çocuk da select + ile engellenir. Engellenen tüm bu çocuklar soketlerden herhangi biri + üzerinde tek bir istek göründüğünde select tarafından + uyandırılıp işleme sokulmak üzere döndürülürler. (Uyandırılan çocuk + sayısı işletim sistemine ve zamanlama ayarlarına göre değişiklik + gösterir,) Bunların hepsi döngüye katılıp bağlantı kabul etmeye + (accept) çalışırlar. Fakat içlerinden yalnız biri + (sadece bir bağlantı isteğinin mevcut olduğu varsayımıyla) bunu + başarabilir. Kalanının bağlantı kabul etmesi (accept) + engellenir. Bu durum, bu çocukları istekleri başka başka soketlerden + değil mecburen tek bir soketten kabul etmeye kilitler ve bu soket + üzerinde yeni bir istek belirip uyandırılana kadar bu durumda + kalırlar. Bu açlık sorunu ilk olarak PR#467 sayılı raporla + belgelenmiştir. Bu sorunun en az iki çözümü vardır.

+ +

Çözümün biri engellenmeyen soket kullanımıdır. Bu durumda + accept çocukları engellemeyecek ve yapılan bir + bağlantının ardından diğer çocuklar durumları değişmeksizin bağlantı + beklemeye devam edeceklerdir. Fakat bu durum işlemci zamanının boşa + harcanmasına sebep olur. Seçilmiş (select) boşta on + çocuğun olduğunu ve bir bağlantı geldiğini varsayalım. Kalan dokuz + çocuk işine devam edip bağlantı kabul etmeyi (accept) + deneyecek, başarızsız olacak, dönecek başa, tekrar seçilecek + (select) ve böyle hiçbir iş yapmadan dönüp duracaktır. Bu + arada hizmet sunmakta olanlar da işlerini bitirdikten sonra bu + döngüdeki yerlerini alacaklardır. Aynı kutunun içinde boşta bir sürü + işlemciniz (çok işlemcili sistemler) yoksa bu çözüm pek verimli + olmayacaktır.

+ +

Diğer çözüm ise Apache tarafından kullanılan çözüm olup, girdiyi + bir iç döngüde sıraya sokmaktır. Döngü aşağıda örneklenmiştir (farklar + vurgulanmıştır):

+ +

        for (;;) {
+          accept_mutex_on ();
+          for (;;) {
+            fd_set accept_fds;
+
+            FD_ZERO (&accept_fds);
+            for (i = first_socket; i <= last_socket; ++i) {
+              FD_SET (i, &accept_fds);
+            }
+            rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+            if (rc < 1) continue;
+            new_connection = -1;
+            for (i = first_socket; i <= last_socket; ++i) {
+              if (FD_ISSET (i, &accept_fds)) {
+                new_connection = accept (i, NULL, NULL);
+                if (new_connection != -1) break;
+              }
+            }
+            if (new_connection != -1) break;
+          }
+          accept_mutex_off ();
+          process the new_connection;
+        }

+ + +

accept_mutex_on ve accept_mutex_off işlevleri bir karşılıklı red + semoforu oluştururlar. Mutekse aynı anda sadece bir çocuk sahip + olabilir. Bu muteksleri gerçeklemek için çeşitli seçenekler vardır. + Seçim, src/conf.h (1.3 öncesi) veya + src/include/ap_config.h (1.3 ve sonrası) dosyasında + tanımlanmıştır. Bazı mimariler bir kilitleme seçeneğine sahip + değildir. Böyle mimarilerde çok sayıda Listen yönergesi kullanmak güvenilir + olmayacaktır.

+ +

Mutex yönergesi, + mpm-accept muteks gerçeklenimini çalışma anında değiştirmek + için kullanılabilir. Farklı muteks gerçeklenimleri ile ilgili hususlar + bu yönergede belgelenmiştir.

+ +

Başka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceğinden + (yani belli sayıda sürece izin verilemeyeceğinden) asla + gerçeklenmemiştir. Bu sadece, aynı anda çok sayıda çocuk sürecin + çalışabileceği ve dolayısıyla band genişliğinin tüm yönleriyle + kullanılabileceği çok işlemcili sistemlerde ilginç olabilirdi. Bu + gelecekte incelenmeye değer bir konu olmakla beraber çok sayıda HTTP + sunucusunun aynı anda aynı amaca hizmet edecek şekilde çalışması + standart olarak pek mümkün görülmediğinden bu olasılık çok + düşüktür.

+ +

En yüksek başarımı elde etmek için ideal olanı sunucuları + çalıştırırken çok sayıda Listen yönergesi kullanmamaktır. Fakat siz yine de + okumaya devam edin.

+ + + +

`accept` dizgilemesi - tek soket

+ + + +

Çok soketli sunucular için yukarıda açıklananlar iyi güzel de tek + soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir + sorunları olmaması gerekir. Çünkü yeni bir bağlantı gelene kadar tüm + çocuklar accept(2) ile engellenirler dolayısıyla hiçbir + açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son + kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde + bahsedilenle hemen hemen aynı "boşa dönüp durma" davranışı mevcuttur. + Çoğu TCP yığıtı bu yolu gerçeklemiştir. Çekirdek, yeni bir bağlantı + ortaya çıktığında accept ile engellenen tüm süreçleri + uyandırır. Bu süreçlerden bağlantıyı alan kullanıcı bölgesine geçerken + çekirdek içinde döngüde olan diğerleri de yeni bağlantı keşfedilene + kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı + bölgesindeki kodlara görünür değildir ama bu olmadıkları anlamına + gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boşa + döngünün sebep olduğu gereksiz işlemci yükü sorununu içinde + barındırır.

+ +

Bununla birlikte, tek soketli durumda bile bundan daha verimli bir + davranış sergileyen bir çok mimari bulduk. Bu aslında hemen hemen her + durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü + denemelerde (128MB bellekli çift Pentium pro 166 işlemcili makinede + Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiş duruma göre + saniyede %3 daha az istekle sonuçlandığı gösterilmiştir. Fakat + dizgilenmemiş tek soket durumunda her istekte 100ms'lik ek bir gecikme + olduğu görülmüştür. Bu gecikmenin sebebi muhtemelen uzun mesafeli + hatlar olup sadece yerel ağlarda söz konusudur. Tek soketli + dizgilemeyi geçersiz kılmak için + SINGLE_LISTEN_UNSERIALIZED_ACCEPT tanımlarsanız tek + soketli sunucularda artık dizgileme yapılmayacaktır.

+ + + +

Kapatmayı zamana yaymak

+ + + +

draft-ietf-http-connection-00.txt taslağının 8. bölümünde + bahsedildiği gibi, bir HTTP sunucusunun protokolü güvenilir + şekilde gerçeklemesi için her iki yöndeki iletişimi + birbirinden bağımsız olarak (iki yönlü bir TCP bağlantısının her + yarısını diğerinden bağımsız olarak) kapatması gerekir.

+ +

Bu özellik Apache'ye eklendiğinde Unix'in çeşitli sürümlerinde + uzgörüsüzlükten dolayı bir takım geçici telaş sorunlarına sebep oldu. + TCP belirtimi FIN_WAIT_2 durumunda bir zaman aşımından + bahsetmez ama yasaklamaz da. Zaman aşımı olmayan sistemlerde, Apache + 1.2 çoğu soketin sonsuza kadar FIN_WAIT_2 durumunda + takılıp kalmasına sebep olur. Çoğu durumda, satıcıdan sağlanan en son + TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni + yama dağıtmadığı durumlarda (örneğin, SunOS4 -- bir kaynak lisansı ile + insanlar bunu kendileri yamayabilirse de) bu özelliği devre dışı + bırakmaya karar verdik.

+ +

Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri + SO_LINGER soket seçeneğidir. Bu işin kaderi buymuş gibi + görünürse de çoğu TCP/IP yığıtında bu gerektiği gibi + gerçeklenmemiştir. Bu yığıtlar üzerinde, bu yöntemin, doğru bir + gerçeklenimle bile (örneğin, Linux 2.0.31) sonraki çözümden daha + pahalı olduğu ortaya çıkmıştır.

+ +

Çoğunlukla, Apache bunu (http_main.c içindeki) + lingering_close adında bir işlevle gerçekler. Bu işlev + kabaca şöyle görünür:

+ +

        void lingering_close (int s)
+        {
+          char junk_buffer[2048];
+
+          /* shutdown the sending side */
+          shutdown (s, 1);
+
+          signal (SIGALRM, lingering_death);
+          alarm (30);
+
+          for (;;) {
+            select (s for reading, 2 second timeout);
+            if (error) break;
+            if (s is ready for reading) {
+              if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+                break;
+              }
+              /* just toss away whatever is here */
+            }
+          }
+
+          close (s);
+        }

+ + +

Bağlantı sonunda bu doğal olarak biraz daha masrafa yol açar, fakat + güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın + kullanılmaya başlanması ve tüm bağlantıların kalıcı hale gelmesiyle bu + gerçeklenim daha fazla istek üzerinden kendi masrafını + karşılayacaktır. Ateşle oynamak ve bu özelliği devre dışı bırakmak + isterseniz NO_LINGCLOSE'u tanımlayabilirsiniz, fakat bu + asla önerilmez. Özellikle, HTTP/1.1'den itibaren boruhatlı kalıcı + bağlantıların lingering_close kullanmaya başlaması mutlak + bir gerekliliktir (ve + boruhatlı bağlantıların daha hızlı olması nedeniyle bu + bağlantıları desteklemek isteyebilirsiniz).

+ + + +

Çetele Dosyası

+ + + +

Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birşey + üzerinden haberleşirler. Bunun en mükemmel şekilde paylaşımlı bellekte + gerçeklenmesi gerekir. Eriştiğimiz veya portlarını ayrıntılı olarak + belirttiğimiz işletim sistemleri için bu, genellikle paylaşımlı bellek + kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir + disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaş olmanın yanı + sıra güvenilir de değildir (ve daha az özelliğe sahiptir). Mimarinizin + src/main/conf.h dosyasını inceleyin ve + USE_MMAP_SCOREBOARD veya + USE_SHMGET_SCOREBOARD'a bakın. Bu ikisinden birinin (ve + yanı sıra sırasıyla HAVE_MMAP veya + HAVE_SHMGET'in) tanımlanmış olması, sağlanan paylaşımlı + bellek kodunu etkinleştirir. Eğer sisteminiz diğer türdeki paylaşımlı + belleğe sahipse, src/main/http_main.c dosyasını açıp, + Apache'de bu belleği kullanması gereken kanca işlevleri ekleyin (Bize + de bir yama yollayın, lütfen).

+ +

Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2 + sürümüne kadar paylaşımlı belleği kullanmaya başlamamıştı. Bu kusur, + Apache'nin Linux üzerindeki erken dönem sürümlerinin davranışlarının + zayıf ve güvenilmez olmasına yol açmıştı.

+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz + (burayı okuyan ve sunucunuzun başarımını son kırıntısına kadar + arttırmakla ilgilenen biriyseniz bunu düşünmezsiniz), sunucunuzu + derlerken seçenekler arasına -DDYNAMIC_MODULE_LIMIT=0 + seçeneğini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen + modüller için ayrılacak belleği kazanmış olacaksınız.

+ + + +

Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi

+ + + +

Burada, Solaris 8 üzerinde worker MPM'li Apache 2.0.38'in bir sistem + çağrısı izlenmektedir. Bu izleme şu komutla elde edilmiştir:

+ +

+ truss -l -p httpd_çocuk_pidi. +

+ +

-l seçeneği, truss'a hafif bir sürecin yaptığı her + sistem çağrısını (hafif süreç -- HS -- Solaris'in bir çekirdek seviyesi + evreleme biçimi) günlüğe yazmasını söyler.

+ +

Diğer sistemlerin sistem çağrılarını izleyen farklı araçları vardır + (strace, ktrace, par gibi). + Bunlar da benzer çıktılar üretirler.

+ +

Bu izleme sırasında, bir istemci httpd'den 10 KB'lık duruk bir dosya + talebinde bulunmuştur. Duruk olmayan veya içerik uzlaşımlı isteklerin + izleme kayıtları vahşice (bazı durumlarda epey çirkince) farklı + görünür.

+ +

+ /67: accept(3, 0x00200BEC, 0x00200C0C, 1) (uykuda...) + /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9 +

+ +

Bu izlemede, dinleyen evre HS #67 içinde çalışmaktadır.

+ +

accept(2) dizgelemesinin olmayışına dikkat edin. + Özellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe, + öntanımlı olarak dizgeleştirilmemiş bir accept çağrısı kullanır.

+ +

+ /65: lwp_park(0x00000000, 0) = 0 + /67: lwp_unpark(65, 1) = 0 +

+ +

Bağlantının kabul edilmesiyle, dinleyici evre isteği yerine getirmek + üzere bir worker evresini uyandırır. Bu izlemede, isteği yerine getiren + worker evresi HS #65'e aittir.

+ +

+ /65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0 +

+ +

Sanal konakların gerçeklenimi sırasında, Apache'nin, bağlantıları + kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir. + Çoğu durumda bu çağrıyı bertaraf etmek mümkündür (hiç sanal konağın + olmadığı veya Listen + yönergelerinin mutlak adreslerle kullanıldığı durumlarda). Fakat bu en + iyilemeleri yapmak için henüz bir çaba harcanmamıştır.

+ +

+ /65: brk(0x002170E8) = 0 + /65: brk(0x002190E8) = 0 +

+ +

brk(2) çağrıları devingen bellekten bellek ayırır. httpd + çoğu isteği yerine getirirken özel bellek ayırıcılar + (apr_pool ve apr_bucket_alloc) kullandığından + bunlar bir sistem çağrısı izlemesinde nadiren görünür. Bu izlemede, + httpd henüz yeni başlatıldığından, özel bellek ayırıcıları oluşturmak + için ham bellek bloklarını ayırmak amacıyla malloc(3) + çağrıları yapması gerekir.

+ +

+/65: fcntl(9, F_GETFL, 0x00000000) = 2 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0 +/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0 +/65: fcntl(9, F_SETFL, 0x00000082) = 0 +

+ +

Ardından, worker evresi istemciye (dosya tanıtıcısı 9) engellenmeyen + kipte bir bağlantı açar. setsockopt(2) + ve getsockopt(2) çağrıları, Solaris libc'sinin soketler + üzerindeki fcntl(2) çağrısı yanında birer yan etkiden + ibarettirler.

+ +

+ /65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97 +

+ +

Worker evresi istemciden isteği okur.

+ +

+/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0 +/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10 +

+ +

Bu httpd Options FollowSymLinks ve AllowOverride + None ile yapılandırılmıştır. Bu bakımdan, ne istenen dosya ile + sonuçlanan yol üzerindeki her dizinde lstat(2) çağrısına ne + de .htaccess dosyalarına bakılmasına gerek vardır. + stat(2) çağrısı basitçe dosya için şunları doğrulamak + amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin değil normal bir + dosyadır.

+ +

+ /65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269 +

+ +

Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt başlığını tek bir + sendfilev(2) sistem çağrısı ile göndermektedir. Dosya + gönderim işleminin anlamı sistemden sisteme değişiklik gösterir. Bazı + sistemlerde, sendfile(2) çağrısından önce başlıkları + göndermek için write(2) veya writev(2) + çağrısı yapmak gerekir.

+ +

+ /65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78 +

+ +

Bu write(2) çağrısı isteği erişim günlüğüne kaydeder. Bu + izlemede eksik olan tek şey, time(2) çağrısıdır. Apache + 1.3'ün aksine, Apache 2.x zamana bakmak için + gettimeofday(3) çağırısını kullanır. Linux ve Solaris gibi + bazı işletim sistemleri, gettimeofday işlevinin, sıradan + bir sistem çağrısından daha fazla götürüsü olmayan en iyilenmiş bir + gerçeklenimine sahiptir.

+ +

+ /65: shutdown(9, 1, 1) = 0 + /65: poll(0xFAF7B980, 1, 2000) = 1 + /65: read(9, 0xFAF7BC20, 512) = 0 + /65: close(9) = 0 +

+ +

Burada worker evresi bağlantıyı zamana yaymaktadır.

+ +

+ /65: close(10) = 0 + /65: lwp_park(0x00000000, 0) (uykuda...) +

+ +

Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra + dinleyici evre tarafından başka bir bağlantı atanıncaya kadar beklemeye + alınır.

+ +

+ /67: accept(3, 0x001FEB74, 0x001FEB94, 1) (uykuda...) +

+ +

Bu arada, dinleyici evre bağlantıyı bir worker evresine atar atamaz + başka bir bağlantıyı beklemeye başlar (Mevcut tüm evreler meşgulse + dinleyici evreyi baskılayan worker MPM'nin akış denetim şemasına konu + olur). Bu izlemede görünmüyor olsa da sonraki accept(2) + çağrısı, yeni bağlantı kabul eden worker evresine paralel olarak + yapılabilir (aşırı yük durumlarında normal olarak, bu yapılır).

+ +

Apache’de Başarımın Arttırılması

Ayrıca bakınız:

Bellek Eşlemleri

sendfile

MPM Seçimi

Atomik İşlemler

mod_status ve ExtendedStatus On +

accept dizgilemesi ve çok soketli işlem

Uyarı:

accept dizgilemesi - tek soket

Kapatmayı zamana yaymak

Çetele Dosyası

DYNAMIC_MODULE_LIMIT

`sendfile`

`mod_status` ve `ExtendedStatus On` +

`accept` dizgilemesi ve çok soketli işlem

`accept` dizgilemesi - tek soket