1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
4 <!-- English Revision: 1174747:1673917 (outdated) -->
5 <!-- =====================================================
6 Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
7 Reviewed by: Orhan Berent <berent belgeler.org>
8 ========================================================== -->
11 Licensed to the Apache Software Foundation (ASF) under one or more
12 contributor license agreements. See the NOTICE file distributed with
13 this work for additional information regarding copyright ownership.
14 The ASF licenses this file to You under the Apache License, Version 2.0
15 (the "License"); you may not use this file except in compliance with
16 the License. You may obtain a copy of the License at
18 http://www.apache.org/licenses/LICENSE-2.0
20 Unless required by applicable law or agreed to in writing, software
21 distributed under the License is distributed on an "AS IS" BASIS,
22 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
23 See the License for the specific language governing permissions and
24 limitations under the License.
27 <manualpage metafile="perf-tuning.xml.meta">
28 <parentdocument href="./">Çeşitli Belgeler</parentdocument>
30 <title>Apache’de Başarımın Arttırılması</title>
34 <p>Apache 2.x, esneklik, taşınabilirlik ve başarım arasında bir denge
35 sağlamak üzere tasarlanmış genel amaçlı bir HTTP sunucusudur. Başka
36 sunucularla kıyaslama denemelerinde öne geçmek üzere tasarlanmamış
37 olsa da Apache 2.x gerçek yaşamda karşılaşılan pek çok durumda oldukça
38 yüksek bir başarıma ulaşacak yetenektedir.</p>
40 <p>Apache 1.3 ile karşılaştırıldığında 2.x sürümleri toplam veri hızını
41 ve ölçeklenebilirliği arttırmak için pek çok en iyileme seçeneği
42 içerir. Bu iyileştirmelerin pek çoğu zaten öntanımlı olarak etkin
43 olmakla birlikte derleme ve kullanım sırasında başarımı önemli ölçüde
44 etkileyebilen yapılandırma seçenekleri de mevcuttur. Bu belgede, bir
45 Apache 2.x kurulumunda sunucu yöneticisinin sunucunun başarımını
46 arttırmak amacıyla yapılandırma sırasında neler yapabileceğinden
47 bahsedilmiştir. Bu yapılandırma seçeneklerinden bazıları, httpd’nin
48 donanımın ve işletim sisteminin olanaklarından daha iyi
49 yararlanabilmesini sağlarken bir kısmı da daha hızlı bir sunum için
50 yöneticinin işlevsellikten ödün verebilmesini olanaklı kılar.</p>
54 <section id="hardware">
56 <title>Donanım ve İşletim Sistemi ile İlgili Konular</title>
58 <p>HTTP sunucusunun başarımını etkileyen en önemli donanım bellektir
59 (RAM). Bir HTTP sunucusu asla takaslama yapmamalıdır. Çünkü takaslama,
60 kullanıcının "yeterince hız" umduğu noktada sunumun gecikmesine sebep
61 olur. Böyle bir durumda kullanıcılar yüklemeyi durdurup tekrar
62 başlatma eğilimindedirler; sonuçta yük daha da artar. <directive
63 module="mpm_common" >MaxRequestWorkers</directive> yönergesinin değerini
64 değiştirerek takaslamaya sebep olabilecek kadar çok çocuk süreç
65 oluşturulmasını engelleyebilirsiniz ve böyle bir durumda bunu mutlaka
66 yapmalısınız. Bunun için yapacağınız işlem basittir: <code>top</code>
67 benzeri bir araç üzerinden çalışan süreçlerinizin bir listesini alıp
68 Apache süreçlerinizin ortalama büyüklüğünü saptayıp, mevcut bellekten
69 bir kısmını diğer süreçler için ayırdıktan sonra kalan miktarı bu
70 değere bölerseniz yönergeye atayacağınız değeri bulmuş olursunuz.</p>
72 <p>Donanımın diğer unsurları için kararı siz verin: Daha hızlı işlemci,
73 daha hızlı ağ kartı, daha hızlı disk; daha hızlının ne kadar hızlı
74 olacağını deneyimlerinize bağlı olarak tamamen sizin ihtiyaçlarınız
77 <p>İşletim sistemi seçimi büyük oranda yerel ilgi konusudur. Fakat yine
78 de, genelde yararlılığı kanıtlanmış bazı kurallar bu seçimde size
79 yardımcı olabilir:</p>
83 <p>Seçtiğiniz işletim sisteminin (çekirdeğin) en son kararlı
84 sürümünü çalıştırın. Bir çok işletim sistemi, son yıllarda TCP
85 yığıtları ve evre kütüphaneleri ile ilgili belirgin iyileştirmeler
86 yapmışlar ve yapmaktadırlar.</p>
90 <p>İşletim sisteminiz <code>sendfile</code>(2) sistem çağrısını
91 destekliyorsa bunun etkinleştirilebildiği sürümün kurulu olması
92 önemlidir. (Örneğin, Linux için bu, Linux 2.4 ve sonraki sürümler
93 anlamına gelirken, Solaris için Solaris 8’den önceki sürümlerin
94 yamanması gerektirdiği anlamına gelmektedir.)
95 <code>sendfile</code> işlevinin desteklendiği sistemlerde Apache 2
96 duruk içeriği daha hızlı teslim etmek ve işlemci kullanımını
97 düşürmek amacıyla bu işlevselliği kullanacaktır.</p>
103 <section id="runtime">
105 <title>Çalışma Anı Yapılandırması ile İlgili Konular</title>
109 <module>mod_dir</module>
110 <module>mpm_common</module>
111 <module>mod_status</module>
114 <directive module="core">AllowOverride</directive>
115 <directive module="mod_dir">DirectoryIndex</directive>
116 <directive module="core">HostnameLookups</directive>
117 <directive module="core">EnableMMAP</directive>
118 <directive module="core">EnableSendfile</directive>
119 <directive module="core">KeepAliveTimeout</directive>
120 <directive module="prefork">MaxSpareServers</directive>
121 <directive module="prefork">MinSpareServers</directive>
122 <directive module="core">Options</directive>
123 <directive module="mpm_common">StartServers</directive>
129 <title><code>HostnameLookups</code> ve DNS ile ilgili diğer konular</title>
131 <p>Apache 1.3 öncesinde, <directive module="core"
132 >HostnameLookups</directive> yönergesinin öntanımlı değeri
133 <code>On</code> idi. İstek yerine getirilmeden önce bir DNS sorgusu
134 yapılmasını gerektirmesi sebebiyle bu ayarlama her istekte bir
135 miktar gecikmeye sebep olurdu. Apache 1.3’ten itibaren yönergenin
136 öntanımlı değeri <code>Off</code> yapılmıştır. Eğer günlük
137 dosyalarınızda konak isimlerinin bulunmasını isterseniz, Apache ile
138 birlikte gelen <program>logresolve</program> programını
139 kullanabileceğiniz gibi günlük raporlarını çözümleyen Apache ile
140 gelmeyen programlardan herhangi birini de kullanabilirsiniz.</p>
142 <p>Günlük dosyaları üzerindeki bu işlemi sunucu makinesi dışında
143 günlük dosyasının bir kopyası üzerinde yapmanızı öneririz. Aksi
144 takdirde sunucunuzun başarımı önemli ölçüde etkilenebilir.</p>
146 <p><directive module="mod_access_compat">Allow</directive> veya
147 <directive module="mod_access_compat">Deny</directive>
148 yönergelerinde IP adresi yerine bir konak veya alan ismi
149 belirtirseniz, iki DNS sorguluk bir bedel ödersiniz (biri normal,
150 diğeri IP taklidine karşı ters DNS sorgusu). Başarımı en iyilemek
151 için bu yönergelerde mümkün olduğunca isim yerine IP adreslerini
154 <p><directive module="core" >HostnameLookups</directive>
155 yönergelerinin <code><Location /server-status></code> gibi
156 bölüm yönergelerinin içinde de yer alabileceğini unutmayın. Bu gibi
157 durumlarda DNS sorguları sadece istek kuralla eşleştiği takdirde
158 yapılacaktır. Aşağıdaki örnekte <code>.html</code> ve
159 <code>.cgi</code> dosyalarına yapılan istekler hariç DNS sorguları
160 iptal edilmektedir:</p>
163 HostnameLookups off<br />
164 <Files ~ "\.(html|cgi)$"><br />
166 HostnameLookups on<br />
171 <p>Yine de bazı CGI’lerin DNS isimlerine ihtiyacı olursa bu CGI’lerin
172 bu ihtiyaçlarına yönelik olarak <code>gethostbyname</code> çağrıları
173 yapabileceğini gözardı etmeyiniz.</p>
177 <section id="symlinks">
179 <title><code>FollowSymLinks</code> ve
180 <code>SymLinksIfOwnerMatch</code></title>
182 <p>URL uzayınızda geçerli olmak üzere bir <code>Options
183 FollowSymLinks</code> yoksa veya <code>Options
184 SymLinksIfOwnerMatch</code> yönergeleri varsa, Apache her sembolik
185 bağın üzerinde bazı sınamalar yapmak için ek bir sistem çağrısından
186 başka istenen her dosya için de ayrı bir çağrı yapacaktır.</p>
188 <example><title>Örnek:</title>
189 DocumentRoot /siteler/htdocs<br />
190 <Directory /><br />
192 Options SymLinksIfOwnerMatch<br />
197 <p>Bu durumda <code>/index.html</code> için bir istek yapıldığında
198 Apache, <code>/siteler</code>, <code>/siteler/htdocs</code> ve<br />
199 <code>/siteler/htdocs/index.html</code> üzerinde
200 <code>lstat</code>(2) çağrıları yapacaktır. <code>lstat</code>
201 sonuçları önbelleğe kaydedilmediğinden bu işlem her istekte
202 yinelenecektir. Amacınız gerçekten sembolik bağları güvenlik
203 açısından sınamaksa bunu şöyle yapabilirsiniz:</p>
206 DocumentRoot /siteler/htdocs<br />
207 <Directory /><br />
209 Options FollowSymLinks<br />
211 </Directory><br />
213 <Directory /sitem/htdocs><br />
215 Options -FollowSymLinks +SymLinksIfOwnerMatch<br />
220 <p>Böylece <directive module="core">DocumentRoot</directive> altındaki
221 dosyalar için fazladan bir çağrı yapılmasını engellemiş olursunuz.
222 Eğer bazı bölümlerde <directive module="mod_alias"
223 >Alias</directive>, <directive module="mod_rewrite"
224 >RewriteRule</directive> gibi yönergeler üzerinden belge kök
225 dizininizin dışında kalan dosya yollarına sahipseniz benzer
226 işlemleri onlar için de yapmalısınız. Sembolik bağ koruması yapmamak
227 suretiyle başarımı arttırmak isterseniz, <code>FollowSymLinks</code>
228 seçeneğini her yerde etkin kılın ve
229 <code>SymLinksIfOwnerMatch</code> seçeneğini asla
230 etkinleştirmeyin.</p>
234 <section id="htaccess">
236 <title><code>AllowOverride</code></title>
238 <p>Genellikle <code>.htaccess</code> dosyaları üzerinden yapıldığı
239 gibi URL uzayınızda geçersizleştirmelere izin veriyorsanız, Apache
240 her dosya bileşeni için bu <code>.htaccess</code> dosyalarını açmaya
243 <example><title>Örnek:</title>
244 DocumentRoot /siteler/htdocs<br />
245 <Directory /><br />
247 AllowOverride all<br />
252 <p>Bu durumda <code>/index.html</code> sayfasına yapılan bir istek için
253 Apache, <code>/.htaccess</code>, <code>/siteler/.htaccess</code> ve
254 <code>/siteler/htdocs/.htaccess</code> dosyalarını açmaya
255 çalışacaktır. Çözüm <code>Options FollowSymLinks</code> durumunun
256 benzeridir; başarımı arttırmak için dosya sisteminizin her yerinde
257 <code>AllowOverride None</code> olsun.</p>
261 <section id="negotiation">
263 <title>Dil Uzlaşımı</title>
265 <p>Başarımı son kırıntısına kadar arttırmak istiyorsanız, mümkünse
266 içerik dili uzlaşımı da yapmayın. Dil uzlaşımından yararlanmak
267 isterken büyük başarım kayıplarına uğrayabilirsiniz. Böyle bir
268 durumda sunucunun başarımını arttırmanın tek bir yolu vardır. </p>
274 <p>Yukarıdaki gibi bir dosya ismi kalıbı kullanmak yerine, aşağıdaki
275 gibi seçenekleri tam bir liste halinde belirtin:</p>
278 DirectoryIndex index.cgi index.pl index.shtml index.html
281 <p>Buradaki sıralama öncelik sırasını belirler; yani,
282 öncelikli olmasını istediğiniz seçeneği listenin başına
285 <p>İstenen dosya için <code>MultiViews</code> kullanarak dizini
286 taratmak yerine, gerekli bilgiyi tek bir dosyadan okutmak suretiyle
287 başarımı arttırabilirsiniz. Bu amaçla türeşlem
288 (<code>type-map</code>) dosyaları kullanmanız yeterli olacaktır.</p>
290 <p>Sitenizde içerik dili uzlaşımına gerek varsa, bunu <code>Options
291 MultiViews</code> yönergesi üzerinden değil, türeşlem dosyaları
292 kullanarak yapmayı deneyin. İçerik dili uzlaşımı ve türeşlem
293 dosyalarının oluşturulması hakkında daha ayrıntılı bilgi edinmek
294 için <a href="../content-negotiation.html">İçerik Uzlaşımı</a>
295 belgesine bakınız.</p>
301 <title>Bellek Eşlemleri</title>
303 <p>Apache’nin SSI sayfalarında olduğu gibi teslim edilecek dosyanın
304 içeriğine bakma gereği duyduğu durumlarda, eğer işletim sistemi
305 <code>mmap</code>(2) ve benzerlerini destekliyorsa çekirdek normal
306 olarak dosyayı belleğe kopyalayacaktır.</p>
308 <p>Bazı platformlarda bu belleğe eşleme işlemi başarımı arttırsa da
309 başarımın veya httpd kararlılığının zora girdiği durumlar
314 <p>Bazı işletim sistemlerinde işlemci sayısı artışına bağlı
315 olarak, <code>mmap</code> işlevi <code>read</code>(2) kadar iyi
316 ölçeklenmemiştir. Örneğin, çok işlemcili Solaris sunucularda
317 <code>mmap</code> iptal edildiği takdirde içeriği sunucu
318 tarafından işlenen dosyalar üzerinde bazen daha hızlı işlem
319 yapılabilmektedir.</p>
323 <p>Belleğe kopyalanacak dosya NFS üzerinden bağlanan bir dosya
324 sistemindeyse ve dosya başka bir NFS istemcisi makine tarafından
325 silinmiş veya dosyanın boyutu değiştirilmişse sunucunuz dosyaya
326 tekrar erişmeye çalıştığında bir hata alabilecektir.</p>
330 <p>Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriği
331 sunucu tarafından işlenecek dosyaların belleğe kopyalanmaması için
332 yapılandırmanıza <code>EnableMMAP off</code> satırını ekleyiniz.
333 (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen
334 yönergelerdendir.)</p>
340 <title><code>sendfile</code></title>
342 <p>Apache’nin duruk dosyalarda olduğu gibi teslim edilecek dosyanın
343 içeriğine bakmadığı durumlarda, eğer işletim sistemi
344 <code>sendfile</code>(2) desteğine sahipse çekirdek normal olarak bu
345 desteği kullanacaktır.</p>
347 <p>Bazı platformlarda <code>sendfile</code> kullanımı, okuma ve yazma
348 işlemlerinin ayrı ayrı yapılmamasını sağlasa da
349 <code>sendfile</code> kullanımının httpd kararlılığını bozduğu bazı
350 durumlar sözkonusudur:</p>
354 <p>Bazı platformlar derleme sisteminin saptayamadığı bozuk bir
355 <code>sendfile</code> desteğine sahip olabilir. Özellikle
356 derleme işleminin başka bir platformda yapılıp
357 <code>sendfile</code> desteği bozuk bir makineye kurulum
358 yapıldığı durumlarda bu desteğin bozuk olduğu
359 saptanamayacaktır.</p>
362 <p>Çekirdek, NFS üzerinden erişilen ağ dosyalarını kendi önbelleği
363 üzerinden gerektiği gibi sunamayabilir.</p>
367 <p>Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriğin
368 <code>sendfile</code> desteğiyle teslim edilmemesi için
369 yapılandırmanıza <code>EnableSendfile off</code> satırını ekleyiniz.
370 (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen
371 yönergelerdendir.)</p>
375 <section id="process">
377 <title>Süreç Oluşturma</title>
379 <p>Apache 1.3 öncesinde <directive module="prefork"
380 >MinSpareServers</directive>, <directive module="prefork"
381 >MaxSpareServers</directive> ve <directive module="mpm_common"
382 >StartServers</directive> ayarları, başka sunucularla kıyaslama
383 denemelerinde olağanüstü kötü sonuçlar alınmasına sebep olmaktaydı.
384 Özellikle uygulanan yükü karşılamaya yetecek sayıda çocuk süreç
385 oluşturulması aşamasında Apache’nin elde ettiği ivme bunlardan
386 biriydi. Başlangıçta <directive module="mpm_common"
387 >StartServers</directive> yönergesiyle belli sayıda süreç
388 oluşturulduktan sonra her saniyede bir tane olmak üzere <directive
389 module="prefork">MinSpareServers</directive> sayıda çocuk süreç
390 oluşturulmaktaydı. Örneğin, aynı anda 100 isteğe yanıt vermek için
391 <directive module="mpm_common" >StartServers</directive>
392 yönergesinin öntanımlı değeri olarak başta <code>5</code> süreç
393 oluşturulduğundan kalan süreçler için 95 saniye geçmesi gerekirdi.
394 Sık sık yeniden başlatılmadıklarından dolayı gerçek hayatta
395 sunucuların başına gelen de buydu. Başka sunucularla kıyaslama
396 denemelerinde ise işlem sadece on dakika sürmekte ve içler acısı
397 sonuçlar alınmaktaydı.</p>
399 <p>Saniyede bir kuralı, sunucunun yeni çocukları oluşturması sırasında
400 sistemin aşırı meşgul duruma düşmemesi için alınmış bir önlemdi.
401 Makine çocuk süreç oluşturmakla meşgul edildiği sürece isteklere
402 yanıt veremeyecektir. Böylesi bir durum Apache’nin başarımını
403 kötüleştirmekten başka işe yaramayacaktır. Apache 1.3’te saniyede
404 bir kuralı biraz esnetildi. Yeni gerçeklenimde artık bir süreç
405 oluşturduktan bir saniye sonra iki süreç, bir saniye sonra dört
406 süreç oluşturulmakta ve işlem, saniyede 32 çocuk süreç oluşturulur
407 duruma gelene kadar böyle ivmelenmektedir. Çocuk süreç oluşturma
408 işlemi <directive module="prefork" >MinSpareServers</directive>
409 değerine ulaşılınca durmaktadır.</p>
411 <p>Bu, <directive module="prefork" >MinSpareServers</directive>,
412 <directive module="prefork" >MaxSpareServers</directive> ve
413 <directive module="mpm_common" >StartServers</directive> ayarlarıyla
414 oynamayı neredeyse gereksiz kılacak kadar iyi sonuçlar verecek gibi
415 görünmektedir. Saniyede 4 çocuktan fazlası oluşturulmaya
416 başlandığında hata günlüğüne bazı iletiler düşmeye başlar. Bu
417 iletilerin sayısı çok artarsa bu ayarlarla oynama vakti gelmiş
418 demektir. Bunun için <module>mod_status</module> çıktısını bir
419 kılavuz olarak kullanabilirsiniz.</p>
421 <p>Süreç oluşturmayla ilgili olarak süreç ölümü <directive
422 module="mpm_common">MaxConnectionsPerChild</directive> değeri ile
423 sağlanır. Bu değer öntanımlı olarak <code>0</code> olup, çocuk süreç
424 başına istek sayısının sınırsız olduğu anlamına gelir. Eğer
425 yapılandırmanızda bu değeri <code>30</code> gibi çok düşük bir
426 değere ayarlarsanız bunu hemen kaldırmak zorunda kalabilirsiniz.
427 Sunucunuzu SunOS veya Solaris’in eski bir sürümü üzerinde
428 çalıştırıyorsanız bellek kaçaklarına sebep olmamak için bu değeri
429 <code>10000</code> ile sınırlayınız.</p>
431 <p>Kalıcı bağlantı özelliğini kullanıyorsanız, çocuk süreçler zaten
432 açık bağlantılardan istek beklemekte olacaklardır. <directive
433 module="core">KeepAliveTimeout</directive> yönergesinin öntanımlı
434 değeri <code>5</code> saniye olup bu etkiyi en aza indirmeye yönelik
435 süredir. Burada ağ band genişliği ile sunucu kaynaklarının kullanımı
436 arasında bir seçim yapmak söz konusudur. Hiçbir şey umurunuzda
438 href="http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-4.html">
439 çoğu ayrıcalığın yitirilmesi pahasına</a> bu değeri rahatça
440 <code>60</code> saniyenin üzerine çıkarabilirsiniz.</p>
445 <section id="compiletime">
446 <title>Derleme Sırasında Yapılandırma ile İlgili Konular</title>
449 <title>MPM Seçimi</title>
451 <p>Apache 2.x, <a href="../mpm.html">Çok Süreçlilik Modülleri</a>
452 (MPM) adı verilen eklemlenebilir çok görevlilik modellerini
453 destekler. Apache’yi derlerken bu MPM’lerden birini seçmeniz
454 gerekir. MPM’lerden bazıları platformlara özeldir:
455 <module>mpm_netware</module>, <module>mpmt_os2</module> ve
456 <module>mpm_winnt</module>. Unix
457 benzeri sistemler için ise seçebileceğiniz modül sayısı birden
458 fazladır. MPM seçiminin httpd’nin hızında ve ölçeklenebilirliğinde
459 bazı etkileri olabilir:</p>
463 <li><module>worker</module> modülü her biri çok evreli çok sayıda
464 çocuk süreç kullanımını destekler. Her evre aynı anda tek bir
465 bağlantıya hizmet sunar. Aynı hizmeti daha az bellek harcayarak
466 vermesi nedeniyle yüksek trafiğe sahip sunucularda
467 <module>prefork</module> modülüne göre daha iyi bir seçimdir.</li>
469 <li><module>prefork</module> modülü her biri tek bir evreye sahip
470 çok sayıda çocuk süreç kullanımını destekler. Her süreç aynı anda
471 tek bir bağlantıya hizmet sunar. Çoğu sistemde daha hızlı olması
472 nedeniyle <module>worker</module> modülüne göre daha iyi bir seçim
473 olarak görünürse de bunu daha fazla bellek kullanarak sağlar.
474 <module>prefork</module> modülünün evresiz tasarımının
475 <module>worker</module> modülüne göre bazı yararlı tarafları
476 vardır: Çok evreli sistemlerde güvenilir olmayan üçüncü parti
477 modülleri kullanabilir ve evrelerde hata ayıklamanın yetersiz
478 kaldığı platformlarda hatalarını ayıklamak daha kolaydır.</li>
482 <p>Bu modüller ve diğerleri hakkında daha ayrıntılı bilgi edinmek için
483 <a href="../mpm.html">Çok Süreçlilik Modülleri</a> belgesine
488 <section id="modules">
490 <title>Modüller</title>
492 <p>Bellek kullanımı başarım konusunda önemli olduğundan gerçekte
493 kullanmadığınız modülleri elemeye çalışmalısınız. Modülleri birer <a
494 href="../dso.html">DSO</a> olarak derlediyseniz <directive
495 module="mod_so">LoadModule</directive> yönergesinin bulunduğu satırı
496 açıklama haline getirmeniz modülden kurtulmanız için yeterli
497 olacaktır. Modülleri bu şekilde kaldırarak onların yokluğunda
498 sitenizin hala işlevlerini yerine getirdiğini görme şansına da
499 kavuşmuş olursunuz.</p>
501 <p>Ancak, eğer modülleri Apache çalıştırılabilirinin içine
502 gömmüşseniz istenmeyen modülleri kaldırmak için Apache'yi yeniden
503 derlemeniz gerekir.</p>
505 <p>Bu noktada bir soru akla gelebilir: Hangi modüller gerekli,
506 hangileri değil? Bu sorunun yanıtı şüphesiz siteden siteye değişir.
507 Ancak, olmazsa olmaz moüller olarak <module>mod_mime</module>,
508 <module>mod_dir</module> ve <module>mod_log_config</module>
509 modüllerini sayabiliriz. Bunlardan <code>mod_log_config</code>
510 olmadan da bir sitenin çalışabileceğinden hareketle bu modülün
511 varlığı isteğe bağlı olsa da bu modülü kaldırmanızı önermiyoruz.</p>
517 <title>Atomik İşlemler</title>
519 <p>Worker MPM'nin en son geliştirme sürümleri ve
520 <module>mod_cache</module> gibi bazı modüller APR'nin atomik API'sini
521 kullanırlar. Bu API, düşük ayarlı evre eşzamanlamasında atomik
524 <p>Öntanımlı olarak, APR bu işlemleri hedef işletim sistemi/işlemci
525 platformunda kullanılabilecek en verimli mekanizmayı kullanarak
526 gerçekleştirir. Günümüz işlemcilerinin çoğu, örneğin, bir atomik
527 karşılaştırma ve takas (CAS) işlemini donanımda gerçekleştirmektedir.
528 Bazı platformlarda APR'nin atomik işlemler için öntanımlı olarak daha
529 yavaş olan mutekslere dayalı gerçeklenimi kullanmasının sebebi eski
530 işlemcilerde bu tür makine kodlarının yokluğudur. Apache'yi bu tür
531 platformalarda günümüz işlemcileriyde çalıştırmayı düşünüyorsanız
532 Apache'yi derlemek için yapılandırırken en hızlı atomik işlemin
533 seçilebilmesi için <code>--enable-nonportable-atomics</code>
534 seçeneğini kullanın:</p>
538 ./configure --with-mpm=worker --enable-nonportable-atomics=yes
541 <p><code>--enable-nonportable-atomics</code> seçeneği şu platformlar
546 <li>SPARC üzerinde Solaris<br />
547 APR öntanımlı olarak, SPARC/Solaris üzerinde mutekslere dayalı
548 atomik işlemleri kullanır. Ancak,
549 <code>--enable-nonportable-atomics</code> yapılandırmasını
550 kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas
551 için uygun SPARC v8plus kodunu kullanacak şekilde kod üretilir.
552 Apache'yi bu seçenekle yapılandırırsanız atomik işlemler daha
553 verimli olacak fakat derlenen Apache çalıştırılabiliri sadece
554 UltraSPARC kırmığı üzerinde çalışacaktır.
557 <li>x86 üzerinde Linux<br />
558 APR öntanımlı olarak, Linux üzerinde mutekslere dayalı atomik
559 işlemleri kullanır. Ancak,
560 <code>--enable-nonportable-atomics</code> yapılandırmasını
561 kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas
562 için uygun 486 kodunu kullanacak şekilde kod üretilir. Apache'yi
563 bu seçenekle yapılandırırsanız atomik işlemler daha verimli
564 olacak fakat derlenen Apache çalıştırılabiliri (386 üzerinde
565 değil) sadece 486 ve sonrası kırmıklarda çalışacaktır.
574 <title><code>mod_status</code> ve <code>ExtendedStatus On</code>
577 <p><module>mod_status</module> modülünü derlemiş ve Apache'yi
578 yapılandırır ve çalıştırırken <code>ExtendedStatus On</code> satırını
579 da kullanmışsanız Apache her istek üzerinde
580 <code>gettimeofday(2)</code> (veya işletim sistemine bağlı olarak
581 <code>time(2)</code>) çağrısından başka (1.3 öncesinde) fazladan
582 defalarca <code>time(2)</code> çağrıları yapacaktır. Bu çağrılarla
583 durum raporununun zamanlama bilgilerini içermesi sağlanır. Başarımı
584 arttırmak için <code>ExtendedStatus off</code> yapın (zaten öntanımlı
591 <title><code>accept</code> dizgilemesi ve çok soketli işlem</title>
593 <note type="warning"><title>Uyarı:</title>
594 <p>Bu bölüm, Apache HTTP sunucusunun 2.x sürümlerinde yapılan
595 değişikliklere göre tamamen güncellenmemiştir. Bazı bilgiler hala
596 geçerliyse de lütfen dikkatli kullanınız.</p>
599 <p>Burada Unix soket arayüzü gerçeklenirken ihmal edilen bir durumdan
600 bahsedeceğiz. HTTP sunucunuzun çok sayıda adresten çok sayıda portu
601 dinlemek için çok sayıda <directive module="mpm_common"
602 >Listen</directive> yönergesi kullanmakta olduğunu varsayalım. Her
603 soketi çalıştığını görmek için denerken Apache bağlantı için
604 <code>select(2)</code> kullanacaktır. <code>select(2)</code> çağrısı
605 bu soketin üzerinde <em>sıfır</em> veya <em>en azından bir</em>
606 bağlantının beklemekte olduğu anlamına gelir. Apache'nin modeli çok
607 sayıda çocuk süreç içerir ve boşta olanların tümünde aynı anda yeni
608 bağlantılar denenebilir. Gerçekte çalışan kod bu olmasa da meramımızı
609 anlatmak için kodun şöyle bir şey olduğunu varsayabiliriz:</p>
616 fd_set accept_fds;<br />
618 FD_ZERO (&accept_fds);<br />
619 for (i = first_socket; i <= last_socket; ++i) {<br />
621 FD_SET (i, &accept_fds);<br />
624 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br />
625 if (rc < 1) continue;<br />
626 new_connection = -1;<br />
627 for (i = first_socket; i <= last_socket; ++i) {<br />
629 if (FD_ISSET (i, &accept_fds)) {<br />
631 new_connection = accept (i, NULL, NULL);<br />
632 if (new_connection != -1) break;<br />
637 if (new_connection != -1) break;<br />
640 process the new_connection;<br />
645 <p>Bu özet gerçeklenim bir takım açlık sorunlarına sebep olur. Bu
646 döngünün çalışması sırasında aynı anda çok sayıda çocuk süreç yeniden
647 çağrılır ve istekler arasında kalan çoğu çocuk da <code>select</code>
648 ile engellenir. Engellenen tüm bu çocuklar soketlerden herhangi biri
649 üzerinde tek bir istek göründüğünde <code>select</code> tarafından
650 uyandırılıp işleme sokulmak üzere döndürülürler (uyandırılan çocuk
651 sayısı işletim sistemine ve zamanlama ayarlarına göre değişiklik
652 gösterir). Bunların hepsi döngüye katılıp bağlantı kabul etmeye
653 (<code>accept</code>) çalışırlar. Fakat içlerinden yalnız biri
654 (sadece bir bağlantı isteğinin mevcut olduğu varsayımıyla) bunu
655 başarabilir. Kalanının bağlantı kabul etmesi (<code>accept</code>)
656 engellenir. Bu durum, bu çocukları istekleri başka başka soketlerden
657 değil mecburen tek bir soketten kabul etmeye kilitler ve bu soket
658 üzerinde yeni bir istek belirip uyandırılana kadar bu durumda
659 kalırlar. Bu açlık sorunu ilk olarak <a
660 href="http://bugs.apache.org/index/full/467">PR#467</a> sayılı raporla
661 belgelenmiştir. Bu sorunun en az iki çözümü vardır.</p>
663 <p>Çözümün biri engellenmeyen soket kullanımıdır. Bu durumda
664 <code>accept</code> çocukları engellemeyecek ve yapılan bir
665 bağlantının ardından diğer çocuklar durumları değişmeksizin bağlantı
666 beklemeye devam edeceklerdir. Fakat bu durum işlemci zamanının boşa
667 harcanmasına sebep olur. Seçilmiş (<code>select</code>) boşta on
668 çocuğun olduğunu ve bir bağlantı geldiğini varsayalım. Kalan dokuz
669 çocuk işine devam edip bağlantı kabul etmeyi (<code>accept</code>)
670 deneyecek, başarızsız olacak, dönecek başa, tekrar seçilecek
671 (<code>select</code>) ve böyle hiçbir iş yapmadan dönüp duracaktır. Bu
672 arada hizmet sunmakta olanlar da işlerini bitirdikten sonra bu
673 döngüdeki yerlerini alacaklardır. Aynı kutunun içinde boşta bir sürü
674 işlemciniz (çok işlemcili sistemler) yoksa bu çözüm pek verimli
677 <p>Diğer çözüm ise Apache tarafından kullanılan çözüm olup, girdiyi
678 bir iç döngüde sıraya sokmaktır. Döngü aşağıda örneklenmiştir (farklar
684 <strong>accept_mutex_on ();</strong><br />
687 fd_set accept_fds;<br />
689 FD_ZERO (&accept_fds);<br />
690 for (i = first_socket; i <= last_socket; ++i) {<br />
692 FD_SET (i, &accept_fds);<br />
695 rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br />
696 if (rc < 1) continue;<br />
697 new_connection = -1;<br />
698 for (i = first_socket; i <= last_socket; ++i) {<br />
700 if (FD_ISSET (i, &accept_fds)) {<br />
702 new_connection = accept (i, NULL, NULL);<br />
703 if (new_connection != -1) break;<br />
708 if (new_connection != -1) break;<br />
711 <strong>accept_mutex_off ();</strong><br />
712 process the new_connection;<br />
717 <p><code>accept_mutex_on</code> ve <code>accept_mutex_off</code> <a
718 id="serialize" name="serialize">işlevleri</a> bir karşılıklı red
719 semoforu oluştururlar. Mutekse aynı anda sadece bir çocuk sahip
720 olabilir. Bu muteksleri gerçeklemek için çeşitli seçenekler vardır.
721 Seçim, <code>src/conf.h</code> (1.3 öncesi) veya
722 <code>src/include/ap_config.h</code> (1.3 ve sonrası) dosyasında
723 tanımlanmıştır. Bazı mimariler bir kilitleme seçeneğine sahip
724 değildir. Böyle mimarilerde çok sayıda <directive
725 module="mpm_common">Listen</directive> yönergesi kullanmak güvenilir
728 <p><directive module="core">Mutex</directive> yönergesi,
729 <code>mpm-accept</code> muteks gerçeklenimini çalışma anında değiştirmek
730 için kullanılabilir. Farklı muteks gerçeklenimleri ile ilgili hususlar
731 bu yönergede belgelenmiştir.</p>
733 <p>Başka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceğinden
734 (yani belli sayıda sürece izin verilemeyeceğinden) asla
735 gerçeklenmemiştir. Bu sadece, aynı anda çok sayıda çocuk sürecin
736 çalışabileceği ve dolayısıyla band genişliğinin tüm yönleriyle
737 kullanılabileceği çok işlemcili sistemlerde ilginç olabilirdi. Bu
738 gelecekte incelenmeye değer bir konu olmakla beraber çok sayıda HTTP
739 sunucusunun aynı anda aynı amaca hizmet edecek şekilde çalışması
740 standart olarak pek mümkün görülmediğinden bu olasılık çok
743 <p>En yüksek başarımı elde etmek için ideal olanı sunucuları
744 çalıştırırken çok sayıda <directive module="mpm_common"
745 >Listen</directive> yönergesi kullanmamaktır. Fakat siz yine de
746 okumaya devam edin.</p>
752 <title><code>accept</code> dizgilemesi - tek soket</title>
754 <p>Çok soketli sunucular için yukarıda açıklananlar iyi güzel de tek
755 soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir
756 sorunları olmaması gerekir. Çünkü yeni bir bağlantı gelene kadar tüm
757 çocuklar <code>accept(2)</code> ile engellenirler dolayısıyla hiçbir
758 açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son
759 kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde
760 bahsedilenle hemen hemen aynı "boşa dönüp durma" davranışı mevcuttur.
761 Çoğu TCP yığıtı bu yolu gerçeklemiştir. Çekirdek, yeni bir bağlantı
762 ortaya çıktığında <code>accept</code> ile engellenen tüm süreçleri
763 uyandırır. Bu süreçlerden bağlantıyı alan kullanıcı bölgesine geçerken
764 çekirdek içinde döngüde olan diğerleri de yeni bağlantı keşfedilene
765 kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı
766 bölgesindeki kodlara görünür değildir ama bu olmadıkları anlamına
767 gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boşa
768 döngünün sebep olduğu gereksiz işlemci yükü sorununu içinde
771 <p>Bununla birlikte, tek soketli durumda bile bundan daha verimli bir
772 davranış sergileyen bir çok mimari bulduk. Bu aslında hemen hemen her
773 durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü
774 denemelerde (128MB bellekli çift Pentium pro 166 işlemcili makinede
775 Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiş duruma göre
776 saniyede %3 daha az istekle sonuçlandığı gösterilmiştir. Fakat
777 dizgilenmemiş tek soket durumunda her istekte 100ms'lik ek bir gecikme
778 olduğu görülmüştür. Bu gecikmenin sebebi muhtemelen uzun mesafeli
779 hatlar olup sadece yerel ağlarda söz konusudur. Tek soketli
780 dizgilemeyi geçersiz kılmak için
781 <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> tanımlarsanız tek
782 soketli sunucularda artık dizgileme yapılmayacaktır.</p>
788 <title>Kapatmayı zamana yaymak</title>
790 <p><a href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt"
791 >draft-ietf-http-connection-00.txt</a> taslağının 8. bölümünde
792 bahsedildiği gibi, bir HTTP sunucusunun protokolü <strong>güvenilir
793 şekilde</strong> gerçeklemesi için her iki yöndeki iletişimi
794 birbirinden bağımsız olarak (iki yönlü bir TCP bağlantısının her
795 yarısını diğerinden bağımsız olarak) kapatması gerekir.</p>
797 <p>Bu özellik Apache'ye eklendiğinde Unix'in çeşitli sürümlerinde
798 uzgörüsüzlükten dolayı bir takım geçici telaş sorunlarına sebep oldu.
799 TCP belirtimi <code>FIN_WAIT_2</code> durumunda bir zaman aşımından
800 bahsetmez ama yasaklamaz da. Zaman aşımı olmayan sistemlerde, Apache
801 1.2 çoğu soketin sonsuza kadar <code>FIN_WAIT_2</code> durumunda
802 takılıp kalmasına sebep olur. Çoğu durumda, satıcıdan sağlanan en son
803 TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni
804 yama dağıtmadığı durumlarda (örneğin, SunOS4 -- bir kaynak lisansı ile
805 insanlar bunu kendileri yamayabilirse de) bu özelliği devre dışı
806 bırakmaya karar verdik.</p>
808 <p>Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri
809 <code>SO_LINGER</code> soket seçeneğidir. Bu işin kaderi buymuş gibi
810 görünürse de çoğu TCP/IP yığıtında bu gerektiği gibi
811 gerçeklenmemiştir. Bu yığıtlar üzerinde, bu yöntemin, doğru bir
812 gerçeklenimle bile (örneğin, Linux 2.0.31) sonraki çözümden daha
813 pahalı olduğu ortaya çıkmıştır.</p>
815 <p>Çoğunlukla, Apache bunu (<code>http_main.c</code> içindeki)
816 <code>lingering_close</code> adında bir işlevle gerçekler. Bu işlev
817 kabaca şöyle görünür:</p>
820 void lingering_close (int s)<br />
823 char junk_buffer[2048];<br />
825 /* gönderen tarafı kapat */<br />
826 shutdown (s, 1);<br />
828 signal (SIGALRM, lingering_death);<br />
833 /* s'i okumak için, 2 saniyelik zaman aşımı ile seç */<br />
834 select (s for reading, 2 second timeout);<br />
835 /* Hata oluşmuşsa döngüden çık */<br />
836 if (error) break;<br />
837 /* s okumak için hazırsa */<br />
838 if (s is ready for reading) {<br />
840 if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {<br />
845 /* geri kalan herşey burada */<br />
856 <p>Bağlantı sonunda bu doğal olarak biraz daha masrafa yol açar, fakat
857 güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın
858 kullanılmaya başlanması ve tüm bağlantıların kalıcı hale gelmesiyle bu
859 gerçeklenim daha fazla istek üzerinden kendi masrafını
860 karşılayacaktır. Ateşle oynamak ve bu özelliği devre dışı bırakmak
861 isterseniz <code>NO_LINGCLOSE</code>'u tanımlayabilirsiniz, fakat bu
862 asla önerilmez. Özellikle, HTTP/1.1'den itibaren boruhatlı kalıcı
863 bağlantıların <code>lingering_close</code> kullanmaya başlaması mutlak
864 bir gerekliliktir (ve <a
865 href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
866 boruhatlı bağlantıların daha hızlı</a> olması nedeniyle bu
867 bağlantıları desteklemek isteyebilirsiniz).</p>
873 <title>Çetele Dosyası</title>
875 <p>Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birşey
876 üzerinden haberleşirler. Bunun en mükemmel şekilde paylaşımlı bellekte
877 gerçeklenmesi gerekir. Eriştiğimiz veya portlarını ayrıntılı olarak
878 belirttiğimiz işletim sistemleri için bu, genellikle paylaşımlı bellek
879 kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir
880 disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaş olmanın yanı
881 sıra güvenilir de değildir (ve daha az özelliğe sahiptir). Mimarinizin
882 <code>src/main/conf.h</code> dosyasını inceleyin ve
883 <code>USE_MMAP_SCOREBOARD</code> veya
884 <code>USE_SHMGET_SCOREBOARD</code>'a bakın. Bu ikisinden birinin (ve
885 yanı sıra sırasıyla <code>HAVE_MMAP</code> veya
886 <code>HAVE_SHMGET</code>'in) tanımlanmış olması, sağlanan paylaşımlı
887 bellek kodunu etkinleştirir. Eğer sisteminiz diğer türdeki paylaşımlı
888 belleğe sahipse, <code>src/main/http_main.c</code> dosyasını açıp,
889 Apache'de bu belleği kullanması gereken kanca işlevleri ekleyin (Bize
890 de bir yama yollayın, lütfen).</p>
892 <note>Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2
893 sürümüne kadar paylaşımlı belleği kullanmaya başlamamıştı. Bu kusur,
894 Apache'nin Linux üzerindeki erken dönem sürümlerinin davranışlarının
895 zayıf ve güvenilmez olmasına yol açmıştı.</note>
901 <title>DYNAMIC_MODULE_LIMIT</title>
903 <p>Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz
904 (burayı okuyan ve sunucunuzun başarımını son kırıntısına kadar
905 arttırmakla ilgilenen biriyseniz bunu düşünmezsiniz), sunucunuzu
906 derlerken seçenekler arasına <code>-DDYNAMIC_MODULE_LIMIT=0</code>
907 seçeneğini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen
908 modüller için ayrılacak belleği kazanmış olacaksınız.</p>
916 <title>Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi</title>
918 <p>Burada, Solaris 8 üzerinde worker MPM'li Apache 2.0.38'in bir sistem
919 çağrısı izlenmektedir. Bu izleme şu komutla elde edilmiştir:</p>
922 truss -l -p <var>httpd_çocuk_pidi</var>.
925 <p><code>-l</code> seçeneği, truss'a hafif bir sürecin yaptığı her
926 sistem çağrısını (hafif süreç -- HS -- Solaris'in bir çekirdek seviyesi
927 evreleme biçimi) günlüğe yazmasını söyler.</p>
929 <p>Diğer sistemlerin sistem çağrılarını izleyen farklı araçları vardır
930 (<code>strace</code>, <code>ktrace</code>, <code>par</code> gibi).
931 Bunlar da benzer çıktılar üretirler.</p>
933 <p>Bu izleme sırasında, bir istemci httpd'den 10 KB'lık duruk bir dosya
934 talebinde bulunmuştur. Duruk olmayan veya içerik uzlaşımlı isteklerin
935 izleme kayıtları vahşice (bazı durumlarda epey çirkince) farklı
939 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) (uykuda...)<br />
940 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
943 <p>Bu izlemede, dinleyen evre HS #67 içinde çalışmaktadır.</p>
945 <note><code>accept(2)</code> dizgelemesinin olmayışına dikkat edin.
946 Özellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe,
947 öntanımlı olarak dizgeleştirilmemiş bir accept çağrısı kullanır.</note>
950 /65: lwp_park(0x00000000, 0) = 0<br />
951 /67: lwp_unpark(65, 1) = 0
954 <p>Bağlantının kabul edilmesiyle, dinleyici evre isteği yerine getirmek
955 üzere bir worker evresini uyandırır. Bu izlemede, isteği yerine getiren
956 worker evresi HS #65'e aittir.</p>
959 /65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
962 <p>Sanal konakların gerçeklenimi sırasında, Apache'nin, bağlantıları
963 kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir.
964 Çoğu durumda bu çağrıyı bertaraf etmek mümkündür (hiç sanal konağın
965 olmadığı veya <directive module="mpm_common">Listen</directive>
966 yönergelerinin mutlak adreslerle kullanıldığı durumlarda). Fakat bu en
967 iyilemeleri yapmak için henüz bir çaba harcanmamıştır.</p>
970 /65: brk(0x002170E8) = 0<br />
971 /65: brk(0x002190E8) = 0
974 <p><code>brk(2)</code> çağrıları devingen bellekten bellek ayırır. httpd
975 çoğu isteği yerine getirirken özel bellek ayırıcılar
976 (<code>apr_pool</code> ve <code>apr_bucket_alloc</code>) kullandığından
977 bunlar bir sistem çağrısı izlemesinde nadiren görünür. Bu izlemede,
978 httpd henüz yeni başlatıldığından, özel bellek ayırıcıları oluşturmak
979 için ham bellek bloklarını ayırmak amacıyla <code>malloc(3)</code>
980 çağrıları yapması gerekir.</p>
983 /65: fcntl(9, F_GETFL, 0x00000000) = 2<br />
984 /65: fstat64(9, 0xFAF7B818) = 0<br />
985 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0<br />
986 /65: fstat64(9, 0xFAF7B818) = 0<br />
987 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0<br />
988 /65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0<br />
989 /65: fcntl(9, F_SETFL, 0x00000082) = 0
992 <p>Ardından, worker evresi istemciye (dosya tanıtıcısı 9) engellenmeyen
993 kipte bir bağlantı açar. <code>setsockopt(2)</code>
994 ve <code>getsockopt(2)</code> çağrıları, Solaris libc'sinin soketler
995 üzerindeki <code>fcntl(2)</code> çağrısı yanında birer yan etkiden
999 /65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
1002 <p>Worker evresi istemciden isteği okur.</p>
1005 /65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0<br />
1006 /65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10
1009 <p>Bu httpd <code>Options FollowSymLinks</code> ve <code>AllowOverride
1010 None</code> ile yapılandırılmıştır. Bu bakımdan, ne istenen dosya ile
1011 sonuçlanan yol üzerindeki her dizinde <code>lstat(2)</code> çağrısına ne
1012 de <code>.htaccess</code> dosyalarına bakılmasına gerek vardır.
1013 <code>stat(2)</code> çağrısı basitçe dosya için şunları doğrulamak
1014 amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin değil normal bir
1018 /65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
1021 <p>Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt başlığını tek bir
1022 <code>sendfilev(2)</code> sistem çağrısı ile göndermektedir. Dosya
1023 gönderim işleminin anlamı sistemden sisteme değişiklik gösterir. Bazı
1024 sistemlerde, <code>sendfile(2)</code> çağrısından önce başlıkları
1025 göndermek için <code>write(2)</code> veya <code>writev(2)</code>
1026 çağrısı yapmak gerekir.</p>
1029 /65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
1032 <p>Bu <code>write(2)</code> çağrısı isteği erişim günlüğüne kaydeder. Bu
1033 izlemede eksik olan tek şey, <code>time(2)</code> çağrısıdır. Apache
1034 1.3'ün aksine, Apache 2.x zamana bakmak için
1035 <code>gettimeofday(3)</code> çağırısını kullanır. Linux ve Solaris gibi
1036 bazı işletim sistemleri, <code>gettimeofday</code> işlevinin, sıradan
1037 bir sistem çağrısından daha fazla götürüsü olmayan en iyilenmiş bir
1038 gerçeklenimine sahiptir.</p>
1041 /65: shutdown(9, 1, 1) = 0<br />
1042 /65: poll(0xFAF7B980, 1, 2000) = 1<br />
1043 /65: read(9, 0xFAF7BC20, 512) = 0<br />
1047 <p>Burada worker evresi bağlantıyı zamana yaymaktadır.</p>
1050 /65: close(10) = 0<br />
1051 /65: lwp_park(0x00000000, 0) (uykuda...)
1054 <p>Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra
1055 dinleyici evre tarafından başka bir bağlantı atanıncaya kadar beklemeye
1059 /67: accept(3, 0x001FEB74, 0x001FEB94, 1) (uykuda...)
1062 <p>Bu arada, dinleyici evre bağlantıyı bir worker evresine atar atamaz
1063 başka bir bağlantıyı beklemeye başlar (Mevcut tüm evreler meşgulse
1064 dinleyici evreyi baskılayan worker MPM'nin akış denetim şemasına konu
1065 olur). Bu izlemede görünmüyor olsa da sonraki <code>accept(2)</code>
1066 çağrısı, yeni bağlantı kabul eden worker evresine paralel olarak
1067 yapılabilir (aşırı yük durumlarında normal olarak, bu yapılır).</p>