Sunucu Optimizasyonu Nasıl Ölçülerek Yapılır?

Sunucu optimizasyonu, rastgele limit artırmak yerine yavaşlığın hangi kaynakta oluştuğunu ölçüp yalnızca o noktayı değiştirmektir. Bu rehber, yönetici erişimli Linux tabanlı bir web sunucusunda web isteğinin yavaşlamasını incelemek için hazırlanmıştır. Önce aynı isteğin zamanını ve mevcut ayarları kaydedin; ardından CPU, bellek, disk gecikmesi ve uygulama günlüklerini karşılaştırarak tek bir güvenli değişiklik yapın.

Sunucu optimizasyonu öncesinde kapsamı belirleyin

Bu yöntem, işletim sistemi ve web sunucusu ayarlarına erişebildiğiniz sanal ya da fiziksel sunucular için uygundur. Yalnızca paylaşımlı hosting paneline erişiyorsanız çekirdek, servis havuzu veya sistem önbelleği ayarlarını değiştiremezsiniz; bu durumda paneldeki kaynak kullanımını ve siteye ait hata günlüklerini inceleyip sağlayıcıya zaman bilgisiyle başvurmanız gerekir.

İlk olarak sorunu ölçülebilir hâle getirin. Yavaş açılan URL’yi, yaklaşık saatini, isteğin her zaman mı yoksa yoğunluk sırasında mı geciktiğini ve son yapılandırma değişikliğini not edin. Web sunucusunun erişim günlüğünde aynı isteğin yanıt süresi alanı varsa onu, yoksa uygulama günlüklerindeki işlem süresini kullanın. Aynı anda birden fazla ayarı değiştirmeyin; aksi hâlde hangi değişikliğin sonucu etkilediği anlaşılmaz.

Kaynak darboğazını belirtilere göre ayırın

İlk karar, gecikmenin hesaplama mı yoksa bekleme kaynaklı mı olduğunu ayırmaktır. CPU kullanımı sürekli yüksek ve çalışan işlem sayısı artıyorsa uygulama işlemlerinin hesaplama kapasitesini tüketmesi olasıdır; bu durumda sorgu, eklenti veya uygulama kodu incelemesi bellek artırmaktan daha anlamlıdır. CPU düşük kalırken disk bekleme süresi yükseliyorsa dosya erişimi, günlük yazımı veya depolama gecikmesi öne çıkar.

Bellek kullanımı sınıra yaklaşıyor, takas alanı etkin biçimde kullanılıyor ve yanıt süreleri düzensizleşiyorsa önce uygulama süreçlerinin bellek tüketimini ve aynı anda çalışan süreç sayısını inceleyin. Bellek yeterli, ancak yalnızca ilk istekte gecikme görülüyorsa önbelleğin ısınması veya uygulamanın başlangıç işlemi söz konusu olabilir. Böyle bir bulgu, tüm sistem limitlerini artırmak için tek başına gerekçe değildir.

Diyelim ki bir ürün kataloğu yoğun saatlerde yavaşlıyor. Ölçüm sırasında CPU kullanımı orta düzeyde kalırken disk bekleme süresi belirginleşiyor ve erişim günlüğünde yavaş istekler ürün görselleriyle aynı zamana denk geliyor. Bu durumda işlemci sayısını artırmak yerine görsel depolama ve günlük yazma davranışını incelemek daha tutarlıdır. Aynı gözlemde disk beklemesi yok, fakat uygulama süreci tek bir CPU çekirdeğini sürekli dolduruyorsa hedef değişir: önce yavaş sorgu veya işlem döngüsü araştırılmalıdır.

Değişikliği güvenli biçimde uygulayın

1. Mevcut durumu kaydedin. Web sunucusu yapılandırmasının yedeğini alın ve değiştireceğiniz değerin eski hâlini not edin. Ayrıca aynı URL için başlangıç yanıt süresini ve sistem kaynak görünümünü kaydedin. Bu kayıt, başarısız bir değişiklikte geri dönüş ölçütü olur.
2. Yeni kanıtı doğru günlükte arayın. Web sunucusunun erişim ve hata günlüklerinde, not ettiğiniz zaman aralığındaki yeni satırları inceleyin. Yalnızca belirli bir uygulama isteği yavaşsa uygulama günlüğünü de aynı zaman damgasıyla karşılaştırın. Hata günlüğünde bellek yetersizliği veya süreç sınırı görülüyorsa kaynak havuzunu; yalnızca uzun işlem süresi görülüyorsa ilgili kodu ya da sorguyu ele alın.
3. Tek hedefli bir düzeltme seçin. Süreç sınırı nedeniyle yeni istekler bekliyorsa, web sunucusunun veya uygulama çalışma havuzunun eşzamanlı süreç ayarını mevcut bellek kapasitesini dikkate alarak küçük bir adımla düzenleyin. Disk beklemesi ve büyük günlük dosyaları birlikte görülüyorsa önce gereksiz ayrıntılı günlük seviyesini güvenli, desteklenen bir seviyeye çekin; günlükleri silmeyin. Bellek baskısı varsa süreç sayısını artırmak yerine daha az eşzamanlı süreçle deneme yapmak daha güvenli olabilir.
4. Yapılandırmayı doğrulayın. Değişiklikten önce web sunucusunun kendi yapılandırma doğrulama işlevini veya yönetim panelindeki test seçeneğini çalıştırın. Hata alırsanız servisi yeniden yüklemeyin; önce sözdizimini düzeltip kaydettiğiniz eski değerle karşılaştırın. Doğrulama başarılıysa değişikliği, sağlayıcının önerdiği kontrollü yeniden yükleme yöntemiyle uygulayın.
5. Aynı işlemi yeniden deneyin. Değişiklikten sonra daha önce yavaşlayan aynı URL’yi benzer koşullarda tekrar açın. Yeni zaman aralığında erişim günlüğünü ve kaynak göstergelerini yeniden inceleyin. Yanıt süresi düşmüş, süreç sınırı kayıtları kaybolmuş ve yeni bir hata oluşmamışsa değişiklik hedeflenen belirtiyle uyumludur. Süre aynı kalmışsa başka bir ayarı değiştirmeden önce ilk bulgunun gerçekten devam edip etmediğini kontrol edin.
6. Gerekirse geri dönün. Hata oranı artar, bellek kullanımı yükselir veya yeni yapılandırma uyarısı oluşursa önceki değere dönün ve aynı URL için yeni zaman damgalı kanıt toplayın. Sorun sürerse uygulamayı, veritabanını veya depolama katmanını ayrı inceleyin; genel limitleri topluca yükseltmek yerine sağlayıcının bakım prosedürüne başvurun.

Kaynak profili ile ayarı karıştırmayın

Bir ayar değişikliği ancak sunucunun gerçek kapasitesiyle uyumluysa yarar sağlar. Örneğin bellek zaten sınırlıysa daha fazla uygulama süreci açmak, kısa süreli paralellik karşılığında takas kullanımını artırarak toplam yanıt süresini kötüleştirebilir. Buna karşılık yeterli bellek bulunduğu hâlde süreç havuzu gereğinden küçükse, istekler uygulamaya ulaşmadan sırada bekleyebilir.

İş yükü sürekli büyüyor ve ölçümlerde CPU, bellek veya depolama sınırına tekrar tekrar ulaşılıyorsa konu yalnızca yapılandırma değildir. Uygulama sorgularını ve önbellek davranışını iyileştirdikten sonra kaynak profilini yeniden değerlendirin. Farklı sunucu seçeneklerini incelerken sunucu kiralama çözümleri sayfasını yalnızca seçenekleri gözden geçirmek için kullanabilirsiniz; uygunluk kararını kendi ölçümleriniz ve uygulamanızın gereksinimleriyle verin.

İlk sonraki adım

Bugün tek bir yavaş URL seçin, son başarısız veya yavaş isteğin saatini kaydedin ve o zamana ait erişim, hata ve kaynak göstergelerini birlikte karşılaştırın. Belirtiyi açıklayan tek bir kanıt bulmadan ayar değiştirmeyin; değişiklik yaptıysanız aynı isteği yeni zaman damgasıyla yeniden ölçmeden sonucu başarılı kabul etmeyin.