Application Insights içindeki eski Performance Testing ekranı üzerinden anlatılan yük testi akışı artık güncel değil. Azure’da yeni testler için Azure Load Testing kullanılıyor; basit bir HTTP testi URL ile başlayabiliyor, daha ayrıntılı senaryolarda JMeter veya Locust betikleri devreye giriyor. Eski ekranı bulamamanız bu yüzden.
Bu yazıyı güncel hizmete göre yeniden düzenliyorum. Önce testin neyi ölçeceğini belirleyeceğiz, sonra güvenli bir başlangıç yükü kurup sonuçları uygulama metrikleriyle okuyacağız. İlk sürümdeki ekran görüntüleri korunuyor, ancak bunların 2020 dönemindeki hizmete ait olduğunu göz önünde bulundurun.
Yük testinden hangi cevabı bekliyorsunuz?
Yük testi, belirli bir trafik altında uygulamanın yanıt süresini ve hata davranışını ölçer. Ana sayfanın bir kez hızlı açılması, aynı anda çok sayıda istekte de hızlı kalacağını göstermez. Veritabanı bağlantıları tükenebilir veya arka plandaki bir servis istekleri sıraya almaya başlayabilir.
Test planını tek bir soruyla sınırlandırmak işinizi kolaylaştırır. Örneğin ürün arama isteğinin beklenen trafik altında kabul edilen sürede cevap vermesini kontrol edebilirsiniz. Ana sayfa, oturum açma ve ödeme akışını tek toplam sonuçta birleştirirseniz yavaşlığın nerede başladığını bulmak zorlaşır.
Sanal kullanıcı sayısı da doğrudan saniyedeki istek sayısı anlamına gelmez. İstekler arasındaki bekleme süresi ve sunucunun yanıtı, üretilen trafiği etkiler. Gerçek kullanıcıların sayfa okuduğu bir akışı beklemesiz döngüyle çalıştırmak, beklediğinizden çok daha ağır yük oluşturabilir.
Eski Application Insights ekranına dönmeyin
İlk sürümde Application Insights kaynağı ve Azure DevOps hesabı üzerinden ilerliyorduk. Aşağıdaki ekran o eski bağlantıyı gösteriyor; güncel hizmet için zorunlu kurulum sırası olarak kullanılmamalı. Ekrandaki 20.000 kullanıcı ve 60 dakika değerleri de bugünkü hizmetin sınırı veya önerisi değildir.
Microsoft’un güncel hızlı başlangıcı, Azure App Testing üzerinden bir Azure Load Testing kaynağı oluşturup URL tabanlı test açmayı anlatıyor. Uygulamanızın Azure’da barınması şart değil; test motorunun hedefe erişebilmesi gerekiyor.
Kaynak oluşturma yetkisiyle test çalıştırma yetkisini ayrı düşünün. Azure kaynak yönetiminde geniş yetkili bir rol vermek yerine ekip üyelerine ihtiyaçları olan yük testi rollerini atayın. Private ağdaki uygulamalarda bağlantı yolunu ve ad çözümlemesini testten önce hazırlayın.
Hizmetin genel bakış sayfasında desteklenen senaryo türleri açıklanıyor. URL tabanlı başlangıç, JMeter test planı ve Locust senaryosu aynı hazırlık maliyetine sahip değil. Önce ölçmek istediğiniz akışın gerektirdiği en basit yöntemi seçin.
İlk testi küçük ve kontrollü kurun
Yalnız sahibi olduğunuz veya test izniniz bulunan uygulamayı hedefleyin. İlk denemeyi üretim dışı ortamda yapmanız, beklenmedik hata oranında gerçek kullanıcıları etkilemeden durabilmenizi sağlar. Ödeme, e-posta veya SMS gibi ücretli yan etkileri olan akışları test ortamına yönlendirin.
Azure Load Testing kaynağında URL tabanlı test açın, hedef adresi ve HTTP yöntemini girin. Güncel hızlı başlangıçta aynı teste beş HTTP isteğine kadar eklenebiliyor. Header veya istek gövdesi gerekiyorsa bunları senaryonun parçası olarak tanımlayın.
Ardından sanal kullanıcı sayısını, toplam süreyi ve ramp-up süresini belirleyin. Ramp-up, kullanıcıları bir anda başlatmak yerine yükü kademeli artırır. Ben ilk koşuda, hedefi zorlamadan bağlantı ve senaryo doğruluğunu görmenizi öneriyorum.
Güncel kotaları kaynak ve test türünüz için ayrıca kontrol edin. Aşağıdaki Visual Studio test projesi ekranı eski yönteme ait; URL tabanlı yeni test için bu projeyi oluşturmanız gerekmiyor.
Basit URL isteği, tarayıcının yaptığı her işi taklit etmez. JavaScript çalıştırma, oturum boyunca taşınan token veya birbirine bağlı API çağrıları gerekiyorsa bunu test betiğine modellemek gerekir. Giriş ekranına gelen 200 cevabı, kullanıcının gerçekten oturum açtığını kanıtlamaz.
Başarı ölçütünü koşudan önce yazın
Hata oranı, yanıt süresi ve beklenen trafik için kabul sınırını uygulama sahibinin belirlemesi gerekir. İnternette görülen tek bir milisaniye değerini bütün sistemlere uygulamayın. Arama isteğiyle büyük rapor üretiminin kabul edilen süresi farklı olabilir.
Ortalamanın yanına yüzde birlik dilimleri de koyun. p95, isteklerin yüzde 95’inin altında kaldığı yanıt süresini gösterir; kalan yavaş istekleri ortalama içinde kaybetmemenize yardımcı olur. Hata yüzdesi yükselirken ortalama sürenin düşmesi ise uygulamanın daha hızlı çalıştığını göstermeyebilir, hatalı istekler erken dönüyor olabilir.
Testi durdurma koşulunu da belirleyin. Beklenmedik hata artışı, kaynak tükenmesi veya bağımlı serviste sorun görürseniz yükü sürdürmeyin. Canlı sistemde test yapılacaksa bakım penceresi, sorumlu kişi ve durdurma yetkisi önceden açık olmalı.
Grafikleri uygulama tarafıyla birlikte okuyun
Azure Load Testing sonuçlarında istek sayısı, yanıt süresi, hata oranı ve throughput gibi değerleri görebilirsiniz. Throughput, zaman içinde işlenen istek miktarını anlatır. Kullanıcı sayısını artırdığınızda bu değer yerinde kalırken gecikme büyüyorsa sistemin bir bölümünde kapasite sınırına yaklaşmış olabilirsiniz.
Bu görüntü eski sonuç ekranına ait; üzerindeki sayılar yeni bir ölçüm sonucu değil. Güncel koşuda sonuçları aynı zaman aralığındaki uygulama telemetrisiyle karşılaştırın. CPU yükselmesiyle veritabanı bağlantı havuzunun dolması farklı müdahaleler gerektirir.
Application Insights burada hala işe yarar. İsteklerin hangi bağımlılıkta zaman geçirdiğini, hata kodlarını ve istisnaları inceleyebilirsiniz. Test motorunun hedefe ulaşamamasıyla uygulamanın iş mantığında hata üretmesini ayırın. Güvenlik duvarından dönen cevap, kapasite sonucu olarak yorumlanmamalı.
İkinci koşuyu ilk koşuyla karşılaştırırken uygulama sürümünü ve test parametrelerini kaydedin. Önbelleğin boş veya dolu olması bile sonucu değiştirebilir. Birden fazla ayarı aynı anda değiştirirseniz iyileşmenin hangisinden geldiğini söyleyemezsiniz.
Eski fiyat tablosunu bütçeye taşımayın
İlk yazıdaki aşağıdaki tablo 2020 döneminin ücretlendirmesini gösteriyor. Güncel Azure Load Testing maliyetini bu sayılardan hesaplamayın.
Güncel fiyat sayfasından test tüketimini kontrol edin. Uygulamanın ölçeklenmesi ve telemetri toplama maliyeti de kendi kaynaklarında oluşabilir. Test bittikten sonra sonuçları saklamakla kullanılmayan test kaynaklarını açık bırakmak ayrı kararlar.
Bir sonraki koşu için
- Senaryonun gerçekten hedeflediğiniz işlemi yaptığını doğrulayın.
- Düşük yükte başlayın, kabul ve durdurma sınırlarını önceden belirleyin.
- Sonuçları aynı zaman aralığındaki uygulama metrikleriyle karşılaştırın.
- Tek bir değişiklik yapıp aynı koşullarda yeniden ölçün.
İyi bir test raporu, hangi koşulda hangi isteğin yavaşladığını tekrar gösterebilmelidir. Sorularınız olursa yorumlarda buluşalım.
