Apache niniz Çokmu yavaş ?

Evet arkadaşlar apacheniz cok yavaş ise aşagıdaki uygulayın % 70 gibi performans artışı görürsünüz.İlk başta bende inanmıyordum uyguladım ve mükemmel sonuç aldım


Sembolik bağlarla (symbolic links) ilgili ayarlar
Apache, kullanıcı tarafından istenen bir dizin ya da dosyayı işlerken, bir sembolik bağ olup olmadığını inceleyebilir. Apache'nin varsayılan ayarlarında Option FollowSymLinks vardır. Güvenliği düşünen sistem yöneticileri bunu genellikle Option None ya da Option SymLinksIfOwnerMatch yapmaktadır. Ancak bu hızı düşürmektedir. En yüksek performans Option FollowSymLinks yönergesiyle alınmaktadır.

Option SymLinksIfOwnerMatch durumu
Apache bu yönergeyle, normale göre istenen dizinin/dosyanın bir sembolik bağ olup olmadığını kontrol etmek zorundadır. İstenen dizinin derinliğine göre en üst dizinden (/) başlayarak, bu işlem alt dizinlere kadar tek tek yapılmaktadr. Örneğin, istenen belge /usr/local/apache/htdocs/dizin/dosya.html'se, Apache şu dizin/dosyaların hepsinin bir sembolik bağ olmadığını kontrol eder:

(/ asla kontrol edilmez, çünkü / her zaman gerçek bir dizindir)
/usr
/usr/local
/usr/local/apache
/usr/local/apache/htdocs
/usr/local/apache/htdocs/dizin
/usr/local/apache/htdocs/dizin/dosya.html
Burada önemli olan şudur, /usr/local/apache/htdocs fiziksel (gerçek) bir dizin olsa da Apache bunu kontrol etmek zorundadır. Ayrıca yapılan iki işlem de, dosyanın/dizinin gerçek sahibini almak, sembolik bağın sahibini almak ve bunları karşılaştırmak. Örneğin, webauthor kullanıcısı şu komutla:

$ln -s /usr/local/apache/htdocs/gizli_dizin /etc

şeklinde bir komutla bir sembolik bağ yaratmışsa, /usr/local/apache/htdocs/gizli_dizin'in sahibi (webuser) ve /etc'nin sahibi (root) sistem çağrıları aracılığıyla alınır ve karşılaştırılır. Bu tip dizinlerin sık çağrılması durumunda tepki süresi düşecektir. Ayrıca, bu karşılaştırma işleminin sonuçları önbelleklenmez, dolayısıyla bu kontroller her çağrıda tekrar tekrar yapılır.

Alternatif çözüm
Güvenlikten fazla taviz verilmeden gidilecek daha iyi bir çözüm, dosyaların kök dizini dışında sembolik bağ kontrolünü açıp, kök dizinin altında kapatmak olabilir.

DocumentRoot /webroot/docs
...
<Directory />
Options FollowSymLinks
</Directory>
<Directory /webroot/docs>
Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>

Bu şekilde, dosyaların kök dizini altında, sembolik bağı veren kişiyle bağ verilen dosya/dizinin sahibi aynı kişi değilse, Apache o dosyayı/dizini istemciye göndermeyecektir, ve güvenlik de nispeten artmış olacaktır.

Çocuk sunucularla ilgili ayarlar
Apache, tepki süresini arttırmak amacıyla, bir miktar çocuk sunucuyu (child server, fork edilen sunucular) önceden açar ve boşta bekletir. Diğer sunucuların meşgul olması ve yeni bir istemcinin bağlanması durumunda bu sunuculardan bir tanesi gelen isteği karşılar. Ani yüklenmelerin (transient peak) olduğu bir sunucuda, boşta bekleyen sunucuların fazlaca olması tavsiye edilir. Apache'de varsayılan şu iki yönerge vardır:

MinSpareServers 5
MaxSpareServers 10

Bu sayıları aşağıdaki gibi 32 ve 48 şeklinde değiştirmeniz, bir anda 32 istemcinin birden sunucudan dosya istemesi halinde, anında tepki verilebilmesini sağlar:

MinSpareServers 32
MinSpareServers 48

Yine de hatırlatmak gerekir, açılan her çocuk sunucu bellek kullanımını arttırır. Bu sayıyı çok arttırmanız durumunda Web sunucunun kullandığı bellek, fiziksel belleği aşacağı için sunucu diske swap yapmaya başlar ki bu da performansı düşürür. Dolayısıyla doğru ayarları bulana kadar, bir miktar deneme/yanılma yapmanız gerekebilir.

Bir başka ayar da, çocuk sunucuların ölmeden önce kaç isteğe cevap vereceği ayarıdır. Apache'nin varsayılan ayarı:

MaxRequestsPerChild 10000

şeklindedir. Bu sayıyı çok düşürmeniz halinde (ör. 50-100), sunucular sürekli olarak öldürülüp tekrar başlatılacaktır, ki bu da sunucunun tepki süresini düşürür. Çok yüksek olması durumunda (ör. 100,000 ya da sınırsız için kullanılan 0) ise, çocuk sunucuların bellek akıtma (memory leaking) problemi varsa (ör. Solaris'de vardır), bellek kullanımı artacaktır ve sunucunun performansı yine düşecektir. Bu tip bir probleminiz varsa ve sunucunuza gelen trafik sürekli yüksek değilse, bu sayıyı 500-1000'e kadar düşürebilirsiniz.

.htaccess'le ilgili ayarlar
Apache'nin bir özelliği de, bazı dizinlerde bulunabilen .htaccess dosyaları aracılığıyla kullanıcılardan isim/şifre isteyebilmesi ya da IP numaralarını kontrol ederek erişimi kısıtlayabilmesidir. Bazı sistem yöneticileri bu dosyaları kullanabilmek için şu şekilde bir tanımlama yapabilirler:

DocumentRoot /webroot/docs/
...
<Directory /webroot/docs/>
AllowOverride AuthConfig
</Directory>

Ancak sembolik bağlarda çıkan durum burada da vardır. Apache bu dizinin altındaki her dizinde (her seferinde bir alta inerek) bir .htaccess dosyasının olup olmadığını kontrol etmek zorunda kalır ve bu da performansı düşürür. Bunun yerine sadece gerekli dizinlerde bu ayar açılarak sunucunun diğer dizinlerde bir kontrol işlemi yapması engellenebilir, ve bu da performansı arttırır. Örneğin, şu şekilde bir tanımlama kullanılabilir:

DocumentRoot /webroot/docs/
...
<Directory /webroot/docs>
AllowOverride None
</Directory>
<Directory /webroot/docs/guvenli_dizin>
AllowOverride AuthConfig>
</Directory>

Kayıt dosyalarıyla ilgili ayarlar
Apache, sunucuya bağlanan kullanıcıların isteklerinin detaylı bir kaydını tutabilir. Birçok sistem yöneticisi de varsayılanları kullandığı için genelde şu ikisinden biri tercih edilir:

CustomLog /usr/local/apache/logs/access_log common

CustomLog /usr/local/apache/logs/access_log combined

Eğer Apache'nin tepki süresini hızlandırmak istiyorsanız, kayıtları kapatın! Bu birçok sistem yöneticisine mide spazmı bile geçirtebilecek bir öneridir, ancak Apache gelen her istek için bu dosyaları açmakta ve gerekli değişkenleri hesaplayıp dosyaya eklemektedir. Bir Web sunucusunda performans genel olarak, dosyaları işleme süresinin düşüklüğü ve diske ne kadar az erişim yaptığıyla belirlenir. Hiç kayıt tutulmaması ve dosyaların önbelleklenmesi gibi tekniklerle, sunucu minimum seviyede disk erişimi yapacağından tepki süresi çok artacaktır.

Burada kapılınabilecek yanlış bir hüküm, kayıt dosyalarına yazılan verilerin miktarının düşürülmesinin performansı arttıracağıdır. Bu kısmen doğrudur, ancak yine de fiziksel disk erişimi her durumda yavaş olduğundan performansı çok arttırmayacaktır.

Diğer ayarlar
Kullanıcıların istekleriyle cevabın gönderilmesi arasındaki süre KeepAlive olarak adlandırılır. Bu süre düşürülerek, hattaki gecikmeler nedeniyle sunucunun gereksiz yere paketleri göndermek için meşgul edilmemesi sağlanabilir. Varsayılan ayar

Timeout 300

(saniye) şeklindedir. Bu değer örneğin

Timeout 120

yapılabilir. Bu değerin çok düşürülmesi (ör. 5-10) durumunda ise, istemcilerin hoşuna gitmeyen sonuçlar çıkacaktır: sunucu isteği aldıktan sonra paketi gönderecek ve kısa bir süre sonra paketler bitmese bile bağlantıyı kesecektir.

SSI ve CGI kullanmak, birçok sayfada otomasyona gidilmesini sağlarken, bir yandan da performansı düşürmektedir. Bu iki tekniği kullanarak üretilen her sayfa, fazladan bir disk erişimi ya da program çalıştırılmasını gerektirdiğinden tepki süresi artacaktır.

Sunucu durumunu öğrenmek için /server-status işlemcisini kullanıyorsanız, bu da performansı düşürecektir. Apache, bu işlemcinin her an çağırılabilme ihtimaline karşı her istek için o andaki saati sistemden öğrenmek durumunda kalacaktır ve bu da bir hız düşüşü şeklinde ortaya çıkacaktır. Bu işlemciyi kapatmak için

ExtendedStatus off

yönergesini veriniz.

Performansı özellikle düşüren bir diğer yönerge de HostnameLookups on'dur. Bu yönerge verildiğinde, özellikle kayıt dosyalarında, istemcinin IP numarası yerine tam adresi (FQDN, ör. istemci.bolum.kurum.edu.tr) kullanılabilir. Ancak bu durumda, istemcinin IP numarası bir DNS sunucusundan bakılarak, adresi bulunmak zorundadır ki, performans ciddi ölçüde düşecektir. Eğer bunu istemiyorsanız bu özelliği şu şekilde iptal edebilirsiniz:

HostnameLookups off

Bir başka performans arttırımı da sık kullanılmayan modüllerin DSO (Dynamic Shared Object) olarak derlenmesi ve kullanılmadıkça bellekte durmamasıdır. Bunun için Apache'yi derlerken şuna benzer parametreleri vermelisiniz:

#./configure \
--enable-rule=SHARED_CORE \
--enable-shared=define \
--enable-shared=headers \
--enable-shared=include

Burada --enable-rule=SHARED_CORE komutu DSO desteğini açacak, --enable-shared= satırları da DSO olarak derlenecek modülleri belirtecektir. Bu şekilde, sunucunun bellekte kapladığı yer azalacaktır ve daha çok çocuk sunucu hazırda bekletilebilecektir.

Özet ve işletim sistemiyle ilgili ayarlar
Bir Web sunucusunun tepki süresi arttırılmak isteniyorsa, asıl prensip sunucunun mümkün olduğu kadar az disk erişimi yapmasıdır, çünkü dosyalar bir program tarafından işleniyor bile olsa, bellekteki işleme süresi, disk erişim süresinden kat kat hızlıdır. Ayrıca, Web sunucusunun mutlaka bol miktarda belleği olmalıdır, ve bellek yetersizliğinden dolayı diske asla swap yapmamalıdır. Eğer, sunucu disk erişimi yapmak zorundaysa, hızlı bir disk almanız tavsiye edilir, özellikle SCSI diskler bu işler için idealdir. Bir başka öneriyse, Web sunucu makinesinin ayrık olması durumunda, üzerindeki tüm gereksiz servislerin kapatılmasıdır, bu hem boş belleği arttıracaktır, hem de güvenliği. Windows sunucularında (Apache her ne kadar Unix türevlerindeki kadar performanslı çalışmasa da), düzenli bir defragmentation işlemi de işe yarayacaktır, Unix'deyse bu işleme zaten gerek yoktur.

Hem Unix türevlerinde, hem de Windows'da işe yarayan bir başka ayarsa, Web dosyalarının durduğu diskin inode/cluster boyutlarının büyütülmesidir. Böylece özellikle büyük dosyaların istemciye gönderilmesi sırasında, sabit disk kafası bir o yana bir bu yana dolaşmak zorunda kalmayacaktır ve diskin SeekTime (arama zamanı, disk kafasının bir başka bölüme zıplama süresi) parametresinden kurtulmuş olunacaktır.

Burada önerilebilecek bir diğer teknik, eğer dosyalarınız dinamik üretiliyorsa, Unix'deki Paylaşımlı Bellek (Shared Memory) kullanarak (PHP, Perl ve C'de bu destek vardır), işlenmiş sayfalar önbelleklenebilir ve disk erişimi azaltılabilir. Ayrıca kayıtları kapatmışsanız, önişleme yapan programınız aracılığıyla, kayıtları programınız kendisi tutarak, biriktirip belli aralıklarla diske flush ettirebilirsiniz. Böylece disk erişimi minimum seviyede olacaktır.

Bir başka teknik de, CGI programlarında aynı anda çalışabilecek kopya sayısının sınırlandırılarak, sunucunun işlemcisinin fazlaca meşgul edilmemesidir. Bunun için bir sayaç dosyası tutulabileceği gibi, bir ortam değişkeni ya da paylaşımlı bellek de kullanılabilir. Sayaç dosyası tekniği, yavaşlığı dolayısıyla da yarış durumları (race condition) daha kolay çıktığı için, mümkünse tercih edilmemelidir.

Son olarak, işletim sistemlerinin bazı parametrelerinde oynamalar yaparak, makine Web sunucusu olmak için özelleştirilebilir.