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 ş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 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 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 , 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 parametresinden kurtulmuş olunacaktır. Burada önerilebilecek bir diğer teknik, eğer dosyalarınız dinamik üretiliyorsa, Unix'deki Paylaşımlı Bellek kullanarak , 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ı 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.

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 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: /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 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 ve /etc'nin sahibi 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... &lt;Directory /&gt; Options FollowSymLinks &lt;/Directory&gt; &lt;Directory /webroot/docs&gt; Options -FollowSymLinks +SymLinksIfOwnerMatch &lt;/Directory&gt; 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 ö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 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 problemi varsa , 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/ ... &lt;Directory /webroot/docs/&gt; AllowOverride AuthConfig &lt;/Directory&gt; Ancak sembolik bağlarda çıkan durum burada da vardır. Apache bu dizinin altındaki her dizinde 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/ ... &lt;Directory /webroot/docs&gt; AllowOverride None &lt;/Directory&gt; &lt;Directory /webroot/docs/guvenli_dizin&gt; AllowOverride AuthConfig&gt; &lt;/Directory&gt; 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.