Sunucu Optimizasyonu: Darboğazı Bulup Güvenle İyileştirme

Sunucu optimizasyonu, tüm ayarları rastgele değiştirmek değil, yavaşlığın CPU, bellek, disk, ağ veya uygulama katmanından hangisinden kaynaklandığını ölçerek belirlemektir. Yönetici erişiminiz olan bir Linux sunucuda önce aynı işlemin zamanını ve belirtisini kaydedin, ardından tek bir ayarı değiştirip aynı işlemi yeniden çalıştırın. Böylece gerçek iyileşmeyi yan etkilerden ayırabilirsiniz.

Sunucu optimizasyonu öncesinde kapsamı ve erişimi belirleyin

Bu yaklaşım, sunucu yöneticisi erişimi olan VPS, bulut sunucu veya fiziksel sunucu için uygundur. Paylaşımlı hosting kullanıyorsanız işletim sistemi kaynaklarını, servis yapılandırmalarını ve çekirdek ayarlarını değiştiremezsiniz; bunun yerine hosting panelindeki kaynak grafikleri, uygulama hata kayıtları ve sağlayıcının sunduğu PHP ya da veritabanı ayarlarıyla sınırlı kalmanız gerekir.

Değişiklikten önce mevcut yapılandırmayı dışa aktarın veya ilgili ayarın eski değerini ayrı bir notta saklayın. Mümkünse yapılandırma dosyası ve uygulama verileri için doğrulanmış bir yedek alın. Üretim ortamında aynı anda PHP çalışan sayısını, veritabanı önbelleğini ve disk ayarlarını değiştirmeyin; aksi durumda hangi değişikliğin sonucu etkilediği anlaşılamaz.

Darboğazı ölçülebilir belirtilerle ayırın

Önce sorunun ne zaman oluştuğunu belirleyin: tüm sayfalar mı yavaş, yalnızca rapor veya arama gibi belirli bir işlem mi sorunlu, yoksa işlem zaman aşımına mı uğruyor? İstek zamanı, URL veya işlem adı ve gözlenen yanıt süresini not edin. Ardından sunucu izleme ekranında CPU kullanımı, bellek doluluğu, disk gecikmesi, disk kapasitesi ve ağ trafiğini aynı zaman aralığında karşılaştırın.

• CPU sürekli yüksek ve çalışan süreçlerden biri belirgin biçimde öndeyse, önce o sürecin uygulama, sorgu veya görev türünü inceleyin. CPU sayısını artırmak yerine uzun süren işlemin nedenini bulmak daha güvenlidir.
• Bellek doluyor ve takas alanı kullanılmaya başlıyorsa, uygulama çalışan sayısı veya önbellek boyutu kapasiteyi aşıyor olabilir. Takas kullanımını yalnızca daha fazla RAM varmış gibi yorumlamayın; disk üzerinden bellek kullanımı yanıt süresini uzatabilir.
• CPU ve bellek normal olduğu hâlde disk gecikmesi yükseliyorsa, yoğun yazma yapan veritabanı, yedekleme veya günlükleme işlemini kontrol edin. Disk kapasitesinin dolmaya yaklaşması da yeni yazma işlemlerini etkileyebilir.

Belirtiye göre karar verin: yalnızca bir veritabanı sorgusu yavaşsa sorgu planı ve indeks kullanımı, tüm uygulama yavaşsa süreç kaynakları ve disk davranışı öncelikli inceleme alanıdır. Ağ grafiği doygun görünüyorsa uygulama ayarlarını değiştirmek yerine trafik, bağlantı sayısı ve sağlayıcı ağ sınırlarını değerlendirin.

Güvenli iyileştirme için beş adımlı uygulama

1. Başlangıç ölçümünü kaydedin. İzleme panelindeki kaynak grafiklerinin zaman aralığını sorun oluştuğu dakikaları kapsayacak şekilde seçin. Aynı URL, arka plan görevi veya sorgu için yanıt süresini ve ilgili hata kaydının zamanını not edin. Bu kayıt yoksa sonraki değişikliğin etkisini güvenilir biçimde karşılaştıramazsınız.
2. İlgili uygulama ve servis kaydını inceleyin. Web sunucusu, uygulama çalışma zamanı ve veritabanı loglarında aynı zaman aralığına ait yeni satırları bulun. Zaman aşımı, bellek yetersizliği, bağlantı havuzu doluluğu veya disk yazma hatası gibi kayıtlar farklı çözümler gerektirir. Örneğin belirli bir sorgunun zaman aşımına uğradığı görülüyorsa çalışan sayısını artırmak yerine sorgunun planını ve kullandığı indeksleri inceleyin.
3. Tek bir hedef ayarı değiştirin. Bellek baskısı uygulama çalışanlarından kaynaklanıyorsa, çalışma zamanı veya işlem yöneticisindeki çalışan sayısını geçici olarak azaltmak güvenli bir test olabilir; ancak bunun sonucunda eşzamanlı istek kapasitesi düşebilir. Değişiklikten önce eski değeri kaydedin ve yalnızca bu ayarı değiştirin. Disk doluluğu loglardan kaynaklanıyorsa dosyaları elle silmek yerine uygulamanın desteklediği günlük döndürme, saklama ve arşivleme politikasını kullanın.
4. Aynı başarısız işlemi tekrar çalıştırın. İlk aşamada kullandığınız aynı URL, rapor veya görevle yeni bir test yapın. Bu kez test saatini not edip yeni log satırlarını ve kaynak grafiklerini inceleyin. Yanıt süresi düzelmiş, bellek baskısı azalmış ve yeni hata oluşmamışsa değişikliğin hedef belirtiyle uyumlu olduğu düşünülebilir; yalnızca genel bir hızlanma izlenimine güvenmeyin.
5. Kalıcılaştırma veya geri alma kararı verin. Sorun devam ediyorsa ikinci bir ayarı hemen değiştirmeyin. Yeni kayıtta farklı bir hata görünüyorsa ilk bulgunun tüm nedeni açıklamadığını kabul edip o belirtiyi ayrı değerlendirin. Kaynak kullanımı kötüleştiyse önceki değere dönün. Belirti sürüyor ancak kaynaklar normal görünüyorsa uygulama kodu, dış servis gecikmesi veya sağlayıcı tarafındaki sanal makine performansı için yöneticinizden ya da sağlayıcınızdan zaman eşleşmeli inceleme isteyin.

Kaynak türüne göre doğru düzeltmeyi seçin

Diyelim ki bir e-ticaret uygulamasında ürün araması yalnız yoğun saatlerde yavaşlıyor; hipotetik ölçümde CPU yüksek, bellek dengeli ve aynı anda veritabanı sorgu süresi artıyor. Bu durumda ilk tercih daha fazla uygulama çalışanı açmak değil, yavaş sorgunun planını ve indeks kullanımını incelemektir. Sorgu düzelip CPU düşerse darboğaz veritabanı işlemiydi; sorgu normal olduğu hâlde CPU yüksek kalırsa uygulama kodu veya başka bir görev ayrıca incelenmelidir.

Başka bir karar örneğinde, tüm istekler bellek baskısı altında yavaşlıyor ve loglarda çalışan süreçlerin bellek sınırına ulaştığı görülüyorsa, çalışan sayısını azaltmak kısa vadede takas kullanımını düşürebilir. Bunun karşılığında kuyrukta bekleyen istekler artarsa bu ayar kalıcı çözüm değildir; daha fazla RAM, daha küçük önbellek veya uygulamanın bellek kullanımını azaltan bir düzeltme değerlendirilmelidir. Sunucu kapasitesini artırmak, ölçüm belirgin biçimde bellek sınırını gösteriyorsa anlamlıdır; disk veya sorgu kaynaklı sorunu çözmez.

Sonucu doğrularken sınırları gözden kaçırmayın

Başarılı bir değişiklik, yalnızca bir isteğin hızlanması değil, aynı işlem tekrarlanırken yeni ve zamanla eşleşen kanıtların da iyileşmesidir. Hata kaydı ortadan kalkmış, ilgili kaynak baskısı azalmış ve uygulamanın beklenen işlevi doğru sonucu üretmiş olmalıdır. Trafik yoğunluğu, önbellek durumu veya arka plan görevleri test sonucunu etkileyebileceği için mümkün olduğunca benzer koşullarda karşılaştırma yapın.

Yönetici erişiminiz yoksa sistem düzeyi optimizasyon yapmaya çalışmak yerine panelde görülen kanıtları kaydedin: olay saati, etkilenen işlem, kaynak grafiği ve yeni hata satırı. Sunucu tarafında daha geniş kapasite veya yapılandırma değerlendirmesi gerekiyorsa sunucu kiralama çözümleri sayfasını bir seçenekleri inceleme noktası olarak kullanabilirsiniz; uygun yapılandırma, iş yükünün ölçümlerine göre ayrıca belirlenmelidir.

İlk güvenli sonraki adım, sorunun tekrarlandığı tek bir işlemi seçip başlangıç ölçümünü almaktır. Ölçüm olmadan ayar değiştirmeyin; ölçüm alındıktan sonra yalnızca en güçlü kanıtın işaret ettiği tek faktörü ele alın.