- Kimler için?
- Küçük VDS üzerinde mobil backend kuran geliştiriciler ve bütçe planlayan ekipler.
- Başlamadan önce
- Temsili veri seti, test ortamı ve normal/yoğun kullanıcı akışları.
1. Aylık kullanıcıyı eşzamanlı yükten ayırın
10.000 aylık kullanıcı günün farklı saatlerinde uygulamaya girebilir veya bir bildirim sonrası aynı dakika içinde dönebilir. Sunucuyu zorlayan durum aynı anda yürüyen iş ve her işin maliyetidir. Sadece giriş sayısını değil, kullanıcı oturumundaki liste, arama, dosya ve yazma isteklerini de modele ekleyin. Gerçek üretim davranışı yoksa varsayımları açıkça kaydedin.
2. Belleği servisler arasında paylaştırın
İşletim sistemi, API süreci, veritabanı, bağlantı havuzu ve worker aynı RAM’i tüketir. Uygulamaya ayrılan kota ile VDS’nin toplam belleğini karıştırmayın. Worker’ın büyük görsel işleme görevi API’yi bellek baskısına sokabilir. Çok sayıda süreç açmak da her süreç için taban bellek tüketimini büyütür.
| Kaynak | İzlenecek işaret | İlk müdahale |
|---|---|---|
| RAM | RSS ve bellek baskısı | Süreç/iş boyutunu sınırlama |
| Veritabanı | Bağlantı ve yavaş sorgu | Havuz, indeks ve sorgu düzeltme |
| CPU | Uzun iş ve kuyruk | Ağır işi worker’a ayırma |
| Disk | Doluluk ve gecikme | Retention ve kapasite planı |
3. Temsili yük testi kurun
Boş tabloya tek endpoint çağırmak kapasite ölçümü değildir. Normal liste boyutunu, veri ilişkilerini ve kullanıcı yetkisini içeren örnekler hazırlayın. Okuma/yazma dağılımını ve bir oturumun düşünme süresini modele ekleyin. Testi size ait staging ortamında yapın; canlı kullanıcıları etkileyecek sınırsız yük üretmeyin. Önce düşük trafik, sonra kademeli artış ve kısa yoğunluk deneyi kullanın.
4. Kabul kriterini önceden yazın
Başarıyı yalnızca ortalama yanıtla değerlendirmeyin. p95 gecikme, hata oranı, timeout ve kuyrukta bekleme hedefleri belirleyin. Test boyunca RAM, CPU, veritabanı bağlantısı ve disk gecikmesini kaydedin. Sistem trafik düştüğünde toparlanmıyorsa düşük ortalama süre yanıltıcı olabilir.
Rapor: veri büyüklüğü + akış karışımı + eşzamanlılık + süre
Sonuç: p50 / p95 + hata oranı + kaynak kullanımı + toparlanma5. Sonucu bütçeye ve ölçekleme kararına bağlayın
Önce yavaş sorgu, gereksiz veri ve sınırsız iş kuyruğu gibi tasarım sorunlarını düzeltin. Ardından daha büyük kaynak, ayrı veritabanı veya ayrı worker seçeneklerini test edin. Bir test sonucunu tüm mobil uygulamalara genellemeyin. Uygulama Cloud paketleri planlanan kaynak kapsamını belirtir; kullanıcı, SLA veya eşzamanlı bağlantı garantisi içermez.
Uygulama özeti
- MAU ile eşzamanlılığı ayırın.
- Gerçekçi veri ve kullanıcı akışıyla test edin.
- Sonucu gecikme, hata ve toparlanma kriterleriyle değerlendirin.
Sık sorulan sorular
2 GB VDS kesin kaç kullanıcı taşır?
İş yükü tanımlanmadan güvenilir bir sayı verilemez. Eşzamanlı istek ve her isteğin maliyeti ölçülmelidir.
CPU düşükse kapasite sorunu yok mu?
Hayır. Veritabanı bağlantısı, RAM, disk, ağ veya kuyruk darboğazı CPU düşükken de oluşabilir.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: