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