Tiesto

Tiesto

WFN Üye
Konular
594
Mesajlar
594
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Antalya
Web Sitesi
Var
Alanı
Domain Uzmanı
1/1
Konu sahibi
Yavaş yanıt süresini düzeltmenin doğru yolu, Apache ayarlarını rastgele büyütmek değil, beklemenin nerede oluştuğunu ölçerek ilerlemektir. Önce yanıt süresini DNS, bağlantı, TLS, Apache ve uygulama olarak ayırın; ardından server-status, erişim günlüğü ve işletim sistemi kaynak kullanımını birlikte inceleyin. Sorun Apache’nin bağlantı yönetimindeyse uygun MPM ve işçi sınırlarını düzenleyin; PHP, veritabanı veya harici API bekletiyorsa Apache’yi büyütmek yerine uygulama katmanını düzeltin. Her değişiklikten sonra aynı URL’yi, benzer trafik koşulunda yeniden ölçün.

Önce yavaşlığın hangi katmanda olduğunu belirleyin​


“Apache yavaş” ifadesi tek başına yeterli değildir. Bir isteğin toplam süresi; DNS çözümlemesi, TCP ve TLS bağlantısı, Apache’nin isteği kabul etmesi, uygulamanın çalışması ve yanıtın istemciye aktarılması gibi farklı aşamalardan oluşur. Apache yapılandırmasını değiştirmeden önce gecikmenin hangi aşamada yoğunlaştığını bulun.

Aynı URL için birkaç kez başlık isteği göndererek başlangıç noktası oluşturabilirsiniz:

Bash: 
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Buradaki example.com değerini kendi alan adınızla değiştirin. time_starttransfer, istemcinin ilk yanıt baytını ne kadar sürede aldığını; time_total ise yanıtın tamamının ne kadar sürede geldiğini gösterir. DNS veya TLS süreleri yüksekse Apache ayarını değiştirmek doğrudan çözüm sağlamaz. İlk bayt süresi yüksek, toplam süre buna yakınsa sunucu ya da uygulama yanıtı geç üretmektedir. İlk bayt hızlı, toplam süre yüksekse büyük yanıt, yavaş istemci, sıkıştırma veya ağ aktarımı incelenmelidir.

Bu ölçümü önbellekli ve önbelleksiz yanıtlar için ayrı değerlendirin. Sadece tarayıcıda sayfanın hızlı açılması, Apache’nin hızlı yanıt verdiğini kanıtlamaz; tarayıcı önbelleği, CDN ve daha önce kurulmuş bağlantı sonucu etkileyebilir.

Apache’nin anlık durumunu ve günlüklerini inceleyin​


Apache’nin hangi istekleri işlediğini ve boşta işçi kalıp kalmadığını görmek için mod_status kullanılabilir. Yapılandırma dosyanıza, erişimi yalnızca yönetim IP adresinizle sınırlandırarak benzer bir bölüm ekleyin:

Kod: 
<Location "/server-status">
    SetHandler server-status
    Require ip 203.0.113.10
</Location>

203.0.113.10 yerine kendi sabit yönetim IP adresinizi yazın. Sabit IP’niz yoksa bu alanı genel internete açmayın; erişimi VPN, güvenlik duvarı veya yalnızca yerel yönetim ağı üzerinden sınırlandırın. Yapılandırmayı kaydettikten sonra önce Apache yapılandırmasını denetleyin, hata yoksa yeniden yükleyin:

Bash: 
apachectl configtest
systemctl reload apache2

Dağıtımınızda servis adı httpd ise ilgili komutu buna göre kullanın. Yapılandırma denetimi hata verirse yeniden yükleme yapmayın; hata satırındaki dosya ve yönergeyi düzeltin. Başarılı yeniden yüklemeden sonra /server-status sayfasını yalnızca izin verilen ağdan açın.

Burada özellikle şu durumlara bakın:
  • Boşta işçi kalmıyor ve etkin istek sayısı sürekli sınıra dayanıyorsa Apache eşzamanlı istek kapasitesine ulaşmış olabilir.
  • CPU kullanımı yüksek, fakat istekler kısa sürede tamamlanıyorsa sıkıştırma, TLS, yoğun günlükleme veya yüksek istek hacmi etkili olabilir.
  • İstekler uzun süre etkin kalıyor ve aynı URL’ler tekrar tekrar görünüyorsa uygulama, veritabanı veya harici servis beklemesi araştırılmalıdır.
  • Bellek kullanımı yükseliyor ve takas alanı kullanılmaya başlıyorsa daha fazla işçi açmak gecikmeyi azaltmak yerine artırabilir.
server-status anlık bir görüntüdür; tek başına hangi isteğin her zaman yavaş olduğunu kanıtlamaz. Yavaş istekleri erişim günlüğünde süre bilgisiyle izlemek daha kalıcı bir teşhis sağlar. Günlük biçiminizde istek süresi yoksa, kullandığınız dağıtımın Apache günlük yapılandırmasında desteklenen zaman değişkenleriyle ayrı bir günlük alanı ekleyin. Ardından yavaş URL, yanıt kodu, istemci IP’si ve istek süresini birlikte gruplayın. Aynı URL’nin yalnızca yoğun saatlerde yavaşlaması kapasite sorununa; her zaman yavaş kalması uygulama veya veritabanı sorununa daha çok işaret eder.

MPM seçimini ve işçi sınırlarını kontrol edin​


Apache 2.4’te MPM, sunucunun süreç ve iş parçacıklarını nasıl kullandığını belirler. Unix benzeri sistemlerde event, worker ve prefork seçenekleri bulunabilir. event, boşta bekleyen keep-alive bağlantılarının etkin iş parçacıklarını gereksiz yere meşgul etmemesi için tasarlanmıştır. Bu nedenle thread-safe çalışan uygulama ve modüllerle kullanılan, modern Linux sunucularda genellikle ilk incelenecek seçenektir.

Önce hangi MPM’nin etkin olduğunu öğrenin:

Bash: 
apachectl -V | grep -i mpm
apachectl -M | grep mpm

Çıktıda mpm_prefork_module görüyorsanız, doğrudan event modülüne geçmeyin. PHP gibi Apache içine yüklenen veya thread-safe olmayan bir modül prefork gerektirebilir. Uygulama PHP-FPM gibi ayrı bir işlem yöneticisi üzerinden çalışıyor ve kullanılan diğer modüller thread-safe ise event MPM’ye geçiş değerlendirilebilir. Geçişten önce mevcut yapılandırmanın yedeğini alın, tek bir MPM’nin yüklü olduğundan emin olun ve dağıtımınızın paketleme yöntemine uygun modül etkinleştirme komutlarını kullanın.

MPM ayarlarında en sık yapılan hata MaxRequestWorkers değerini RAM’i hesaba katmadan yükseltmektir. Bu değer, Apache’nin aynı anda işleyebileceği etkin işçi sayısını sınırlar. Yaklaşık bellek hesabı için Apache süreçlerinin veya iş parçacıklarının ortalama çalışma belleğini ölçün; ardından işletim sistemi, PHP-FPM, veritabanı ve diğer servisler için pay bırakarak sınır belirleyin. Örneğin varsayımsal olarak Apache için kullanılabilir 2.400 MB RAM ayırabiliyor ve bir Apache işçisi ortalama 80 MB kullanıyorsa teorik üst sınır 30 işçidir. Bu değer güvenli nihai ayar değildir; ani bellek artışları ve diğer servisler için ayrıca pay gerekir.

MaxRequestWorkers sınırına sürekli ulaşılıyor, RAM ve CPU hâlâ uygun durumdaysa kademeli artış düşünülebilir. Sınırın artırılmasıyla birlikte bellek tükeniyor, takas başlıyor veya yanıt süresi uzuyorsa eski değere dönün. Sınır hiç dolmuyor ama ilk bayt süresi yüksek kalıyorsa bu ayar asıl sorunu çözmez; uygulama ve veritabanı ölçümlerine geçin.

Keep-alive ve bağlantı beklemelerini dengeli ayarlayın​


Keep-alive, aynı TCP bağlantısının birden fazla istekte kullanılmasını sağlar; ancak bağlantının uzun süre açık tutulması, özellikle yanlış MPM veya yetersiz işçi kapasitesiyle birlikte kaynak tüketebilir. event MPM’de keep-alive bağlantılarının yönetimi için özel mekanizmalar bulunduğundan, sırf bağlantılar açık kalıyor diye keep-alive’ı tamamen kapatmak doğru ilk adım değildir.

KeepAliveTimeout değerini çok yüksek tutmak, kullanılmayan istemcilerin bağlantıyı uzun süre işgal etmesine; çok düşük tutmak ise yeni TCP ve TLS bağlantılarının artmasına yol açabilir. Önce server-status üzerindeki keep-alive ve etkin bağlantı durumunu, ardından erişim günlüklerindeki bağlantı ve yanıt sürelerini inceleyin. Bağlantıların çoğu boşta bekliyor ve işçi kapasitesi doluyorsa timeout değerini kademeli düşürün. Yeni bağlantı ve TLS yükü belirgin biçimde artarsa aşırı düşürmüş olabilirsiniz.

Bu ayarı değiştirirken aynı anda MaxRequestWorkers, MPM ve ağ katmanını değiştirmeyin. Tek değişkenle ilerlemek, ölçüm sonucunun hangi ayardan kaynaklandığını anlamanızı sağlar.

Statik içerik, sıkıştırma ve önbelleği doğru yerde kullanın​


Statik dosyalar Apache tarafından doğrudan sunuluyorsa dosya boyutlarını, disk erişimini ve gereksiz modülleri inceleyin. CSS ve JavaScript dosyalarının gereksiz büyük olması toplam aktarım süresini artırır; ancak bu durum ilk bayt süresini açıklamayabilir. Büyük dosyalarda toplam süre yüksek, ilk bayt süresi düşükse sorun çoğunlukla yanıt üretiminde değil aktarım boyutundadır.

Metin tabanlı HTML, CSS, JavaScript, JSON ve SVG yanıtlarında mod_deflate veya sunucunuzun desteklediği uygun sıkıştırma yöntemini kullanabilirsiniz. Görselleri ve zaten sıkıştırılmış arşivleri tekrar sıkıştırmak CPU tüketir, fakat anlamlı boyut kazancı sağlamayabilir. Sıkıştırmayı etkinleştirdikten sonra CPU kullanımını ve Content-Encoding başlığını kontrol edin. Başlıkta sıkıştırma görünmüyor veya sıkıştırma CPU’yu tüketiyorsa MIME türleri, boyut eşiği ve sıkıştırma düzeyi yeniden düzenlenmelidir.

Değişmeyen statik dosyalarda uzun süreli istemci önbelleği kullanılabilir. Dosya adlarına sürüm veya içerik özeti eklenmiyorsa uzun önbellek süresi, yeni dosyanın istemciye geç ulaşmasına neden olabilir. Bu nedenle önbellek süresini artırmadan önce dosya adlarının değişiklikleri ayırt edip etmediğini kontrol edin.

Apache önbelleği yalnızca içeriğin gerçekten önbelleğe uygun olduğu durumlarda kullanılmalıdır. Oturum, kişisel veri, yönetici ekranı veya kullanıcıya göre değişen yanıtları yanlışlıkla ortak önbelleğe almak güvenlik ve doğruluk sorunu oluşturur. Önbellek kullanıldığında ilk isteğin yavaş olması, sonraki isteğin hızlanması beklenebilir; bu, uygulamanın her zaman düzeldiğini kanıtlamaz. Önbellek dışı isteklerin süresini de ayrı ölçün.

Apache dışındaki beklemeleri ayırın​


Apache bir PHP, Python, proxy veya CGI uygulamasından yanıt bekliyorsa işçi uzun süre meşgul kalabilir. Bu durumda Apache’yi daha fazla işçiyle çalıştırmak yalnızca daha fazla eşzamanlı uygulama süreci başlatır. Sonuç; veritabanı bağlantı havuzunun dolması, RAM tüketiminin artması veya uygulamanın daha da yavaşlaması olabilir.

Yavaş bir URL için şu ayrımı yapın:
  • Statik bir dosya hızlı, dinamik sayfa yavaşsa Apache’nin temel dosya sunumu yerine uygulama zincirini inceleyin.
  • Tüm URL’ler aynı anda yavaşlıyorsa CPU, RAM, disk, ağ, TLS veya Apache kapasitesini kontrol edin.
  • Sadece belirli parametreli istekler yavaşsa veritabanı sorgusu, dış API çağrısı veya uygulama kodundaki koşullu işlem araştırılmalıdır.
  • Apache günlüğünde 5xx hataları veya proxy zaman aşımı görülüyorsa yalnızca timeout değerini artırmayın; önce arka uç servisin neden zamanında yanıt vermediğini bulun.
PHP-FPM veya başka bir arka uç kullanıyorsanız Apache ile arka uçtaki eşzamanlı işlem sayısını birlikte değerlendirin. Apache’nin kabul ettiği istek sayısı, arka ucun işleyebileceği istek sayısından çok yüksekse istekler kuyrukta bekler. Arka uç sınırını artırmak için önce her işlemin bellek tüketimini ölçün; RAM yetersizse daha yüksek süreç sayısı çözüm değildir.

Değişikliği güvenli biçimde uygulayın ve sonucu yorumlayın​


Her değişiklikten önce ilgili Apache yapılandırma dosyasının yedeğini alın. Ardından şu sırayı izleyin:
  1. Mevcut MPM, MaxRequestWorkers, KeepAliveTimeout, CPU, RAM, disk kullanımı ve örnek URL yanıt sürelerini kaydedin.
  2. Yalnızca bir ayar veya bir ayar grubu değiştirin; dosyayı kaydedin.
  3. Yapılandırmayı apachectl configtest ile denetleyin. Hata varsa yeniden yüklemeyin; bildirilen dosya ve satırı düzeltin.
  4. Denetim başarılıysa Apache’yi yeniden yükleyin. Yeniden başlatma yerine yeniden yükleme destekleniyorsa mevcut bağlantıları daha az etkileyen bu yöntemi tercih edin.
  5. Aynı URL’leri tekrar ölçün; ilk bayt süresi, toplam süre, HTTP durum kodu, CPU, RAM, takas ve server-status işçi durumunu birlikte karşılaştırın.
  6. Yanıt süresi düzelmiyor veya kaynak kullanımı kötüleşiyorsa son değişikliği geri alın ve bir sonraki katmanı inceleyin.
İlk bayt süresi düşmüş, CPU ve RAM kabul edilebilir kalmışsa değişiklik muhtemelen doğru katmanı etkilemiştir. İlk bayt süresi aynı kalıp toplam süre azaldıysa sıkıştırma, dosya boyutu veya bağlantı aktarımı iyileşmiştir; uygulama üretim süresi hâlâ devam ediyor olabilir. Yanıt süresi artmış ve bellek baskısı oluşmuşsa işçi sınırı fazla yükseltilmiş olabilir. Yanıt süresi yalnızca önbellekli isteklerde düşüyorsa kaynak sorununu değil, tekrar eden uygulama çalışmasını gizleyen bir önbellek etkisini görüyorsunuz demektir.

Sorun devam ederse destek veya barındırma sağlayıcısına yalnızca “Apache yavaş” demek yerine şu bilgileri birlikte iletin: ölçüm zamanı ve saat dilimi, test edilen URL, curl zaman değerleri, HTTP durum kodu, Apache sürümü ve etkin MPM, ilgili günlük satırları, server-status sırasında etkin işçi durumu, CPU/RAM/takas kullanımı ve son yapılandırma değişikliği. Parola, oturum çerezi veya kişisel verileri paylaşmadan bu veriler üzerinden hangi katmanda darboğaz bulunduğunun incelenmesini isteyin.

Sık sorulan sorular​

Apache’de MaxRequestWorkers değerini artırmak her zaman yanıt süresini düşürür mü?​

Hayır. Değer düşük olduğu için istekler gerçekten sırada bekliyorsa yardımcı olabilir. Ancak CPU, RAM, veritabanı veya uygulama zaten doygunsa daha fazla işçi kaynak yarışını artırır ve yanıt süresini kötüleştirebilir. Önce server-status, RAM ve takas kullanımını inceleyin.

Apache’yi prefork yerine event MPM’ye geçirmek güvenli midir?​

Her kurulum için doğrudan güvenli değildir. Apache içine yüklenen modüllerin thread-safe olması ve uygulama çalışma modelinin buna uygun olması gerekir. Özellikle modül uyumluluğunu ve PHP’nin Apache’ye nasıl bağlandığını kontrol etmeden MPM değiştirmeyin.

Keep-alive’ı kapatmak yavaş yanıt sorununu çözer mi?​

Genellikle ilk çözüm değildir. Kapatmak yeni TCP ve TLS bağlantılarını artırabilir. Sorun, boşta bağlantıların işçileri tüketmesi ise timeout ve MPM davranışı birlikte incelenmeli; bağlantıların kendiliğinden neden uzun süre açık kaldığı belirlenmelidir.

İlk bayt süresi yüksek, toplam süre de yüksekse neye bakmalıyım?​

Önce dinamik uygulama, veritabanı, PHP-FPM veya proxy arka ucu incelenmelidir. Statik dosya hızlıyken yalnız dinamik sayfa yavaşsa Apache işçi sayısını artırmak yerine yavaş sorguyu, harici API çağrısını veya uygulama işlemini ölçün.

Değişiklikten sonra site açılmazsa ne yapmalıyım?​

Önce apachectl configtest çıktısındaki dosya ve satırı kontrol edin. Yapılandırma hatalıysa son değişikliği geri alıp yeniden denetleyin. Apache başlıyor fakat istekler hata veriyorsa hata günlüğünde modül yükleme, izin, proxy, PHP-FPM ve zaman aşımı kayıtlarını; ardından HTTP durum kodlarını inceleyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)