- Konu sahibi
- #1
Web uygulaması için sunucu kaynakları, yalnızca ziyaretçi sayısına bakılarak değil; eşzamanlı istek, istek başına işlem süresi, veritabanı yükü, önbellek kullanımı ve trafik artış payı birlikte değerlendirilerek belirlenir. En doğru yöntem, uygulamayı gerçekçi bir test yükü altında ölçmek, CPU/RAM/disk ağı/yanıt süresi göstergelerini izlemek ve darboğaza göre kaynağı artırmaktır. Başlangıçta varsayımlı bir kaynak planı yapılabilir; ancak kalıcı kapasite kararı gözlem verisine dayanmalıdır.
CPU, PHP, Node.js, Python, Java veya benzeri uygulama süreçlerinin hesaplama ihtiyacını karşılar. Yoğun rapor, görsel işleme, şifreleme ve arama işlemleri CPU tüketimini artırır.
RAM, uygulama süreçleri, veritabanı önbelleği, işletim sistemi önbelleği ve bağlantı havuzları tarafından kullanılır. RAM yetersiz kalırsa sistem diske taşma yapabilir; bu da yanıt sürelerini belirgin biçimde kötüleştirir.
Disk için yalnız kapasiteye değil, okuma-yazma gecikmesine ve IOPS ihtiyacına da bakılır. Veritabanı, oturum dosyaları, yüklenen içerikler, günlükler ve yedekler aynı diski kullanıyorsa bu tüketimler ayrı hesaplanmalıdır.
Ağ kapasitesi, özellikle dosya indirme, video, görsel ve API yanıtlarında önemlidir. Trafik hesabına yalnız ortalama değil, yoğun saatlerdeki ani artış da dahil edilmelidir.
Veritabanı çoğu uygulamada ayrı bir darboğazdır. Bağlantı sayısı, sorgu süresi, indeksler, kilitlenmeler ve sorgu başına okunan veri miktarı sunucu seçimini doğrudan etkiler.
Aşağıdaki sırayı izleyerek ölçülebilir bir başlangıç planı oluşturun:
Test için gecikme/hata hedefini baştan yazın; p95/p99, sürdürülebilen istek hızı ve kuyruk uzunluğunu izleyin. Aktif kullanıcı sayısı eşzamanlı uçuş hâlindeki istek sayısı değildir: kararlı durumda10 istek/s ×0,2 saniye yaklaşık2 eşzamanlı istek eder. Temsili200KB yanıt ×10 istek/s yaklaşık2MB/s (16Mbit/s) gövde trafiğidir; protokol ve diğer varlıklar ek yük getirir. Bunlar sunucu modeline veya RAM miktarına doğrudan çevrilemez. Yük testini yetkili kontrollü ortamda yapın; ödeme/e-posta gibi gerçek yan etkileri sınırlandırın.
Bir katalog uygulamasında yoğun saatte 10 istek/saniye, 100 eşzamanlı kullanıcı ve küçük görsellerin uygulama sunucusundan gönderildiğini varsayalım. Test sırasında CPU düşük kalırken RAM hızla tükeniyor ve yanıt süresi disk beklemesiyle artıyorsa ilk karar daha fazla CPU eklemek değildir. Görselleri ayrı bir depolama veya önbellek katmanına almak, uygulama süreçlerinin bellek sınırlarını kontrol etmek ve veritabanı sorgularını incelemek daha doğru ilk adımdır.
Tersine, RAM yeterli olduğu hâlde tek bir uygulama süreci CPU'yu sürekli tüketiyorsa pahalı bir sunucuya geçmeden önce yavaş sorgu, döngüsel işlem, sıkıştırma veya gereksiz veri dönüştürme araştırılmalıdır. Test başarısız olursa sonuç, uygulamanın bu yükü karşılayamadığı anlamına gelir; hangi kaynağın yetersiz olduğunu metriklerden ayırmadan kaynak seçmek doğru değildir.
Aşağıdaki tablo, gözlenen belirti ile ilk inceleme yönünü eşleştirir:
Bu tablo doğrudan kaynak artırma listesi değildir. Aynı belirti birden fazla nedenden oluşabileceği için değişiklikten sonra yeniden ölçüm yapılmalıdır.
Yalnız ziyaretçi sayısını kullanmak: Aynı kullanıcı sayısı, basit bir sayfada düşük; rapor veya arama yapan uygulamada yüksek kaynak tüketebilir.
Eşzamanlılık ile toplam trafiği karıştırmak: Aylık veya günlük toplam istek, aynı anda kaç isteğin işlendiğini göstermez. Sunucu kapasitesini özellikle yoğun an belirler.
Ortalama değere güvenmek: Ortalama yanıt süresi iyi görünürken az sayıdaki çok yavaş istek kullanıcı deneyimini bozabilir. Dağılımı, hata oranını ve en yavaş istekleri de izleyin.
Yedek ve günlükleri hesaba katmamak: Disk kapasitesi yalnız uygulama dosyalarından oluşmaz. Günlüklerin büyümesi ve yedeklerin aynı depolamada tutulması ayrıca planlanmalıdır.
Tek testle karar vermek: Önbellek sıcaklığı, arka plan görevleri ve trafik şekli sonucu değiştirebilir. Farklı senaryoları ve kısa süreli yoğunluğu ayrı test edin.
Uygulamanın iş yükü, veri hacmi, kodu veya mimarisi değiştiğinde; ayrıca izleme değerleri uzun süre mevcut kapasiteye yaklaştığında yeniden test yapılmalıdır. Büyük sürüm değişiklikleri de kapasite testi için uygun bir zamandır.
Karar yalnız kaynak miktarına bağlı değildir. Uygulama durum bilgisiz çalışabiliyor, dosyalar ortak veya ayrı depolanabiliyor ve veritabanı bağlantısı güvenilir biçimde yönetilebiliyorsa yatay çoğaltma değerlendirilebilir. Aksi durumda önce uygulamanın bu mimariye uygunluğu hazırlanmalıdır.
Hangi kaynaklar belirlenir?
CPU, PHP, Node.js, Python, Java veya benzeri uygulama süreçlerinin hesaplama ihtiyacını karşılar. Yoğun rapor, görsel işleme, şifreleme ve arama işlemleri CPU tüketimini artırır.
RAM, uygulama süreçleri, veritabanı önbelleği, işletim sistemi önbelleği ve bağlantı havuzları tarafından kullanılır. RAM yetersiz kalırsa sistem diske taşma yapabilir; bu da yanıt sürelerini belirgin biçimde kötüleştirir.
Disk için yalnız kapasiteye değil, okuma-yazma gecikmesine ve IOPS ihtiyacına da bakılır. Veritabanı, oturum dosyaları, yüklenen içerikler, günlükler ve yedekler aynı diski kullanıyorsa bu tüketimler ayrı hesaplanmalıdır.
Ağ kapasitesi, özellikle dosya indirme, video, görsel ve API yanıtlarında önemlidir. Trafik hesabına yalnız ortalama değil, yoğun saatlerdeki ani artış da dahil edilmelidir.
Veritabanı çoğu uygulamada ayrı bir darboğazdır. Bağlantı sayısı, sorgu süresi, indeksler, kilitlenmeler ve sorgu başına okunan veri miktarı sunucu seçimini doğrudan etkiler.
Kapasiteyi belirleme yöntemi
Aşağıdaki sırayı izleyerek ölçülebilir bir başlangıç planı oluşturun:
- Uygulamanın çalışma şeklini yazın: statik sayfa, oturum kullanan panel, e-ticaret, API, arka plan işi veya dosya işleme gibi iş yüklerini ayırın.
- Yoğun saat için varsayım belirleyin. Örneğin saniyede 10 istek, istek başına ortalama 200 KB yanıt, aynı anda 100 aktif kullanıcı ve ayrı bir veritabanı sorgusu kullanan bir uygulama varsayın. Bu değerler ölçüm değil, test planı girdisidir.
- Uygulamayı bu yükü ve kısa süreli artışı temsil eden bir testle çalıştırın. Test sırasında CPU kullanımı, kullanılabilir RAM, disk gecikmesi, ağ aktarımı, veritabanı sorgu süresi, hata oranı ve yanıt sürelerini birlikte kaydedin.
- Ölçümde ilk doygunluğa ulaşan kaynağı bulun. CPU sürekli doluyorsa sorgu veya uygulama kodunu inceleyin; RAM azalıyor ve takas kullanılıyorsa bellek tüketimini inceleyin; disk bekleme süresi yükseliyorsa veritabanı, günlükleme veya disk tipini değerlendirin.
- Kaynağı artırmadan önce yazılım tarafındaki nedeni düzeltin. Eksik indeks, gereksiz sorgu, sınırsız günlük, büyük oturum verisi veya yanlış önbellek kullanımı daha büyük sunucuyla yalnızca ertelenebilir.
- Düzeltmeden sonra aynı testi tekrarlayın. Hedef yalnızca ortalama yanıt süresi değil; hata oranının düşük kalması, yoğun isteklerde kabul edilebilir gecikme ve sistemin test sonunda toparlanabilmesidir.
- Sonucu bir başlangıç kapasitesine çevirin ve izleme uyarıları kurun. Gerçek trafik varsayımı aşarsa dikey büyütme, yatay çoğaltma, ayrı veritabanı veya önbellek gibi bir sonraki adımı önceden belirleyin.
Test için gecikme/hata hedefini baştan yazın; p95/p99, sürdürülebilen istek hızı ve kuyruk uzunluğunu izleyin. Aktif kullanıcı sayısı eşzamanlı uçuş hâlindeki istek sayısı değildir: kararlı durumda10 istek/s ×0,2 saniye yaklaşık2 eşzamanlı istek eder. Temsili200KB yanıt ×10 istek/s yaklaşık2MB/s (16Mbit/s) gövde trafiğidir; protokol ve diğer varlıklar ek yük getirir. Bunlar sunucu modeline veya RAM miktarına doğrudan çevrilemez. Yük testini yetkili kontrollü ortamda yapın; ödeme/e-posta gibi gerçek yan etkileri sınırlandırın.
Varsayımlı örnek
Bir katalog uygulamasında yoğun saatte 10 istek/saniye, 100 eşzamanlı kullanıcı ve küçük görsellerin uygulama sunucusundan gönderildiğini varsayalım. Test sırasında CPU düşük kalırken RAM hızla tükeniyor ve yanıt süresi disk beklemesiyle artıyorsa ilk karar daha fazla CPU eklemek değildir. Görselleri ayrı bir depolama veya önbellek katmanına almak, uygulama süreçlerinin bellek sınırlarını kontrol etmek ve veritabanı sorgularını incelemek daha doğru ilk adımdır.
Tersine, RAM yeterli olduğu hâlde tek bir uygulama süreci CPU'yu sürekli tüketiyorsa pahalı bir sunucuya geçmeden önce yavaş sorgu, döngüsel işlem, sıkıştırma veya gereksiz veri dönüştürme araştırılmalıdır. Test başarısız olursa sonuç, uygulamanın bu yükü karşılayamadığı anlamına gelir; hangi kaynağın yetersiz olduğunu metriklerden ayırmadan kaynak seçmek doğru değildir.
Aşağıdaki tablo, gözlenen belirti ile ilk inceleme yönünü eşleştirir:
| Belirti | Muhtemel kaynak | İlk karar |
|---|---|---|
| CPU sürekli yüksek | Kod, sorgu veya işlem yoğunluğu | Profil çıkarın, sorguları ve süreç sayısını inceleyin |
| RAM azalıyor, takas artıyor | Süreç, önbellek veya bağlantı tüketimi | Bellek tüketimini sınırlayın ve sızıntıyı araştırın |
| Disk beklemesi yükseliyor | Veritabanı, günlük veya yavaş depolama | Sorgu, günlükleme ve disk gecikmesini ölçün |
| Ağ doluyor | Büyük yanıtlar veya dosya aktarımı | Önbellek, sıkıştırma ve ayrı dosya sunumunu değerlendirin |
Bu tablo doğrudan kaynak artırma listesi değildir. Aynı belirti birden fazla nedenden oluşabileceği için değişiklikten sonra yeniden ölçüm yapılmalıdır.
Sık yapılan hatalar
Yalnız ziyaretçi sayısını kullanmak: Aynı kullanıcı sayısı, basit bir sayfada düşük; rapor veya arama yapan uygulamada yüksek kaynak tüketebilir.
Eşzamanlılık ile toplam trafiği karıştırmak: Aylık veya günlük toplam istek, aynı anda kaç isteğin işlendiğini göstermez. Sunucu kapasitesini özellikle yoğun an belirler.
Ortalama değere güvenmek: Ortalama yanıt süresi iyi görünürken az sayıdaki çok yavaş istek kullanıcı deneyimini bozabilir. Dağılımı, hata oranını ve en yavaş istekleri de izleyin.
Yedek ve günlükleri hesaba katmamak: Disk kapasitesi yalnız uygulama dosyalarından oluşmaz. Günlüklerin büyümesi ve yedeklerin aynı depolamada tutulması ayrıca planlanmalıdır.
Tek testle karar vermek: Önbellek sıcaklığı, arka plan görevleri ve trafik şekli sonucu değiştirebilir. Farklı senaryoları ve kısa süreli yoğunluğu ayrı test edin.
Kaynaklar
Sık sorulan sorular
Kaynak planı ne zaman yeniden gözden geçirilmelidir?
Uygulamanın iş yükü, veri hacmi, kodu veya mimarisi değiştiğinde; ayrıca izleme değerleri uzun süre mevcut kapasiteye yaklaştığında yeniden test yapılmalıdır. Büyük sürüm değişiklikleri de kapasite testi için uygun bir zamandır.
Tek sunucu mu, birden fazla sunucu mu seçilmelidir?
Karar yalnız kaynak miktarına bağlı değildir. Uygulama durum bilgisiz çalışabiliyor, dosyalar ortak veya ayrı depolanabiliyor ve veritabanı bağlantısı güvenilir biçimde yönetilebiliyorsa yatay çoğaltma değerlendirilebilir. Aksi durumda önce uygulamanın bu mimariye uygunluğu hazırlanmalıdır.
