Performans Testi: JMeter ve k6 ile Yük Testi Nasıl Yapılır?

Performans testi nedir ve neden yapılır?

Performans testi, bir uygulamanın belirli bir kullanıcı yükü altında ne kadar hızlı, kararlı ve verimli çalıştığını ölçen test türüdür. Fonksiyonel test "doğru sonucu veriyor mu" sorusunu sorar. Performans testi ise "aynı sonucu çok sayıda kullanıcıya, kabul edilebilir sürede verebiliyor mu" sorusunu sorar.

Amaç, kampanya, dönem sonu ya da yeni sürüm gibi yoğun anlarda yaşanacak yavaşlamayı ve kesintiyi gerçek kullanıcılar yaşamadan önce görmektir. Test sonucunda ortaya çıkan veri, hem yazılım ekibine darboğazın yerini gösterir hem de altyapı ekibine kapasite kararı için dayanak olur.

Pratikte bir performans testi çalışması şu sırayla ilerler: önce iş açısından kritik akış seçilir (örneğin giriş, arama, ödeme), sonra bu akış için kabul edilebilir yanıt süresi ve hata oranı iş birimiyle birlikte yazıya dökülür. Ardından gerçek kullanım kayıtlarından ya da erişim günlüklerinden bir kullanıcı davranış profili çıkarılır, test verisi hazırlanır, senaryo önce tek kullanıcıyla doğrulanır ve ancak sonra yük kademeli artırılır. Başarı ölçütü testten önce yazılmazsa, sonuçlar her isteyen tarafından kendi lehine yorumlanabilir.

Hangi performans test türleri vardır?

Test türleri, hangi soruya yanıt aradığınıza göre ayrılır.

• Yük testi: Beklenen normal ve yoğun kullanıcı sayısı altında sistemin davranışını ölçer.
• Stres testi: Yükü sistemin sınırının ötesine taşıyarak nerede ve nasıl bozulduğunu, bozulduktan sonra toparlanıp toparlanmadığını görür.
• Dayanıklılık (soak) testi: Orta düzey yükü uzun süre uygulayarak bellek sızıntısı ve kaynak tükenmesi gibi yavaş gelişen sorunları arar.
• Ani yük (spike) testi: Trafiğin kısa sürede aniden artmasına sistemin tepkisini inceler.

Bir proje çoğu zaman bunların hepsine ihtiyaç duymaz. Önce iş açısından en kritik akışı ve en olası riski belirleyip ona uygun türü seçmek, test çabasını odaklı tutar.

JMeter ile test nasıl tasarlanır?

Apache JMeter, grafik arayüzü olan, açık kaynaklı bir test aracıdır. Temel akış şöyledir: bir test planı oluşturulur, içine kullanıcı gruplarını (thread group) temsil eden bir yapı eklenir, her kullanıcının yapacağı istekler örnekleyiciler (sampler) ile tanımlanır ve sonuçlar dinleyicilerle (listener) toplanır.

Gerçekçi bir senaryo için istekleri gerçek bir kullanıcı yolculuğuna benzetin: giriş yap, ürün ara, sepete ekle gibi. Kullanıcı arasında bekleme süresi (düşünme zamanı) ekleyin; aksi halde yük gerçek kullanımdan çok daha sert olur. Oturum anahtarı ya da dinamik değer gibi her istekte değişen verileri, yanıttan çıkarıp sonraki isteğe taşıyan ayıklayıcılarla (extractor) yönetin. Test verisini ayrı bir dosyadan okutarak her sanal kullanıcının farklı bilgiyle çalışmasını sağlayın.

k6 ile kod olarak performans testi

k6, testlerin JavaScript ile yazıldığı, komut satırından çalışan modern bir yük testi aracıdır. Test betiği sürüm kontrolünde diğer kodla birlikte durabilir, kod incelemesinden geçebilir ve sürekli entegrasyon hattında otomatik koşulabilir. Bu yüzden her sürümde tekrarlanması gereken testlerde pratiktir.

Bir k6 betiği, sanal kullanıcı sayısını ve süreyi tanımlayan bir ayar bölümü ile her kullanıcının tekrar edeceği bir ana işlevden oluşur. Eşik (threshold) tanımlayarak testi "geçti ya da kaldı" biçiminde değerlendirebilirsiniz. Örneğin yanıt süresinin belirli bir sınırı aşması durumunda testin başarısız sayılması gibi. JMeter ile k6 arasında seçim; ekibin alışkanlığına, arayüz ya da kod tercihine ve otomasyon ihtiyacına bağlıdır, ikisi de ciddi işlerde kullanılır.

Sonuçlar nasıl okunur, darboğaz nasıl bulunur?

Ortalama yanıt süresi tek başına yanıltıcıdır. Bunun yerine yüzdelik dilimlere (örneğin yavaş kalan kullanıcı grubunun süresine), hata oranına ve saniyedeki işlem hacmine birlikte bakın. Bu ölçümlerin yük arttıkça nasıl değiştiğini izleyin: işlem hacmi artmayı bırakıp yanıt süresi yükseliyorsa sistem doygunluğa ulaşmış demektir.

Darboğazı bulmak için test ölçümlerini sunucu tarafı izlemeyle eşleştirin. İşlemci, bellek, disk, ağ, veritabanı bağlantı havuzu ve yavaş sorgular gibi kaynakları aynı zaman çizelgesinde inceleyin. Yanıt süresinin yükseldiği anda hangi kaynağın tavan yaptığı, sorunun uygulama kodunda, veritabanında ya da altyapıda olduğunu gösterir. Bir seferde tek değişiklik yapıp testi yeniden koşmak, hangi iyileştirmenin işe yaradığını netleştirir.

Sık yapılan hatalar ve raporlama

Sık görülen hatalar şunlardır: • Test ortamını üretim ortamından çok farklı kurmak ve sonucu kesin kabul etmek. • Düşünme zamanı eklemeden gerçekçi olmayan yük üretmek. • Önbelleğe alınmış tek bir isteği tekrarlayıp sistemi olduğundan hızlı sanmak. • Yük üreten makinenin kendisini darboğaz haline getirmek. • Test öncesinde başarı ölçütünü tanımlamamak.

Başka bir sık hata, testi yalnızca yayın öncesi son haftaya bırakmaktır. Bulunan darboğazın düzeltilmesi çoğu zaman mimari değişiklik gerektirir; bu yüzden kritik akışlar için küçük ölçekli testleri geliştirme sürecine yaymak, her sürümde aynı senaryoyu koşturup sonuçları bir öncekiyle karşılaştırmak daha sağlıklıdır. Karşılaştırma için test ortamını, veri hacmini ve senaryoyu sabit tutmak gerekir; aksi halde fark, değişikliğin değil ortamın sonucu olur.

Rapor, teknik olmayan karar vericinin de anlayacağı şekilde, test amacı, senaryo, ortam, ölçülen değerler, bulunan darboğazlar ve önerilen aksiyonlarla yazılmalıdır. Kapasite planlaması için, mevcut sistemin hangi yük seviyesine kadar kabul edilebilir yanıt verdiğini ve büyüme beklentisine göre ne zaman ek kaynak gerekeceğini de raporda belirtin.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Mindset kataloğundaki Performance Testing (JMeter, k6) eğitimi, bu yolu şu modül başlıklarıyla ele alır: Performans Testi Kavramları ve Test Türleri, Apache JMeter ile Test Tasarımı, JMeter Gelişmiş Özellikler, k6 ile Modern Performans Testi, Sonuç Analizi ve Darboğaz Tespiti, Performans Raporu ve Kapasite Planlaması.

Bu dizilim kavramdan araca, araçtan sonuç yorumlamaya ve raporlamaya doğru ilerler.