1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" lang="tr" xml:lang="tr"><head><!--
4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5 This file is generated from xml source: DO NOT EDIT
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
8 <title>Apache’de Başarımın Arttırılması - Apache HTTP Sunucusu</title>
9 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
10 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
11 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
12 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
13 <body id="manual-page"><div id="page-header">
14 <p class="menu"><a href="../mod/">Modüller</a> | <a href="../mod/directives.html">Yönergeler</a> | <a href="../faq/">SSS</a> | <a href="../glossary.html">Terimler</a> | <a href="../sitemap.html">Site Haritası</a></p>
15 <p class="apache">Apache HTTP Sunucusu Sürüm 2.0</p>
16 <img alt="" src="../images/feather.gif" /></div>
17 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
19 <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Sunucusu</a> > <a href="http://httpd.apache.org/docs/">Belgeleme</a> > <a href="../">Sürüm 2.0</a> > <a href="./">Çeşitli Belgeler</a></div><div id="page-content"><div id="preamble"><h1>Apache’de Başarımın Arttırılması</h1>
21 <p><span>Mevcut Diller: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> |
22 <a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
23 <a href="../tr/misc/perf-tuning.html" title="Türkçe"> tr </a></p>
27 <p>Apache 2.x, esneklik, taşınabilirlik ve başarım arasında bir denge
28 sağlamak üzere tasarlanmış genel amaçlı bir HTTP sunucusudur. Başka
29 sunucularla kıyaslama denemelerinde öne geçmek üzere tasarlanmamış
30 olsa da Apache 2.x gerçek yaşamda karşılaşılan pek çok durumda oldukça
31 yüksek bir başarıma ulaşacak yetenektedir.</p>
33 <p>Apache 1.3 ile karşılaştırıldığında 2.x sürümleri toplam veri hızını
34 ve ölçeklenebilirliği arttırmak için pek çok en iyileme seçeneği
35 içerir. Bu iyileştirmelerin pek çoğu zaten öntanımlı olarak etkin
36 olmakla birlikte derleme ve kullanım sırasında başarımı önemli ölçüde
37 etkileyebilen yapılandırma seçenekleri de mevcuttur. Bu belgede, bir
38 Apache 2.x kurulumunda sunucu yöneticisinin sunucunun başarımını
39 arttırmak amacıyla yapılandırma sırasında neler yapabileceğinden
40 bahsedilmiştir. Bu yapılandırma seçeneklerinden bazıları, httpd’nin
41 donanımın ve işletim sisteminin olanaklarından daha iyi
42 yararlanabilmesini sağlarken bir kısmı da daha hızlı bir sunum için
43 yöneticinin işlevsellikten ödün verebilmesini olanaklı kılar.</p>
46 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#hardware">Donanım ve İşletim Sistemi ile İlgili Konular</a></li>
47 <li><img alt="" src="../images/down.gif" /> <a href="#runtime">Çalışma Anı Yapılandırması ile İlgili Konular</a></li>
48 <li><img alt="" src="../images/down.gif" /> <a href="#compiletime">Derleme Sırasında Yapılandırma ile İlgili Konular</a></li>
49 <li><img alt="" src="../images/down.gif" /> <a href="#trace">Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi</a></li>
51 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
53 <h2><a name="hardware" id="hardware">Donanım ve İşletim Sistemi ile İlgili Konular</a></h2>
57 <p>HTTP sunucusunun başarımını etkileyen en önemli donanım bellektir
58 (RAM). Bir HTTP sunucusu asla takaslama yapmamalıdır. Çünkü takaslama,
59 kullanıcının "yeterince hız" umduğu noktada sunumun gecikmesine sebep
60 olur. Böyle bir durumda kullanıcılar yüklemeyi durdurup tekrar
61 başlatma eğilimindedirler; sonuçta yük daha da artar. <code class="directive"><a href="../mod/mpm_common.html#maxclients">MaxClients</a></code> yönergesinin değerini
62 değiştirerek takaslamaya sebep olabilecek kadar çok çocuk süreç
63 oluşturulmasını engelleyebilirsiniz ve böyle bir durumda bunu mutlaka
64 yapmalısınız. Bunun için yapacağınız işlem basittir: <code>top</code>
65 benzeri bir araç üzerinden çalışan süreçlerinizin bir listesini alıp
66 Apache süreçlerinizin ortalama büyüklüğünü saptayıp, mevcut bellekten
67 bir kısmını diğer süreçler için ayırdıktan sonra kalan miktarı bu
68 değere bölerseniz yönergeye atayacağınız değeri bulmuş olursunuz.</p>
70 <p>Donanımın diğer unsurları için kararı siz verin: Daha hızlı işlemci,
71 daha hızlı ağ kartı, daha hızlı disk; daha hızlının ne kadar hızlı
72 olacağını deneyimlerinize bağlı olarak tamamen sizin ihtiyaçlarınız
75 <p>İşletim sistemi seçimi büyük oranda yerel ilgi konusudur. Fakat yine
76 de, genelde yararlılığı kanıtlanmış bazı kurallar bu seçimde size
77 yardımcı olabilir:</p>
81 <p>Seçtiğiniz işletim sisteminin (çekirdeğin) en son kararlı
82 sürümünü çalıştırın. Bir çok işletim sistemi, son yıllarda TCP
83 yığıtları ve evre kütüphaneleri ile ilgili belirgin iyileştirmeler
84 yapmışlar ve yapmaktadırlar.</p>
88 <p>İşletim sisteminiz <code>sendfile</code>(2) sistem çağrısını
89 destekliyorsa bunun etkinleştirilebildiği sürümün kurulu olması
90 önemlidir. (Örneğin, Linux için bu, Linux 2.4 ve sonraki sürümler
91 anlamına gelirken, Solaris için Solaris 8’den önceki sürümlerin
92 yamanması gerektirdiği anlamına gelmektedir.)
93 <code>sendfile</code> işlevinin desteklendiği sistemlerde Apache 2
94 duruk içeriği daha hızlı teslim etmek ve işlemci kullanımını
95 düşürmek amacıyla bu işlevselliği kullanacaktır.</p>
99 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
100 <div class="section">
101 <h2><a name="runtime" id="runtime">Çalışma Anı Yapılandırması ile İlgili Konular</a></h2>
105 <table class="related"><tr><th>İlgili Modüller</th><th>İlgili Yönergeler</th></tr><tr><td><ul><li><code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code></li><li><code class="module"><a href="../mod/mpm_common.html">mpm_common</a></code></li><li><code class="module"><a href="../mod/mod_status.html">mod_status</a></code></li></ul></td><td><ul><li><code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code></li><li><code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code></li><li><code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code></li><li><code class="directive"><a href="../mod/core.html#enablemmap">EnableMMAP</a></code></li><li><code class="directive"><a href="../mod/core.html#enablesendfile">EnableSendfile</a></code></li><li><code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code></li><li><code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code></li><li><code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code></li><li><code class="directive"><a href="../mod/core.html#options">Options</a></code></li><li><code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code></li></ul></td></tr></table>
107 <h3><a name="dns" id="dns"><code>HostnameLookups</code> ve DNS ile ilgili diğer konular</a></h3>
111 <p>Apache 1.3 öncesinde, <code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code> yönergesinin öntanımlı değeri
112 <code>On</code> idi. İstek yerine getirilmeden önce bir DNS sorgusu
113 yapılmasını gerektirmesi sebebiyle bu ayarlama her istekte bir
114 miktar gecikmeye sebep olurdu. Apache 1.3’ten itibaren yönergenin
115 öntanımlı değeri <code>Off</code> yapılmıştır. Eğer günlük
116 dosyalarınızda konak isimlerinin bulunmasını isterseniz, Apache ile
117 birlikte gelen <code class="program"><a href="../programs/logresolve.html">logresolve</a></code> programını
118 kullanabileceğiniz gibi günlük raporlarını çözümleyen Apache ile
119 gelmeyen programlardan herhangi birini de kullanabilirsiniz.</p>
121 <p>Günlük dosyaları üzerindeki bu işlemi sunucu makinesi dışında
122 günlük dosyasının bir kopyası üzerinde yapmanızı öneririz. Aksi
123 takdirde sunucunuzun başarımı önemli ölçüde etkilenebilir.</p>
125 <p><code class="directive"><a href="../mod/mod_access.html#allow">Allow</a></code> veya
126 <code class="directive"><a href="../mod/mod_access.html#deny">Deny</a></code>
127 yönergelerinde IP adresi yerine bir konak veya alan ismi
128 belirtirseniz, iki DNS sorguluk bir bedel ödersiniz (biri normal,
129 diğeri IP taklidine karşı ters DNS sorgusu). Başarımı en iyilemek
130 için bu yönergelerde mümkün olduğunca isim yerine IP adreslerini
133 <p><code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code>
134 yönergelerinin <code><Location /server-status></code> gibi
135 bölüm yönergelerinin içinde de yer alabileceğini unutmayın. Bu gibi
136 durumlarda DNS sorguları sadece istek kuralla eşleştiği takdirde
137 yapılacaktır. Aşağıdaki örnekte <code>.html</code> ve
138 <code>.cgi</code> dosyalarına yapılan istekler hariç DNS sorguları
139 iptal edilmektedir:</p>
141 <div class="example"><p><code>
142 HostnameLookups off<br />
143 <Files ~ "\.(html|cgi)$"><br />
144 <span class="indent">
145 HostnameLookups on<br />
150 <p>Yine de bazı CGI’lerin DNS isimlerine ihtiyacı olursa bu CGI’lerin
151 bu ihtiyaçlarına yönelik olarak <code>gethostbyname</code> çağrıları
152 yapabileceğini gözardı etmeyiniz.</p>
156 <h3><a name="symlinks" id="symlinks"><code>FollowSymLinks</code> ve
157 <code>SymLinksIfOwnerMatch</code></a></h3>
161 <p>URL uzayınızda geçerli olmak üzere bir <code>Options
162 FollowSymLinks</code> yoksa veya <code>Options
163 SymLinksIfOwnerMatch</code> yönergeleri varsa, Apache her sembolik
164 bağın üzerinde bazı sınamalar yapmak için ek bir sistem çağrısından
165 başka istenen her dosya için de ayrı bir çağrı yapacaktır.</p>
167 <div class="example"><h3>Örnek:</h3><p><code>
168 DocumentRoot /siteler/htdocs<br />
169 <Directory /><br />
170 <span class="indent">
171 Options SymLinksIfOwnerMatch<br />
176 <p>Bu durumda <code>/index.html</code> için bir istek yapıldığında
177 Apache, <code>/siteler</code>, <code>/siteler/htdocs</code> ve<br />
178 <code>/siteler/htdocs/index.html</code> üzerinde
179 <code>lstat</code>(2) çağrıları yapacaktır. <code>lstat</code>
180 sonuçları önbelleğe kaydedilmediğinden bu işlem her istekte
181 yinelenecektir. Amacınız gerçekten sembolik bağları güvenlik
182 açısından sınamaksa bunu şöyle yapabilirsiniz:</p>
184 <div class="example"><p><code>
185 DocumentRoot /siteler/htdocs<br />
186 <Directory /><br />
187 <span class="indent">
188 Options FollowSymLinks<br />
190 </Directory><br />
192 <Directory /sitem/htdocs><br />
193 <span class="indent">
194 Options -FollowSymLinks +SymLinksIfOwnerMatch<br />
199 <p>Böylece <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> altındaki
200 dosyalar için fazladan bir çağrı yapılmasını engellemiş olursunuz.
201 Eğer bazı bölümlerde <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code>, <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> gibi yönergeler üzerinden belge kök
202 dizininizin dışında kalan dosya yollarına sahipseniz benzer
203 işlemleri onlar için de yapmalısınız. Sembolik bağ koruması yapmamak
204 suretiyle başarımı arttırmak isterseniz, <code>FollowSymLinks</code>
205 seçeneğini her yerde etkin kılın ve
206 <code>SymLinksIfOwnerMatch</code> seçeneğini asla
207 etkinleştirmeyin.</p>
211 <h3><a name="htacess" id="htacess"><code>AllowOverride</code></a></h3>
215 <p>Genellikle <code>.htaccess</code> dosyaları üzerinden yapıldığı
216 gibi URL uzayınızda geçersizleştirmelere izin veriyorsanız, Apache
217 her dosya bileşeni için bu <code>.htaccess</code> dosyalarını açmaya
220 <div class="example"><h3>Örnek:</h3><p><code>
221 DocumentRoot /siteler/htdocs<br />
222 <Directory /><br />
223 <span class="indent">
224 AllowOverride all<br />
229 <p>Bu durumda <code>/index.html</code> sayfasına yapılan bir istek için
230 Apache, <code>/.htaccess</code>, <code>/siteler/.htaccess</code> ve
231 <code>/siteler/htdocs/.htaccess</code> dosyalarını açmaya
232 çalışacaktır. Çözüm <code>Options FollowSymLinks</code> durumunun
233 benzeridir; başarımı arttırmak için dosya sisteminizin her yerinde
234 <code>AllowOverride None</code> olsun.</p>
238 <h3><a name="negotiation" id="negotiation">Dil Uzlaşımı</a></h3>
242 <p>Başarımı son kırıntısına kadar arttırmak istiyorsanız, mümkünse
243 içerik dili uzlaşımı da yapmayın. Dil uzlaşımından yararlanmak
244 isterken büyük başarım kayıplarına uğrayabilirsiniz. Böyle bir
245 durumda sunucunun başarımını arttırmanın tek bir yolu vardır. </p>
247 <div class="example"><p><code>
251 <p>Yukarıdaki gibi bir dosya ismi kalıbı kullanmak yerine, aşağıdaki
252 gibi seçenekleri tam bir liste halinde belirtin:</p>
254 <div class="example"><p><code>
255 DirectoryIndex index.cgi index.pl index.shtml index.html
258 <p>Buradaki sıralama öncelik sırasını belirler; yani,
259 öncelikli olmasını istediğiniz seçeneği listenin başına
262 <p>İstenen dosya için <code>MultiViews</code> kullanarak dizini
263 taratmak yerine, gerekli bilgiyi tek bir dosyadan okutmak suretiyle
264 başarımı arttırabilirsiniz. Bu amaçla türeşlem
265 (<code>type-map</code>) dosyaları kullanmanız yeterli olacaktır.</p>
267 <p>Sitenizde içerik dili uzlaşımına gerek varsa, bunu <code>Options
268 MultiViews</code> yönergesi üzerinden değil, türeşlem dosyaları
269 kullanarak yapmayı deneyin. İçerik dili uzlaşımı ve türeşlem
270 dosyalarının oluşturulması hakkında daha ayrıntılı bilgi edinmek
271 için <a href="../content-negotiation.html">İçerik Uzlaşımı</a>
272 belgesine bakınız.</p>
276 <h3>Bellek Eşlemleri</h3>
280 <p>Apache’nin SSI sayfalarında olduğu gibi teslim edilecek dosyanın
281 içeriğine bakma gereği duyduğu durumlarda, eğer işletim sistemi
282 <code>mmap</code>(2) ve benzerlerini destekliyorsa çekirdek normal
283 olarak dosyayı belleğe kopyalayacaktır.</p>
285 <p>Bazı platformlarda bu belleğe eşleme işlemi başarımı arttırsa da
286 başarımın veya httpd kararlılığının zora girdiği durumlar
291 <p>Bazı işletim sistemlerinde işlemci sayısı artışına bağlı
292 olarak, <code>mmap</code> işlevi <code>read</code>(2) kadar iyi
293 ölçeklenmemiştir. Örneğin, çok işlemcili Solaris sunucularda
294 <code>mmap</code> iptal edildiği takdirde içeriği sunucu
295 tarafından işlenen dosyalar üzerinde bazen daha hızlı işlem
296 yapılabilmektedir.</p>
300 <p>Belleğe kopyalanacak dosya NFS üzerinden bağlanan bir dosya
301 sistemindeyse ve dosya başka bir NFS istemcisi makine tarafından
302 silinmiş veya dosyanın boyutu değiştirilmişse sunucunuz dosyaya
303 tekrar erişmeye çalıştığında bir hata alabilecektir.</p>
307 <p>Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriği
308 sunucu tarafından işlenecek dosyaların belleğe kopyalanmaması için
309 yapılandırmanıza <code>EnableMMAP off</code> satırını ekleyiniz.
310 (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen
311 yönergelerdendir.)</p>
315 <h3><code>sendfile</code></h3>
319 <p>Apache’nin duruk dosyalarda olduğu gibi teslim edilecek dosyanın
320 içeriğine bakmadığı durumlarda, eğer işletim sistemi
321 <code>sendfile</code>(2) desteğine sahipse çekirdek normal olarak bu
322 desteği kullanacaktır.</p>
324 <p>Bazı platformlarda <code>sendfile</code> kullanımı, okuma ve yazma
325 işlemlerinin ayrı ayrı yapılmamasını sağlasa da
326 <code>sendfile</code> kullanımının httpd kararlılığını bozduğu bazı
327 durumlar sözkonusudur:</p>
331 <p>Bazı platformlar derleme sisteminin saptayamadığı bozuk bir
332 <code>sendfile</code> desteğine sahip olabilir. Özellikle
333 derleme işleminin başka bir platformda yapılıp
334 <code>sendfile</code> desteği bozuk bir makineye kurulum
335 yapıldığı durumlarda bu desteğin bozuk olduğu
336 saptanamayacaktır.</p>
339 <p>Çekirdek, NFS üzerinden erişilen ağ dosyalarını kendi önbelleği
340 üzerinden gerektiği gibi sunamayabilir.</p>
344 <p>Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriğin
345 <code>sendfile</code> desteğiyle teslim edilmemesi için
346 yapılandırmanıza <code>EnableSendfile off</code> satırını ekleyiniz.
347 (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen
348 yönergelerdendir.)</p>
352 <h3><a name="process" id="process">Süreç Oluşturma</a></h3>
356 <p>Apache 1.3 öncesinde <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>, <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code> ve <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> ayarları, başka sunucularla kıyaslama
357 denemelerinde olağanüstü kötü sonuçlar alınmasına sebep olmaktaydı.
358 Özellikle uygulanan yükü karşılamaya yetecek sayıda çocuk süreç
359 oluşturulması aşamasında Apache’nin elde ettiği ivme bunlardan
360 biriydi. Başlangıçta <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> yönergesiyle belli sayıda süreç
361 oluşturulduktan sonra her saniyede bir tane olmak üzere <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code> sayıda çocuk süreç
362 oluşturulmaktaydı. Örneğin, aynı anda 100 isteğe yanıt vermek için
363 <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code>
364 yönergesinin öntanımlı değeri olarak başta <code>5</code> süreç
365 oluşturulduğundan kalan süreçler için 95 saniye geçmesi gerekirdi.
366 Sık sık yeniden başlatılmadıklarından dolayı gerçek hayatta
367 sunucuların başına gelen de buydu. Başka sunucularla kıyaslama
368 denemelerinde ise işlem sadece on dakika sürmekte ve içler acısı
369 sonuçlar alınmaktaydı.</p>
371 <p>Saniyede bir kuralı, sunucunun yeni çocukları oluşturması sırasında
372 sistemin aşırı meşgul duruma düşmemesi için alınmış bir önlemdi.
373 Makine çocuk süreç oluşturmakla meşgul edildiği sürece isteklere
374 yanıt veremeyecektir. Böylesi bir durum Apache’nin başarımını
375 kötüleştirmekten başka işe yaramayacaktır. Apache 1.3’te saniyede
376 bir kuralı biraz esnetildi. Yeni gerçeklenimde artık bir süreç
377 oluşturduktan bir saniye sonra iki süreç, bir saniye sonra dört
378 süreç oluşturulmakta ve işlem, saniyede 32 çocuk süreç oluşturulur
379 duruma gelene kadar böyle ivmelenmektedir. Çocuk süreç oluşturma
380 işlemi <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>
381 değerine ulaşılınca durmaktadır.</p>
383 <p>Bu, <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>,
384 <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code> ve
385 <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> ayarlarıyla
386 oynamayı neredeyse gereksiz kılacak kadar iyi sonuçlar verecek gibi
387 görünmektedir. Saniyede 4 çocuktan fazlası oluşturulmaya
388 başlandığında hata günlüğüne bazı iletiler düşmeye başlar. Bu
389 iletilerin sayısı çok artarsa bu ayarlarla oynama vakti gelmiş
390 demektir. Bunun için <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> çıktısını bir
391 kılavuz olarak kullanabilirsiniz.</p>
393 <p>Süreç oluşturmayla ilgili olarak süreç ölümü <code class="directive"><a href="../mod/mpm_common.html#maxrequestsperchild">MaxRequestsPerChild</a></code> değeri ile
394 sağlanır. Bu değer öntanımlı olarak <code>0</code> olup, çocuk süreç
395 başına istek sayısının sınırsız olduğu anlamına gelir. Eğer
396 yapılandırmanızda bu değeri <code>30</code> gibi çok düşük bir
397 değere ayarlarsanız bunu hemen kaldırmak zorunda kalabilirsiniz.
398 Sunucunuzu SunOS veya Solaris’in eski bir sürümü üzerinde
399 çalıştırıyorsanız bellek kaçaklarına sebep olmamak için bu değeri
400 <code>10000</code> ile sınırlayınız.</p>
402 <p>Kalıcı bağlantı özelliğini kullanıyorsanız, çocuk süreçler zaten
403 açık bağlantılardan istek beklemekte olacaklardır. <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> yönergesinin öntanımlı
404 değeri <code>15</code> saniye olup bu etkiyi en aza indirmeye yönelik
405 süredir. Burada ağ band genişliği ile sunucu kaynaklarının kullanımı
406 arasında bir seçim yapmak söz konusudur. Hiçbir şey umurunuzda
407 değilse <a href="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html">
408 çoğu ayrıcalığın yitirilmesi pahasına</a> bu değeri rahatça
409 <code>60</code> saniyenin üzerine çıkarabilirsiniz.</p>
412 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
413 <div class="section">
414 <h2><a name="compiletime" id="compiletime">Derleme Sırasında Yapılandırma ile İlgili Konular</a></h2>
420 <p>Apache 2.x, <a href="../mpm.html">Çok Süreçlilik Modülleri</a>
421 (MPM) adı verilen eklemlenebilir çok görevlilik modellerini
422 destekler. Apache’yi derlerken bu MPM’lerden birini seçmeniz
423 gerekir. MPM’lerden bazıları platformlara özeldir:
424 <code class="module"><a href="../mod/beos.html">beos</a></code>, <code class="module"><a href="../mod/mpm_netware.html">mpm_netware</a></code>,
425 <code class="module"><a href="../mod/mpmt_os2.html">mpmt_os2</a></code> ve <code class="module"><a href="../mod/mpm_winnt.html">mpm_winnt</a></code>. Unix
426 benzeri sistemler için ise seçebileceğiniz modül sayısı birden
427 fazladır. MPM seçiminin httpd’nin hızında ve ölçeklenebilirliğinde
428 bazı etkileri olabilir:</p>
432 <li><code class="module"><a href="../mod/worker.html">worker</a></code> modülü her biri çok evreli çok sayıda
433 çocuk süreç kullanımını destekler. Her evre aynı anda tek bir
434 bağlantıya hizmet sunar. Aynı hizmeti daha az bellek harcayarak
435 vermesi nedeniyle yüksek trafiğe sahip sunucularda
436 <code class="module"><a href="../mod/prefork.html">prefork</a></code> modülüne göre daha iyi bir seçimdir.</li>
438 <li><code class="module"><a href="../mod/prefork.html">prefork</a></code> modülü her biri tek bir evreye sahip
439 çok sayıda çocuk süreç kullanımını destekler. Her süreç aynı anda
440 tek bir bağlantıya hizmet sunar. Çoğu sistemde daha hızlı olması
441 nedeniyle <code class="module"><a href="../mod/worker.html">worker</a></code> modülüne göre daha iyi bir seçim
442 olarak görünürse de bunu daha fazla bellek kullanarak sağlar.
443 <code class="module"><a href="../mod/prefork.html">prefork</a></code> modülünün evresiz tasarımının
444 <code class="module"><a href="../mod/worker.html">worker</a></code> modülüne göre bazı yararlı tarafları
445 vardır: Çok evreli sistemlerde güvenilir olmayan üçüncü parti
446 modülleri kullanabilir ve evrelerde hata ayıklamanın yetersiz
447 kaldığı platformlarda hatalarını ayıklamak daha kolaydır.</li>
451 <p>Bu modüller ve diğerleri hakkında daha ayrıntılı bilgi edinmek için
452 <a href="../mpm.html">Çok Süreçlilik Modülleri</a> belgesine
457 <h3><a name="modules" id="modules">Modüller</a></h3>
461 <p>Bellek kullanımı başarım konusunda önemli olduğundan gerçekte
462 kullanmadığınız modülleri elemeye çalışmalısınız. Modülleri birer <a href="../dso.html">DSO</a> olarak derlediyseniz <code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code> yönergesinin bulunduğu satırı
463 açıklama haline getirmeniz modülden kurtulmanız için yeterli
464 olacaktır. Modülleri bu şekilde kaldırarak onların yokluğunda
465 sitenizin hala işlevlerini yerine getirdiğini görme şansına da
466 kavuşmuş olursunuz.</p>
468 <p>Ancak, eğer modülleri Apache çalıştırılabilirinin içine
469 gömmüşseniz istenmeyen modülleri kaldırmak için Apache'yi yeniden
470 derlemeniz gerekir.</p>
472 <p>Bu noktada bir soru akla gelebilir: Hangi modüller gerekli,
473 hangileri değil? Bu sorunun yanıtı şüphesiz siteden siteye değişir.
474 Ancak, olmazsa olmaz moüller olarak <code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code>,
475 <code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code> ve <code class="module"><a href="../mod/mod_log_config.html">mod_log_config</a></code>
476 modüllerini sayabiliriz. Bunlardan <code>mod_log_config</code>
477 olmadan da bir sitenin çalışabileceğinden hareketle bu modülün
478 varlığı isteğe bağlı olsa da bu modülü kaldırmanızı önermiyoruz.</p>
482 <h3>Atomik İşlemler</h3>
486 <p>Worker MPM'nin en son geliştirme sürümleri ve
487 <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> gibi bazı modüller APR'nin atomik API'sini
488 kullanırlar. Bu API, düşük ayarlı evre eşzamanlamasında atomik
491 <p>Öntanımlı olarak, APR bu işlemleri hedef işletim sistemi/işlemci
492 platformunda kullanılabilecek en verimli mekanizmayı kullanarak
493 gerçekleştirir. Günümüz işlemcilerinin çoğu, örneğin, bir atomik
494 karşılaştırma ve takas (CAS) işlemini donanımda gerçekleştirmektedir.
495 Bazı platformlarda APR'nin atomik işlemler için öntanımlı olarak daha
496 yavaş olan mutekslere dayalı gerçeklenimi kullanmasının sebebi eski
497 işlemcilerde bu tür makine kodlarının yokluğudur. Apache'yi bu tür
498 platformalarda günümüz işlemcileriyde çalıştırmayı düşünüyorsanız
499 Apache'yi derlemek için yapılandırırken en hızlı atomik işlemin
500 seçilebilmesi için <code>--enable-nonportable-atomics</code>
501 seçeneğini kullanın:</p>
503 <div class="example"><p><code>
505 ./configure --with-mpm=worker --enable-nonportable-atomics=yes
508 <p><code>--enable-nonportable-atomics</code> seçeneği şu platformlar
513 <li>SPARC üzerinde Solaris<br />
514 APR öntanımlı olarak, SPARC/Solaris üzerinde mutekslere dayalı
515 atomik işlemleri kullanır. Ancak,
516 <code>--enable-nonportable-atomics</code> yapılandırmasını
517 kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas
518 için uygun SPARC v8plus kodunu kullanacak şekilde kod üretilir.
519 Apache'yi bu seçenekle yapılandırırsanız atomik işlemler daha
520 verimli olacak fakat derlenen Apache çalıştırılabiliri sadece
521 UltraSPARC kırmığı üzerinde çalışacaktır.
524 <li>x86 üzerinde Linux<br />
525 APR öntanımlı olarak, Linux üzerinde mutekslere dayalı atomik
526 işlemleri kullanır. Ancak,
527 <code>--enable-nonportable-atomics</code> yapılandırmasını
528 kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas
529 için uygun 486 kodunu kullanacak şekilde kod üretilir. Apache'yi
530 bu seçenekle yapılandırırsanız atomik işlemler daha verimli
531 olacak fakat derlenen Apache çalıştırılabiliri (386 üzerinde
532 değil) sadece 486 ve sonrası kırmıklarda çalışacaktır.
539 <h3><code>mod_status</code> ve <code>ExtendedStatus On</code>
544 <p><code class="module"><a href="../mod/mod_status.html">mod_status</a></code> modülünü derlemiş ve Apache'yi
545 yapılandırır ve çalıştırırken <code>ExtendedStatus On</code> satırını
546 da kullanmışsanız Apache her istek üzerinde
547 <code>gettimeofday(2)</code> (veya işletim sistemine bağlı olarak
548 <code>time(2)</code>) çağrısından başka (1.3 öncesinde) fazladan
549 defalarca <code>time(2)</code> çağrıları yapacaktır. Bu çağrılarla
550 durum raporununun zamanlama bilgilerini içermesi sağlanır. Başarımı
551 arttırmak için <code>ExtendedStatus off</code> yapın (zaten öntanımlı
556 <h3><code>accept</code> dizgilemesi ve çok soketli işlem</h3>
560 <div class="warning"><h3>Uyarı:</h3>
561 <p>Bu bölüm, Apache HTTP sunucusunun 2.x sürümlerinde yapılan
562 değişikliklere göre tamamen güncellenmemiştir. Bazı bilgiler hala
563 geçerliyse de lütfen dikkatli kullanınız.</p>
566 <p>Burada Unix soket arayüzü gerçeklenirken ihmal edilen bir durumdan
567 bahsedeceğiz. HTTP sunucunuzun çok sayıda adresten çok sayıda portu
568 dinlemek için çok sayıda <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> yönergesi kullanmakta olduğunu varsayalım. Her
569 soketi çalıştığını görmek için denerken Apache bağlantı için
570 <code>select(2)</code> kullanacaktır. <code>select(2)</code> çağrısı
571 bu soketin üzerinde <em>sıfır</em> veya <em>en azından bir</em>
572 bağlantının beklemekte olduğu anlamına gelir. Apache'nin modeli çok
573 sayıda çocuk süreç içerir ve boşta olanların tümünde aynı anda yeni
574 bağlantılar denenebilir. Gerçekte çalışan kod bu olmasa da meramımızı
575 anlatmak için kodun şöyle bir şey olduğunu varsayabiliriz:</p>
577 <div class="example"><p><code>
579 <span class="indent">
581 <span class="indent">
582 fd_set accept_fds;<br />
584 FD_ZERO (&accept_fds);<br />
585 for (i = first_socket; i <= last_socket; ++i) {<br />
586 <span class="indent">
587 FD_SET (i, &accept_fds);<br />
590 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br />
591 if (rc < 1) continue;<br />
592 new_connection = -1;<br />
593 for (i = first_socket; i <= last_socket; ++i) {<br />
594 <span class="indent">
595 if (FD_ISSET (i, &accept_fds)) {<br />
596 <span class="indent">
597 new_connection = accept (i, NULL, NULL);<br />
598 if (new_connection != -1) break;<br />
603 if (new_connection != -1) break;<br />
606 process the new_connection;<br />
611 <p>Bu özet gerçeklenim bir takım açlık sorunlarına sebep olur. Bu
612 döngünün çalışması sırasında aynı anda çok sayıda çocuk süreç yeniden
613 çağrılır ve istekler arasında kalan çoğu çocuk da <code>select</code>
614 ile engellenir. Engellenen tüm bu çocuklar soketlerden herhangi biri
615 üzerinde tek bir istek göründüğünde <code>select</code> tarafından
616 uyandırılıp işleme sokulmak üzere döndürülürler (uyandırılan çocuk
617 sayısı işletim sistemine ve zamanlama ayarlarına göre değişiklik
618 gösterir). Bunların hepsi döngüye katılıp bağlantı kabul etmeye
619 (<code>accept</code>) çalışırlar. Fakat içlerinden yalnız biri
620 (sadece bir bağlantı isteğinin mevcut olduğu varsayımıyla) bunu
621 başarabilir. Kalanının bağlantı kabul etmesi (<code>accept</code>)
622 engellenir. Bu durum, bu çocukları istekleri başka başka soketlerden
623 değil mecburen tek bir soketten kabul etmeye kilitler ve bu soket
624 üzerinde yeni bir istek belirip uyandırılana kadar bu durumda
625 kalırlar. Bu açlık sorunu ilk olarak <a href="http://bugs.apache.org/index/full/467">PR#467</a> sayılı raporla
626 belgelenmiştir. Bu sorunun en az iki çözümü vardır.</p>
628 <p>Çözümün biri engellenmeyen soket kullanımıdır. Bu durumda
629 <code>accept</code> çocukları engellemeyecek ve yapılan bir
630 bağlantının ardından diğer çocuklar durumları değişmeksizin bağlantı
631 beklemeye devam edeceklerdir. Fakat bu durum işlemci zamanının boşa
632 harcanmasına sebep olur. Seçilmiş (<code>select</code>) boşta on
633 çocuğun olduğunu ve bir bağlantı geldiğini varsayalım. Kalan dokuz
634 çocuk işine devam edip bağlantı kabul etmeyi (<code>accept</code>)
635 deneyecek, başarızsız olacak, dönecek başa, tekrar seçilecek
636 (<code>select</code>) ve böyle hiçbir iş yapmadan dönüp duracaktır. Bu
637 arada hizmet sunmakta olanlar da işlerini bitirdikten sonra bu
638 döngüdeki yerlerini alacaklardır. Aynı kutunun içinde boşta bir sürü
639 işlemciniz (çok işlemcili sistemler) yoksa bu çözüm pek verimli
642 <p>Diğer çözüm ise Apache tarafından kullanılan çözüm olup, girdiyi
643 bir iç döngüde sıraya sokmaktır. Döngü aşağıda örneklenmiştir (farklar
646 <div class="example"><p><code>
648 <span class="indent">
649 <strong>accept_mutex_on ();</strong><br />
651 <span class="indent">
652 fd_set accept_fds;<br />
654 FD_ZERO (&accept_fds);<br />
655 for (i = first_socket; i <= last_socket; ++i) {<br />
656 <span class="indent">
657 FD_SET (i, &accept_fds);<br />
660 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br />
661 if (rc < 1) continue;<br />
662 new_connection = -1;<br />
663 for (i = first_socket; i <= last_socket; ++i) {<br />
664 <span class="indent">
665 if (FD_ISSET (i, &accept_fds)) {<br />
666 <span class="indent">
667 new_connection = accept (i, NULL, NULL);<br />
668 if (new_connection != -1) break;<br />
673 if (new_connection != -1) break;<br />
676 <strong>accept_mutex_off ();</strong><br />
677 process the new_connection;<br />
682 <p><code>accept_mutex_on</code> ve <code>accept_mutex_off</code> <a id="serialize" name="serialize">işlevleri</a> bir karşılıklı red
683 semoforu oluştururlar. Mutekse aynı anda sadece bir çocuk sahip
684 olabilir. Bu muteksleri gerçeklemek için çeşitli seçenekler vardır.
685 Seçim, <code>src/conf.h</code> (1.3 öncesi) veya
686 <code>src/include/ap_config.h</code> (1.3 ve sonrası) dosyasında
687 tanımlanmıştır. Bazı mimariler bir kilitleme seçeneğine sahip
688 değildir. Böyle mimarilerde çok sayıda <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> yönergesi kullanmak güvenilir
691 <p><code class="directive"><a href="../mod/mpm_common.html#acceptmutex">AcceptMutex</a></code> yönergesi,
692 seçilen muteks gerçeklenimini çalışma anında değiştirmek için
696 <dt><code>AcceptMutex flock</code></dt>
699 <p>Bu yöntem, bir kilit dosyasını kilitlemek için
700 <code>flock(2)</code> sistem çağrısını kullanır (Kilit dosyasının
701 yeri <code class="directive"><a href="../mod/mpm_common.html#lockfile">LockFile</a></code>
702 yönergesiyle belirtilir).</p>
705 <dt><code>AcceptMutex fcntl</code></dt>
708 <p>Bu yöntem, bir kilit dosyasını kilitlemek için
709 <code>fcntl(2)</code> sistem çağrısını kullanır (Kilit dosyasının
710 yeri <code class="directive"><a href="../mod/mpm_common.html#lockfile">LockFile</a></code>
711 yönergesiyle belirtilir).</p>
714 <dt><code>AcceptMutex sysvsem</code></dt>
717 <p>(1.3 ve sonrası) Bu yöntem muteksi gerçeklemek için SysV tarzı
718 semaforları kullanır. Maalesef, SysV tarzı semaforların bazı yan
719 etkileri vardır. Bunlardan biri Apache'nin semaforu temizlemeden
720 ölme ihtimalidir (<code>ipcs(8)</code> kılavuz sayfasına bakınız).
721 Diğer biri, CGI'lerin sunucu ile aynı kullanıcı kimliğini
722 kullanmaları nedeniyle semafor arayüzünün hizmet reddi
723 saldırılarına açık olmasıdır (<code class="program"><a href="../programs/suexec.html">suexec</a></code> veya
724 <code>cgiwrapper</code> gibi bir şeyler kullanmadıkça bütün
725 CGI'ler için söz konusudur). Bu sebeple bu yöntem IRIX haricinde
726 hiçbir mimaride kullanılmaz (önceki ikisi çoğu IRIX makine için
727 elde edilmesi imkansız derecede pahalı olduğundan).</p>
730 <dt><code>AcceptMutex pthread</code></dt>
733 <p>(1.3 ve sonrası) Bu yöntem POSIX mutekslerini kullanır ve POSIX
734 evreleri belirtiminin tamamen gerçeklendiği mimarilerde çalışması
735 gerekirse de sadece Solaris (2.5 ve sonrası) üzerinde ve sadece
736 belli yapılandırmalarla çalışmakta gibi görünmektedir. Bunu
737 denemişseniz sunucunuzun çöktüğünü ve yanıt vermediğini
738 görmüşsünüzdür. Sadece duruk içerikli sunucular iyi
742 <dt><code>AcceptMutex posixsem</code></dt>
745 <p>(2.0 ve sonrası) Bu yöntem POSIX semaforlarını kullanır. Eğer
746 işlem sırasında bir evre muteks kaynaklı parçalama arızalarıyla
747 karşı karşıya kalırsa HTTP sunucusunun çökmesiyle semaforun sahibi
753 <p>Eğer sisteminiz yukarıda bahsedilenler dışında başka bir dizgileme
754 yöntemi kullanıyorsa bununla ilgili kodun APR'ye eklenmesi girilen
755 zahmete değecektir.</p>
757 <p>Başka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceğinden
758 (yani belli sayıda sürece izin verilemeyeceğinden) asla
759 gerçeklenmemiştir. Bu sadece, aynı anda çok sayıda çocuk sürecin
760 çalışabileceği ve dolayısıyla band genişliğinin tüm yönleriyle
761 kullanılabileceği çok işlemcili sistemlerde ilginç olabilirdi. Bu
762 gelecekte incelenmeye değer bir konu olmakla beraber çok sayıda HTTP
763 sunucusunun aynı anda aynı amaca hizmet edecek şekilde çalışması
764 standart olarak pek mümkün görülmediğinden bu olasılık çok
767 <p>En yüksek başarımı elde etmek için ideal olanı sunucuları
768 çalıştırırken çok sayıda <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> yönergesi kullanmamaktır. Fakat siz yine de
769 okumaya devam edin.</p>
773 <h3><code>accept</code> dizgilemesi - tek soket</h3>
777 <p>Çok soketli sunucular için yukarıda açıklananlar iyi güzel de tek
778 soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir
779 sorunları olmaması gerekir. Çünkü yeni bir bağlantı gelene kadar tüm
780 çocuklar <code>accept(2)</code> ile engellenirler dolayısıyla hiçbir
781 açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son
782 kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde
783 bahsedilenle hemen hemen aynı "boşa dönüp durma" davranışı mevcuttur.
784 Çoğu TCP yığıtı bu yolu gerçeklemiştir. Çekirdek, yeni bir bağlantı
785 ortaya çıktığında <code>accept</code> ile engellenen tüm süreçleri
786 uyandırır. Bu süreçlerden bağlantıyı alan kullanıcı bölgesine geçerken
787 çekirdek içinde döngüde olan diğerleri de yeni bağlantı keşfedilene
788 kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı
789 bölgesindeki kodlara görünür değildir ama bu olmadıkları anlamına
790 gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boşa
791 döngünün sebep olduğu gereksiz işlemci yükü sorununu içinde
794 <p>Bununla birlikte, tek soketli durumda bile bundan daha verimli bir
795 davranış sergileyen bir çok mimari bulduk. Bu aslında hemen hemen her
796 durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü
797 denemelerde (128MB bellekli çift Pentium pro 166 işlemcili makinede
798 Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiş duruma göre
799 saniyede %3 daha az istekle sonuçlandığı gösterilmiştir. Fakat
800 dizgilenmemiş tek soket durumunda her istekte 100ms'lik ek bir gecikme
801 olduğu görülmüştür. Bu gecikmenin sebebi muhtemelen uzun mesafeli
802 hatlar olup sadece yerel ağlarda söz konusudur. Tek soketli
803 dizgilemeyi geçersiz kılmak için
804 <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> tanımlarsanız tek
805 soketli sunucularda artık dizgileme yapılmayacaktır.</p>
809 <h3>Kapatmayı zamana yaymak</h3>
813 <p><a href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt">draft-ietf-http-connection-00.txt</a> taslağının 8. bölümünde
814 bahsedildiği gibi, bir HTTP sunucusunun protokolü <strong>güvenilir
815 şekilde</strong> gerçeklemesi için her iki yöndeki iletişimi
816 birbirinden bağımsız olarak (iki yönlü bir TCP bağlantısının her
817 yarısını diğerinden bağımsız olarak) kapatması gerekir. Bu olgu başka
818 sunucular tarafından çoğunlukla dikkate alınmaz fakat Apache'nin 1.2
819 sürümünden beri gerektiği gibi gerçeklenmektedir.</p>
821 <p>Bu özellik Apache'ye eklendiğinde Unix'in çeşitli sürümlerinde
822 uzgörüsüzlükten dolayı bir takım geçici telaş sorunlarına sebep oldu.
823 TCP belirtimi <code>FIN_WAIT_2</code> durumunda bir zaman aşımından
824 bahsetmez ama yasaklamaz da. Zaman aşımı olmayan sistemlerde, Apache
825 1.2 çoğu soketin sonsuza kadar <code>FIN_WAIT_2</code> durumunda
826 takılıp kalmasına sebep olur. Çoğu durumda, satıcıdan sağlanan en son
827 TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni
828 yama dağıtmadığı durumlarda (örneğin, SunOS4 -- bir kaynak lisansı ile
829 insanlar bunu kendileri yamayabilirse de) bu özelliği devre dışı
830 bırakmaya karar verdik.</p>
832 <p>Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri
833 <code>SO_LINGER</code> soket seçeneğidir. Bu işin kaderi buymuş gibi
834 görünürse de çoğu TCP/IP yığıtında bu gerektiği gibi
835 gerçeklenmemiştir. Bu yığıtlar üzerinde, bu yöntemin, doğru bir
836 gerçeklenimle bile (örneğin, Linux 2.0.31) sonraki çözümden daha
837 pahalı olduğu ortaya çıkmıştır.</p>
839 <p>Çoğunlukla, Apache bunu (<code>http_main.c</code> içindeki)
840 <code>lingering_close</code> adında bir işlevle gerçekler. Bu işlev
841 kabaca şöyle görünür:</p>
843 <div class="example"><p><code>
844 void lingering_close (int s)<br />
846 <span class="indent">
847 char junk_buffer[2048];<br />
849 /* gönderen tarafı kapat */<br />
850 shutdown (s, 1);<br />
852 signal (SIGALRM, lingering_death);<br />
856 <span class="indent">
857 /* s'i okumak için, 2 saniyelik zaman aşımı ile seç */<br />
858 select (s for reading, 2 second timeout);<br />
859 /* Hata oluşmuşsa döngüden çık */<br />
860 if (error) break;<br />
861 /* s okumak için hazırsa */<br />
862 if (s is ready for reading) {<br />
863 <span class="indent">
864 if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {<br />
865 <span class="indent">
869 /* geri kalan herşey burada */<br />
880 <p>Bağlantı sonunda bu doğal olarak biraz daha masrafa yol açar, fakat
881 güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın
882 kullanılmaya başlanması ve tüm bağlantıların kalıcı hale gelmesiyle bu
883 gerçeklenim daha fazla istek üzerinden kendi masrafını
884 karşılayacaktır. Ateşle oynamak ve bu özelliği devre dışı bırakmak
885 isterseniz <code>NO_LINGCLOSE</code>'u tanımlayabilirsiniz, fakat bu
886 asla önerilmez. Özellikle, HTTP/1.1'den itibaren boruhatlı kalıcı
887 bağlantıların <code>lingering_close</code> kullanmaya başlaması mutlak
888 bir gerekliliktir (ve <a href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
889 boruhatlı bağlantıların daha hızlı</a> olması nedeniyle bu
890 bağlantıları desteklemek isteyebilirsiniz).</p>
894 <h3>Çetele Dosyası</h3>
898 <p>Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birşey
899 üzerinden haberleşirler. Bunun en mükemmel şekilde paylaşımlı bellekte
900 gerçeklenmesi gerekir. Eriştiğimiz veya portlarını ayrıntılı olarak
901 belirttiğimiz işletim sistemleri için bu, genellikle paylaşımlı bellek
902 kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir
903 disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaş olmanın yanı
904 sıra güvenilir de değildir (ve daha az özelliğe sahiptir). Mimarinizin
905 <code>src/main/conf.h</code> dosyasını inceleyin ve
906 <code>USE_MMAP_SCOREBOARD</code> veya
907 <code>USE_SHMGET_SCOREBOARD</code>'a bakın. Bu ikisinden birinin (ve
908 yanı sıra sırasıyla <code>HAVE_MMAP</code> veya
909 <code>HAVE_SHMGET</code>'in) tanımlanmış olması, sağlanan paylaşımlı
910 bellek kodunu etkinleştirir. Eğer sisteminiz diğer türdeki paylaşımlı
911 belleğe sahipse, <code>src/main/http_main.c</code> dosyasını açıp,
912 Apache'de bu belleği kullanması gereken kanca işlevleri ekleyin (Bize
913 de bir yama yollayın, lütfen).</p>
915 <div class="note">Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2
916 sürümüne kadar paylaşımlı belleği kullanmaya başlamamıştı. Bu kusur,
917 Apache'nin Linux üzerindeki erken dönem sürümlerinin davranışlarının
918 zayıf ve güvenilmez olmasına yol açmıştı.</div>
922 <h3>DYNAMIC_MODULE_LIMIT</h3>
926 <p>Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz
927 (burayı okuyan ve sunucunuzun başarımını son kırıntısına kadar
928 arttırmakla ilgilenen biriyseniz bunu düşünmezsiniz), sunucunuzu
929 derlerken seçenekler arasına <code>-DDYNAMIC_MODULE_LIMIT=0</code>
930 seçeneğini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen
931 modüller için ayrılacak belleği kazanmış olacaksınız.</p>
935 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
936 <div class="section">
937 <h2><a name="trace" id="trace">Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi</a></h2>
941 <p>Burada, Solaris 8 üzerinde worker MPM'li Apache 2.0.38'in bir sistem
942 çağrısı izlenmektedir. Bu izleme şu komutla elde edilmiştir:</p>
944 <div class="example"><p><code>
945 truss -l -p <var>httpd_çocuk_pidi</var>.
948 <p><code>-l</code> seçeneği, truss'a hafif bir sürecin yaptığı her
949 sistem çağrısını (hafif süreç -- HS -- Solaris'in bir çekirdek seviyesi
950 evreleme biçimi) günlüğe yazmasını söyler.</p>
952 <p>Diğer sistemlerin sistem çağrılarını izleyen farklı araçları vardır
953 (<code>strace</code>, <code>ktrace</code>, <code>par</code> gibi).
954 Bunlar da benzer çıktılar üretirler.</p>
956 <p>Bu izleme sırasında, bir istemci httpd'den 10 KB'lık duruk bir dosya
957 talebinde bulunmuştur. Duruk olmayan veya içerik uzlaşımlı isteklerin
958 izleme kayıtları vahşice (bazı durumlarda epey çirkince) farklı
961 <div class="example"><p><code>
962 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) (uykuda...)<br />
963 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
966 <p>Bu izlemede, dinleyen evre HS #67 içinde çalışmaktadır.</p>
968 <div class="note"><code>accept(2)</code> dizgelemesinin olmayışına dikkat edin.
969 Özellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe,
970 öntanımlı olarak dizgeleştirilmemiş bir accept çağrısı kullanır.</div>
972 <div class="example"><p><code>
973 /65: lwp_park(0x00000000, 0) = 0<br />
974 /67: lwp_unpark(65, 1) = 0
977 <p>Bağlantının kabul edilmesiyle, dinleyici evre isteği yerine getirmek
978 üzere bir worker evresini uyandırır. Bu izlemede, isteği yerine getiren
979 worker evresi HS #65'e aittir.</p>
981 <div class="example"><p><code>
982 /65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
985 <p>Sanal konakların gerçeklenimi sırasında, Apache'nin, bağlantıları
986 kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir.
987 Çoğu durumda bu çağrıyı bertaraf etmek mümkündür (hiç sanal konağın
988 olmadığı veya <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code>
989 yönergelerinin mutlak adreslerle kullanıldığı durumlarda). Fakat bu en
990 iyilemeleri yapmak için henüz bir çaba harcanmamıştır.</p>
992 <div class="example"><p><code>
993 /65: brk(0x002170E8) = 0<br />
994 /65: brk(0x002190E8) = 0
997 <p><code>brk(2)</code> çağrıları devingen bellekten bellek ayırır. httpd
998 çoğu isteği yerine getirirken özel bellek ayırıcılar
999 (<code>apr_pool</code> ve <code>apr_bucket_alloc</code>) kullandığından
1000 bunlar bir sistem çağrısı izlemesinde nadiren görünür. Bu izlemede,
1001 httpd henüz yeni başlatıldığından, özel bellek ayırıcıları oluşturmak
1002 için ham bellek bloklarını ayırmak amacıyla <code>malloc(3)</code>
1003 çağrıları yapması gerekir.</p>
1005 <div class="example"><p><code>
1006 /65: fcntl(9, F_GETFL, 0x00000000) = 2<br />
1007 /65: fstat64(9, 0xFAF7B818) = 0<br />
1008 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0<br />
1009 /65: fstat64(9, 0xFAF7B818) = 0<br />
1010 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0<br />
1011 /65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0<br />
1012 /65: fcntl(9, F_SETFL, 0x00000082) = 0
1015 <p>Ardından, worker evresi istemciye (dosya tanıtıcısı 9) engellenmeyen
1016 kipte bir bağlantı açar. <code>setsockopt(2)</code>
1017 ve <code>getsockopt(2)</code> çağrıları, Solaris libc'sinin soketler
1018 üzerindeki <code>fcntl(2)</code> çağrısı yanında birer yan etkiden
1021 <div class="example"><p><code>
1022 /65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
1025 <p>Worker evresi istemciden isteği okur.</p>
1027 <div class="example"><p><code>
1028 /65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0<br />
1029 /65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10
1032 <p>Bu httpd <code>Options FollowSymLinks</code> ve <code>AllowOverride
1033 None</code> ile yapılandırılmıştır. Bu bakımdan, ne istenen dosya ile
1034 sonuçlanan yol üzerindeki her dizinde <code>lstat(2)</code> çağrısına ne
1035 de <code>.htaccess</code> dosyalarına bakılmasına gerek vardır.
1036 <code>stat(2)</code> çağrısı basitçe dosya için şunları doğrulamak
1037 amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin değil normal bir
1040 <div class="example"><p><code>
1041 /65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
1044 <p>Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt başlığını tek bir
1045 <code>sendfilev(2)</code> sistem çağrısı ile göndermektedir. Dosya
1046 gönderim işleminin anlamı sistemden sisteme değişiklik gösterir. Bazı
1047 sistemlerde, <code>sendfile(2)</code> çağrısından önce başlıkları
1048 göndermek için <code>write(2)</code> veya <code>writev(2)</code>
1049 çağrısı yapmak gerekir.</p>
1051 <div class="example"><p><code>
1052 /65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
1055 <p>Bu <code>write(2)</code> çağrısı isteği erişim günlüğüne kaydeder. Bu
1056 izlemede eksik olan tek şey, <code>time(2)</code> çağrısıdır. Apache
1057 1.3'ün aksine, Apache 2.x zamana bakmak için
1058 <code>gettimeofday(3)</code> çağırısını kullanır. Linux ve Solaris gibi
1059 bazı işletim sistemleri, <code>gettimeofday</code> işlevinin, sıradan
1060 bir sistem çağrısından daha fazla götürüsü olmayan en iyilenmiş bir
1061 gerçeklenimine sahiptir.</p>
1063 <div class="example"><p><code>
1064 /65: shutdown(9, 1, 1) = 0<br />
1065 /65: poll(0xFAF7B980, 1, 2000) = 1<br />
1066 /65: read(9, 0xFAF7BC20, 512) = 0<br />
1070 <p>Burada worker evresi bağlantıyı zamana yaymaktadır.</p>
1072 <div class="example"><p><code>
1073 /65: close(10) = 0<br />
1074 /65: lwp_park(0x00000000, 0) (uykuda...)
1077 <p>Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra
1078 dinleyici evre tarafından başka bir bağlantı atanıncaya kadar beklemeye
1081 <div class="example"><p><code>
1082 /67: accept(3, 0x001FEB74, 0x001FEB94, 1) (uykuda...)
1085 <p>Bu arada, dinleyici evre bağlantıyı bir worker evresine atar atamaz
1086 başka bir bağlantıyı beklemeye başlar (Mevcut tüm evreler meşgulse
1087 dinleyici evreyi baskılayan worker MPM'nin akış denetim şemasına konu
1088 olur). Bu izlemede görünmüyor olsa da sonraki <code>accept(2)</code>
1089 çağrısı, yeni bağlantı kabul eden worker evresine paralel olarak
1090 yapılabilir (aşırı yük durumlarında normal olarak, bu yapılır).</p>
1093 <div class="bottomlang">
1094 <p><span>Mevcut Diller: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> |
1095 <a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
1096 <a href="../tr/misc/perf-tuning.html" title="Türkçe"> tr </a></p>
1097 </div><div id="footer">
1098 <p class="apache">Copyright 2009 The Apache Software Foundation.<br /><a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a> altında lisanslıdır.</p>
1099 <p class="menu"><a href="../mod/">Modüller</a> | <a href="../mod/directives.html">Yönergeler</a> | <a href="../faq/">SSS</a> | <a href="../glossary.html">Terimler</a> | <a href="../sitemap.html">Site Haritası</a></p></div>