Sunucu Optimizasyonu: Kaynak Darboğazını Ölçerek Giderme

Sunucu optimizasyonu, bütün kaynakları rastgele artırmak değil, yavaşlama anında hangi kaynağın sınırına ulaşıldığını kanıtlayıp yalnızca onu düzeltmektir. Önce aynı işlemin saatini ve belirtisini kaydedin; ardından CPU, bellek, disk gecikmesi ve ağ kullanımını birlikte inceleyin. Değişiklikten önce mevcut ayarı saklayın, tek faktör değiştirin ve aynı işlemi yeni zaman damgalı kayıtlarla tekrar doğrulayın.

Önce erişim türünü ve belirtileri netleştirin

Paylaşımlı hosting kullanıyorsanız işletim sistemi ölçümlerine veya servis ayarlarına erişemeyebilirsiniz. Bu durumda kontrol panelindeki kaynak kullanım grafikleri, işlemci süresi, bellek sınırı, giriş-çıkış kullanımı ve uygulamaya ait hata günlükleri temel kanıttır. Yönetilen bir sanal ya da fiziksel sunucuda ise yönetici hesabı, izleme paneli ve ilgili servis günlükleri gerekir. Yetkiniz olmayan bir ayarı değiştirmeye çalışmak, gerçek nedeni gizleyebilir.

Yavaşlamanın ne zaman oluştuğunu da ayırın. Tüm sayfalar aynı anda yavaşlıyor ve sistem yanıt vermekte zorlanıyorsa CPU, bellek veya disk beklemesi öne çıkar. Sadece büyük dosya yükleme ya da uzak API çağrısı etkileniyorsa ağ kapasitesi, aktarım limiti veya karşı uçtaki yanıt süresi daha olasıdır. Yalnızca veritabanı kullanan sayfalar yavaşsa uygulama ve veritabanı günlüklerindeki sorgu sürelerine bakmadan sunucu boyutunu değiştirmeyin.

Sunucu optimizasyonu için ölçüm sırasını uygulayın

1. Belirtiyi zaman damgasıyla kaydedin. Yavaş URL, işlem türü, yaklaşık başlangıç saati ve gözlenen yanıt süresini not edin. Paneldeki kaynak grafiğinde aynı dakikaları, yönetilen sunucuda ise izleme ekranını ve uygulama hata günlüğünü açın. Kısa süreli CPU sıçraması sırasında bellek ve disk değerleri normalse işlemciyi; bellek doluluğu ile takas kullanımını birlikte görüyorsanız belleği incelemeye geçin.
2. CPU ile bellek baskısını birbirinden ayırın. CPU kullanımı uzun süre yüksek, bellek rahat ve disk beklemesi düşükse yoğun çalışan uygulama iş parçacığını, görev zamanlayıcılarını veya son uygulama değişikliklerini inceleyin. CPU düşük görünürken bellek doluyor ve takas alanı hareketleniyorsa daha fazla işlemci eklemek doğru düzeltme değildir; çalışan süreçlerin bellek tüketimini ve uygulamanın eşzamanlı işlem ayarlarını kontrol edin. Önceki değerleri kaydetmeden limit değiştirmeyin.
3. Disk gecikmesi ve doluluk kanıtını kontrol edin. Panelde disk I/O, depolama doluluğu ve bekleme göstergelerini; yönetici erişiminde izleme aracının disk bekleme ve günlük kayıtlarını inceleyin. CPU ile bellek normal olduğu hâlde okuma-yazma beklemesi yükseliyorsa büyük günlükler, yoğun veritabanı işlemleri veya düşük I/O kapasitesi olasıdır. Günlük saklama politikasını güvenli biçimde düzenleyin ve gereksiz dosyaları silmek yerine sağlayıcının desteklediği arşivleme ya da döndürme yöntemini kullanın. Depolama doluluğu kritikse önce doğrulanmış bir yedek alın.
4. Ağ ve uygulama süresini karşılaştırın. Yalnız aktarım sırasında sorun oluşuyorsa ağ kullanım grafiğini, bağlantı limitlerini ve uygulama günlüğündeki dış servis yanıt sürelerini aynı zaman aralığında karşılaştırın. Sunucunun ağı boşken dış API yanıtı uzuyorsa ağ kapasitesini artırmak sorunu çözmez; zaman aşımı ve karşı servisin durumunu ilgili kayıtlarla değerlendirin. Ağ doygunluğu görünüyorsa aynı anda çalışan aktarım veya yedekleme işlerini planlamaya alın; güvenlik kontrollerini kapatmayın.
5. Tek ve geri alınabilir bir değişiklik yapın. Somut bulguya göre yalnızca ilgili ayarı değiştirin: örneğin bellek baskısı gösteriliyorsa uygulama işçi sayısını düşürmek, disk beklemesi belirginse yoğun görevi daha uygun bir zamana taşımak veya sağlayıcının sunduğu depolama seçeneğini değerlendirmek gibi. Eski değeri, değişiklik saatini ve gerekçeyi kaydedin. Aynı anda PHP sürümü, veritabanı ayarı ve önbellek politikasını değiştirmeyin; aksi hâlde hangi müdahalenin etkili olduğunu ayırt edemezsiniz.
6. Aynı işlemi yeni kanıtla doğrulayın. Sorun çıkaran aynı URL’yi açın, aynı yükleme ya da görevi mümkün olduğunca aynı koşullarda tekrar çalıştırın. Yeni zaman aralığındaki kaynak grafiğini ve yeni günlük satırlarını önceki kayıtla karşılaştırın. Yanıt düzelmiş, hata tekrarlanmamış ve başka bir kaynak sınırı oluşmamışsa değişikliği belgeleyin. Belirti sürüyorsa eski ayarı geri yükleyin ve bir sonraki hipotezi ayrı test edin; yalnızca daha fazla kaynak eklemeyi varsayılan çözüm saymayın.

Kaynağa göre doğru düzeltmeyi seçin

CPU yüksekse, işlemciyi tüketen belirli süreci bulmadan tüm sunucuyu büyütmek pahalı ve belirsiz bir adımdır. Yeni bir eklenti, yoğun rapor görevi veya verimsiz sorgu son değişikliklerle aynı zamana denk geliyorsa önce bunu izole etmek daha güvenlidir. CPU kullanımı normal, ancak bellek sürekli sınırda ise süreç sayısını azaltmak veya bellek tüketen uygulama bileşenini düzeltmek; disk beklemesi yüksekse depolama erişim modelini ele almak gerekir.

Diyelim ki bir e-ticaret uygulamasında yalnızca stok raporu çalışırken sayfalar yavaşlıyor. Aynı dakikalarda CPU yüzde olarak orta düzeyde, bellek değişmiyor, fakat disk beklemesi yükseliyor ve günlükte uzun süren rapor sorguları görünüyor. Bu gözlem, önce raporun zamanlamasını ve sorgu planını incelemeyi destekler; belleği veya ağ paketini büyütmek için henüz yeterli kanıt yoktur. Rapor ertelendikten sonra aynı sayfalar normale dönüyor ama günlükte yeni bir veritabanı hatası oluşuyorsa, zamanlama değişikliğini geri alıp sorgu incelemesine geçmek gerekir.

Değişikliğin güvenli olduğunu nasıl anlarsınız?

Başarılı bir düzeltme yalnızca tek bir hızlı yükleme ile kanıtlanmaz. Aynı işlemin hata oranı, yanıt süresi, ilgili kaynak grafiği ve günlükteki yeni kayıtlar birlikte değerlendirilmelidir. İyileşme yalnızca yoğun saat dışında görülüyorsa ölçüm koşulları farklı olabilir. Bir kaynak düzelirken başka birinin sürekli sınırına yaklaşması kapasite planlaması gerektiğini gösterir; uygulama hatası yoksa bile bu durum sınırsız ölçekleme gerekçesi değildir.

Paylaşımlı hosting sınırları uygulamanın ihtiyacını karşılamıyorsa, ölçüm kayıtlarını ve etkilenen zaman aralıklarını sağlayıcıya iletmek yerine yalnızca “site yavaş” demekten daha yararlıdır. Yönetici erişimli yeni bir ortam değerlendirilirken ise karar, gözlenen darboğaza göre verilmelidir: kısa CPU sıçramaları için işlemci, sürekli bellek baskısı için RAM, yüksek disk beklemesi için uygun depolama davranışı önceliklidir. İhtiyaç farklıysa sunucu kiralama çözümleri hakkında seçenekleri inceleyebilirsiniz; bu bağlantı belirli bir performans sonucunu garanti etmez.

İlk güvenli sonraki adım, son yavaşlama anını ve mevcut kaynak değerlerini kaydedip yalnızca bir ölçüm hipotezini test etmektir. Belirti devam ederse yeni zaman damgalı kayıtları önceki kayıtlarla karşılaştırın; kanıt değişmedikçe birden fazla ayarı birlikte değiştirmeyin.