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: 805049:883878 (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" >MaxClients</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="htacess">
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">MaxRequestsPerChild</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="mpm_common">AcceptMutex</directive> yönergesi,
729 seçilen muteks gerçeklenimini çalışma anında değiştirmek için
733 <dt><code>AcceptMutex flock</code></dt>
736 <p>Bu yöntem, bir kilit dosyasını kilitlemek için
737 <code>flock(2)</code> sistem çağrısını kullanır (Kilit dosyasının
738 yeri <directive module="mpm_common" >LockFile</directive>
739 yönergesiyle belirtilir).</p>
742 <dt><code>AcceptMutex fcntl</code></dt>
745 <p>Bu yöntem, bir kilit dosyasını kilitlemek için
746 <code>fcntl(2)</code> sistem çağrısını kullanır (Kilit dosyasının
747 yeri <directive module="mpm_common" >LockFile</directive>
748 yönergesiyle belirtilir).</p>
751 <dt><code>AcceptMutex sysvsem</code></dt>
754 <p>(1.3 ve sonrası) Bu yöntem muteksi gerçeklemek için SysV tarzı
755 semaforları kullanır. Maalesef, SysV tarzı semaforların bazı yan
756 etkileri vardır. Bunlardan biri Apache'nin semaforu temizlemeden
757 ölme ihtimalidir (<code>ipcs(8)</code> kılavuz sayfasına bakınız).
758 Diğer biri, CGI'lerin sunucu ile aynı kullanıcı kimliğini
759 kullanmaları nedeniyle semafor arayüzünün hizmet reddi
760 saldırılarına açık olmasıdır (<program>suexec</program> veya
761 <code>cgiwrapper</code> gibi bir şeyler kullanmadıkça bütün
762 CGI'ler için söz konusudur).</p>
765 <dt><code>AcceptMutex pthread</code></dt>
768 <p>(1.3 ve sonrası) Bu yöntem POSIX mutekslerini kullanır ve POSIX
769 evreleri belirtiminin tamamen gerçeklendiği mimarilerde çalışması
770 gerekirse de sadece Solaris (2.5 ve sonrası) üzerinde ve sadece
771 belli yapılandırmalarla çalışmakta gibi görünmektedir. Bunu
772 denemişseniz sunucunuzun çöktüğünü ve yanıt vermediğini
773 görmüşsünüzdür. Sadece duruk içerikli sunucular iyi
777 <dt><code>AcceptMutex posixsem</code></dt>
780 <p>(2.0 ve sonrası) Bu yöntem POSIX semaforlarını kullanır. Eğer
781 işlem sırasında bir evre muteks kaynaklı parçalama arızalarıyla
782 karşı karşıya kalırsa HTTP sunucusunun çökmesiyle semaforun sahibi
788 <p>Eğer sisteminiz yukarıda bahsedilenler dışında başka bir dizgileme
789 yöntemi kullanıyorsa bununla ilgili kodun APR'ye eklenmesi girilen
790 zahmete değecektir.</p>
792 <p>Başka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceğinden
793 (yani belli sayıda sürece izin verilemeyeceğinden) asla
794 gerçeklenmemiştir. Bu sadece, aynı anda çok sayıda çocuk sürecin
795 çalışabileceği ve dolayısıyla band genişliğinin tüm yönleriyle
796 kullanılabileceği çok işlemcili sistemlerde ilginç olabilirdi. Bu
797 gelecekte incelenmeye değer bir konu olmakla beraber çok sayıda HTTP
798 sunucusunun aynı anda aynı amaca hizmet edecek şekilde çalışması
799 standart olarak pek mümkün görülmediğinden bu olasılık çok
802 <p>En yüksek başarımı elde etmek için ideal olanı sunucuları
803 çalıştırırken çok sayıda <directive module="mpm_common"
804 >Listen</directive> yönergesi kullanmamaktır. Fakat siz yine de
805 okumaya devam edin.</p>
811 <title><code>accept</code> dizgilemesi - tek soket</title>
813 <p>Çok soketli sunucular için yukarıda açıklananlar iyi güzel de tek
814 soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir
815 sorunları olmaması gerekir. Çünkü yeni bir bağlantı gelene kadar tüm
816 çocuklar <code>accept(2)</code> ile engellenirler dolayısıyla hiçbir
817 açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son
818 kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde
819 bahsedilenle hemen hemen aynı "boşa dönüp durma" davranışı mevcuttur.
820 Çoğu TCP yığıtı bu yolu gerçeklemiştir. Çekirdek, yeni bir bağlantı
821 ortaya çıktığında <code>accept</code> ile engellenen tüm süreçleri
822 uyandırır. Bu süreçlerden bağlantıyı alan kullanıcı bölgesine geçerken
823 çekirdek içinde döngüde olan diğerleri de yeni bağlantı keşfedilene
824 kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı
825 bölgesindeki kodlara görünür değildir ama bu olmadıkları anlamına
826 gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boşa
827 döngünün sebep olduğu gereksiz işlemci yükü sorununu içinde
830 <p>Bununla birlikte, tek soketli durumda bile bundan daha verimli bir
831 davranış sergileyen bir çok mimari bulduk. Bu aslında hemen hemen her
832 durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü
833 denemelerde (128MB bellekli çift Pentium pro 166 işlemcili makinede
834 Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiş duruma göre
835 saniyede %3 daha az istekle sonuçlandığı gösterilmiştir. Fakat
836 dizgilenmemiş tek soket durumunda her istekte 100ms'lik ek bir gecikme
837 olduğu görülmüştür. Bu gecikmenin sebebi muhtemelen uzun mesafeli
838 hatlar olup sadece yerel ağlarda söz konusudur. Tek soketli
839 dizgilemeyi geçersiz kılmak için
840 <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> tanımlarsanız tek
841 soketli sunucularda artık dizgileme yapılmayacaktır.</p>
847 <title>Kapatmayı zamana yaymak</title>
849 <p><a href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt"
850 >draft-ietf-http-connection-00.txt</a> taslağının 8. bölümünde
851 bahsedildiği gibi, bir HTTP sunucusunun protokolü <strong>güvenilir
852 şekilde</strong> gerçeklemesi için her iki yöndeki iletişimi
853 birbirinden bağımsız olarak (iki yönlü bir TCP bağlantısının her
854 yarısını diğerinden bağımsız olarak) kapatması gerekir. Bu olgu başka
855 sunucular tarafından çoğunlukla dikkate alınmaz fakat Apache'nin 1.2
856 sürümünden beri gerektiği gibi gerçeklenmektedir.</p>
858 <p>Bu özellik Apache'ye eklendiğinde Unix'in çeşitli sürümlerinde
859 uzgörüsüzlükten dolayı bir takım geçici telaş sorunlarına sebep oldu.
860 TCP belirtimi <code>FIN_WAIT_2</code> durumunda bir zaman aşımından
861 bahsetmez ama yasaklamaz da. Zaman aşımı olmayan sistemlerde, Apache
862 1.2 çoğu soketin sonsuza kadar <code>FIN_WAIT_2</code> durumunda
863 takılıp kalmasına sebep olur. Çoğu durumda, satıcıdan sağlanan en son
864 TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni
865 yama dağıtmadığı durumlarda (örneğin, SunOS4 -- bir kaynak lisansı ile
866 insanlar bunu kendileri yamayabilirse de) bu özelliği devre dışı
867 bırakmaya karar verdik.</p>
869 <p>Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri
870 <code>SO_LINGER</code> soket seçeneğidir. Bu işin kaderi buymuş gibi
871 görünürse de çoğu TCP/IP yığıtında bu gerektiği gibi
872 gerçeklenmemiştir. Bu yığıtlar üzerinde, bu yöntemin, doğru bir
873 gerçeklenimle bile (örneğin, Linux 2.0.31) sonraki çözümden daha
874 pahalı olduğu ortaya çıkmıştır.</p>
876 <p>Çoğunlukla, Apache bunu (<code>http_main.c</code> içindeki)
877 <code>lingering_close</code> adında bir işlevle gerçekler. Bu işlev
878 kabaca şöyle görünür:</p>
881 void lingering_close (int s)<br />
884 char junk_buffer[2048];<br />
886 /* gönderen tarafı kapat */<br />
887 shutdown (s, 1);<br />
889 signal (SIGALRM, lingering_death);<br />
894 /* s'i okumak için, 2 saniyelik zaman aşımı ile seç */<br />
895 select (s for reading, 2 second timeout);<br />
896 /* Hata oluşmuşsa döngüden çık */<br />
897 if (error) break;<br />
898 /* s okumak için hazırsa */<br />
899 if (s is ready for reading) {<br />
901 if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {<br />
906 /* geri kalan herşey burada */<br />
917 <p>Bağlantı sonunda bu doğal olarak biraz daha masrafa yol açar, fakat
918 güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın
919 kullanılmaya başlanması ve tüm bağlantıların kalıcı hale gelmesiyle bu
920 gerçeklenim daha fazla istek üzerinden kendi masrafını
921 karşılayacaktır. Ateşle oynamak ve bu özelliği devre dışı bırakmak
922 isterseniz <code>NO_LINGCLOSE</code>'u tanımlayabilirsiniz, fakat bu
923 asla önerilmez. Özellikle, HTTP/1.1'den itibaren boruhatlı kalıcı
924 bağlantıların <code>lingering_close</code> kullanmaya başlaması mutlak
925 bir gerekliliktir (ve <a
926 href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
927 boruhatlı bağlantıların daha hızlı</a> olması nedeniyle bu
928 bağlantıları desteklemek isteyebilirsiniz).</p>
934 <title>Çetele Dosyası</title>
936 <p>Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birşey
937 üzerinden haberleşirler. Bunun en mükemmel şekilde paylaşımlı bellekte
938 gerçeklenmesi gerekir. Eriştiğimiz veya portlarını ayrıntılı olarak
939 belirttiğimiz işletim sistemleri için bu, genellikle paylaşımlı bellek
940 kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir
941 disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaş olmanın yanı
942 sıra güvenilir de değildir (ve daha az özelliğe sahiptir). Mimarinizin
943 <code>src/main/conf.h</code> dosyasını inceleyin ve
944 <code>USE_MMAP_SCOREBOARD</code> veya
945 <code>USE_SHMGET_SCOREBOARD</code>'a bakın. Bu ikisinden birinin (ve
946 yanı sıra sırasıyla <code>HAVE_MMAP</code> veya
947 <code>HAVE_SHMGET</code>'in) tanımlanmış olması, sağlanan paylaşımlı
948 bellek kodunu etkinleştirir. Eğer sisteminiz diğer türdeki paylaşımlı
949 belleğe sahipse, <code>src/main/http_main.c</code> dosyasını açıp,
950 Apache'de bu belleği kullanması gereken kanca işlevleri ekleyin (Bize
951 de bir yama yollayın, lütfen).</p>
953 <note>Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2
954 sürümüne kadar paylaşımlı belleği kullanmaya başlamamıştı. Bu kusur,
955 Apache'nin Linux üzerindeki erken dönem sürümlerinin davranışlarının
956 zayıf ve güvenilmez olmasına yol açmıştı.</note>
962 <title>DYNAMIC_MODULE_LIMIT</title>
964 <p>Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz
965 (burayı okuyan ve sunucunuzun başarımını son kırıntısına kadar
966 arttırmakla ilgilenen biriyseniz bunu düşünmezsiniz), sunucunuzu
967 derlerken seçenekler arasına <code>-DDYNAMIC_MODULE_LIMIT=0</code>
968 seçeneğini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen
969 modüller için ayrılacak belleği kazanmış olacaksınız.</p>
977 <title>Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi</title>
979 <p>Burada, Solaris 8 üzerinde worker MPM'li Apache 2.0.38'in bir sistem
980 çağrısı izlenmektedir. Bu izleme şu komutla elde edilmiştir:</p>
983 truss -l -p <var>httpd_çocuk_pidi</var>.
986 <p><code>-l</code> seçeneği, truss'a hafif bir sürecin yaptığı her
987 sistem çağrısını (hafif süreç -- HS -- Solaris'in bir çekirdek seviyesi
988 evreleme biçimi) günlüğe yazmasını söyler.</p>
990 <p>Diğer sistemlerin sistem çağrılarını izleyen farklı araçları vardır
991 (<code>strace</code>, <code>ktrace</code>, <code>par</code> gibi).
992 Bunlar da benzer çıktılar üretirler.</p>
994 <p>Bu izleme sırasında, bir istemci httpd'den 10 KB'lık duruk bir dosya
995 talebinde bulunmuştur. Duruk olmayan veya içerik uzlaşımlı isteklerin
996 izleme kayıtları vahşice (bazı durumlarda epey çirkince) farklı
1000 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) (uykuda...)<br />
1001 /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
1004 <p>Bu izlemede, dinleyen evre HS #67 içinde çalışmaktadır.</p>
1006 <note><code>accept(2)</code> dizgelemesinin olmayışına dikkat edin.
1007 Özellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe,
1008 öntanımlı olarak dizgeleştirilmemiş bir accept çağrısı kullanır.</note>
1011 /65: lwp_park(0x00000000, 0) = 0<br />
1012 /67: lwp_unpark(65, 1) = 0
1015 <p>Bağlantının kabul edilmesiyle, dinleyici evre isteği yerine getirmek
1016 üzere bir worker evresini uyandırır. Bu izlemede, isteği yerine getiren
1017 worker evresi HS #65'e aittir.</p>
1020 /65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
1023 <p>Sanal konakların gerçeklenimi sırasında, Apache'nin, bağlantıları
1024 kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir.
1025 Çoğu durumda bu çağrıyı bertaraf etmek mümkündür (hiç sanal konağın
1026 olmadığı veya <directive module="mpm_common">Listen</directive>
1027 yönergelerinin mutlak adreslerle kullanıldığı durumlarda). Fakat bu en
1028 iyilemeleri yapmak için henüz bir çaba harcanmamıştır.</p>
1031 /65: brk(0x002170E8) = 0<br />
1032 /65: brk(0x002190E8) = 0
1035 <p><code>brk(2)</code> çağrıları devingen bellekten bellek ayırır. httpd
1036 çoğu isteği yerine getirirken özel bellek ayırıcılar
1037 (<code>apr_pool</code> ve <code>apr_bucket_alloc</code>) kullandığından
1038 bunlar bir sistem çağrısı izlemesinde nadiren görünür. Bu izlemede,
1039 httpd henüz yeni başlatıldığından, özel bellek ayırıcıları oluşturmak
1040 için ham bellek bloklarını ayırmak amacıyla <code>malloc(3)</code>
1041 çağrıları yapması gerekir.</p>
1044 /65: fcntl(9, F_GETFL, 0x00000000) = 2<br />
1045 /65: fstat64(9, 0xFAF7B818) = 0<br />
1046 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0<br />
1047 /65: fstat64(9, 0xFAF7B818) = 0<br />
1048 /65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0<br />
1049 /65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0<br />
1050 /65: fcntl(9, F_SETFL, 0x00000082) = 0
1053 <p>Ardından, worker evresi istemciye (dosya tanıtıcısı 9) engellenmeyen
1054 kipte bir bağlantı açar. <code>setsockopt(2)</code>
1055 ve <code>getsockopt(2)</code> çağrıları, Solaris libc'sinin soketler
1056 üzerindeki <code>fcntl(2)</code> çağrısı yanında birer yan etkiden
1060 /65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
1063 <p>Worker evresi istemciden isteği okur.</p>
1066 /65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0<br />
1067 /65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10
1070 <p>Bu httpd <code>Options FollowSymLinks</code> ve <code>AllowOverride
1071 None</code> ile yapılandırılmıştır. Bu bakımdan, ne istenen dosya ile
1072 sonuçlanan yol üzerindeki her dizinde <code>lstat(2)</code> çağrısına ne
1073 de <code>.htaccess</code> dosyalarına bakılmasına gerek vardır.
1074 <code>stat(2)</code> çağrısı basitçe dosya için şunları doğrulamak
1075 amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin değil normal bir
1079 /65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
1082 <p>Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt başlığını tek bir
1083 <code>sendfilev(2)</code> sistem çağrısı ile göndermektedir. Dosya
1084 gönderim işleminin anlamı sistemden sisteme değişiklik gösterir. Bazı
1085 sistemlerde, <code>sendfile(2)</code> çağrısından önce başlıkları
1086 göndermek için <code>write(2)</code> veya <code>writev(2)</code>
1087 çağrısı yapmak gerekir.</p>
1090 /65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
1093 <p>Bu <code>write(2)</code> çağrısı isteği erişim günlüğüne kaydeder. Bu
1094 izlemede eksik olan tek şey, <code>time(2)</code> çağrısıdır. Apache
1095 1.3'ün aksine, Apache 2.x zamana bakmak için
1096 <code>gettimeofday(3)</code> çağırısını kullanır. Linux ve Solaris gibi
1097 bazı işletim sistemleri, <code>gettimeofday</code> işlevinin, sıradan
1098 bir sistem çağrısından daha fazla götürüsü olmayan en iyilenmiş bir
1099 gerçeklenimine sahiptir.</p>
1102 /65: shutdown(9, 1, 1) = 0<br />
1103 /65: poll(0xFAF7B980, 1, 2000) = 1<br />
1104 /65: read(9, 0xFAF7BC20, 512) = 0<br />
1108 <p>Burada worker evresi bağlantıyı zamana yaymaktadır.</p>
1111 /65: close(10) = 0<br />
1112 /65: lwp_park(0x00000000, 0) (uykuda...)
1115 <p>Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra
1116 dinleyici evre tarafından başka bir bağlantı atanıncaya kadar beklemeye
1120 /67: accept(3, 0x001FEB74, 0x001FEB94, 1) (uykuda...)
1123 <p>Bu arada, dinleyici evre bağlantıyı bir worker evresine atar atamaz
1124 başka bir bağlantıyı beklemeye başlar (Mevcut tüm evreler meşgulse
1125 dinleyici evreyi baskılayan worker MPM'nin akış denetim şemasına konu
1126 olur). Bu izlemede görünmüyor olsa da sonraki <code>accept(2)</code>
1127 çağrısı, yeni bağlantı kabul eden worker evresine paralel olarak
1128 yapılabilir (aşırı yük durumlarında normal olarak, bu yapılır).</p>