Apache Jmeter Response Assertion Kullanımı ve Performans Maliyetleri

Apache JMeter, yazılım uygulamalarının performansını test etmek için kullanılan ücretsiz ve açık kaynaklı bir araçtır. Java tabanlı olan bu araç, özellikle servis olarak bilinen API katmanlarını, Web arayüzlerini, veri tabanları ve diğer servislerin yük altında nasıl davrandığını ölçmek için tercih edilir. JMeter sayesinde geliştiriciler ve test uzmanları, sistemin farklı senaryolarda ne kadar dayanıklı olduğunu görerek performans darboğazlarını önce den tespit edebilirler. Genelde test ortamlarında Production (Canlı) olarak bilinen ortama en yakın Branch olan PREPROD ortamda performans testleri koşulur ve senaryolar bu ortama göre üretilir. Canlı ortama en yakın simüle edilebilecek yer burası olduğu için. Uygulamanın ücretsiz olması, JMeter aracının en büyük avantajlarından biridir. Lisans maliyeti olmadığı için her ölçekteki kurum ve ekip tarafından rahatlıkla kullanılabilir. Ayrıca açık kaynak yapısı sayesinde sürekli gelişmekte, topluluk desteğiyle yeni eklentiler ve özellikler kazanmaktadır. Kullanıcılar, test senaryolarını kolayca kaydedebilir, düzenleyebilir ve görselleştirilmiş raporlar alabilir. JMeter’ın sunduğu bir diğer önemli fayda, esnekliğidir. Tek bir sunucu üzerindeki küçük testlerden, yüzlerce kullanıcıyı aynı anda simüle eden geniş kapsamlı yük testlerine kadar her ölçekte kullanılabilir. Bu sayede hem yazılım geliştirme aşamasında, hem de canlıya geçiş öncesinde güvenilir sonuçlar elde edilir. Sonuç olarak Apache JMeter, maliyetsiz oluşu ve güçlü özellikleriyle performans testlerinde yaygın ve etkili bir çözümdür. Bu yazımda Apache JMeter ile ilgili Response Assertion ve sunucu maliyetleri ile ilgili bilgi vermenin yanında not aldığım birkaç ufak bilgilerde sizlerle maddeler şeklinde paylaşmaya çalışacağım.

1) Apache Jmeter Response Assertion Kullanımı

Apache Jmeter uygulamasında Response Assertion özelliğini genelde API (Servis) testi yaparken servisin verdiği Response Code değerini kontrol etmek için genelde kullanıyoruz. Bildiğiniz gibi 200 kodu servislerde başarılı dönen sonuç olup 500 hatası sistem hatası ve 404 ise Not Found (Kayıt Bulunamadı) hatasıdır. Bu hatalar dışında 403, 409, 401, 204 gibi hatalarda vardır. Response Assertion özelliğini daha iyi anlatmak için bir senaryo oluşturalım. Örneğin siz bir performans testi koşuyorsunuz ve dönen servis kodu sonuçlarından 200 ve 404 kodlarının View Results Tree ekranında görmek istemiyorsunuz. Çünkü bu hatalar dışında gelecek 500 veya 403 gibi hata kodlarını görüp ayıklamak istiyorsunuz. O zaman oluşturacağız Response Assertion şu şekilde olacaktır. Öncelikle Test Plan alanından Add diyerek Assertions kısmından Response Assertion sekmesini testinizde ekleyin.

Name: Bu kısım çok önemli olmayıp burayı Response Assertion olarak da bırakabilirsiniz veya Assertion (200-404) olarak adını Custom güncelleyebilirsiniz takip edebilmek için.

Apply to: Buradaki alanı klasik “Main Sample only” seçebilirsiniz. Bu seçenek yalnızca bir (Sampler) servis çağrısının sonucu için geçerlidir.

Field to Test: Burada “Response Code” kısmını seçiniz ve “Ignore Status" alanı mutlaka seçili olsun.

Pattern Matching Rules: Burada ise “Matches” alanını seçiniz ve iki adet Response Code değeri gireceğimiz için “Or” kutucuğunu mutlaka seçmeliyiz.

Patterns to Test: Bu kısımda 200 ve 404 kodlarını eklerken Add diyerek eklemeliyiz resimdeki gibi. Alt alta sadece alt satır olacak şekilde asla eklemeyin o zaman algılamıyor. Yine aynı şekilde 200,404 veya 200|404 gibi kodları yan yana şeklinde de yazmayınız.

2) Apache Jmeter uygulamasını ücretsiz olarak “jmeter.apache.org” sitesinden indirebilirsiniz. Portable bir uygulama olup “bin” klasörü içerisindeki “Jmeter.bat” dosyasını çalıştırarak performans test yönetim arayüzünü açabilirsiniz. Apache JMeter uygulamasının son kararlı versiyonu 5.6.3 olup uygulamanın çalışması için bilgisayarda JAVA programının yüklü olması gerekmektedir.

3) Apache Jmeter Heap Memory ve JVM Ayarları

JMeter performansını artırmak için Windows ortamda “bin/jmeter.bat” dosyasını düzenlemeniz gerekmektedir. Eğer (Master Slave) senaryo ile çalışma yapıyorsan yük oluşturan her Slave Node üzerinde “bin/jmeter-server.bat” dosyasındaki ayarları değiştirmelisin. Çünkü yük aslında orada üretiliyor. Örnek HEAP ayarını aşağıdaki gibi değiştirebilirsiniz sunucunun RAM ve CPU değerlerine göre. Tüm bu HEAP ayarlarını testi başlattığınız Master sunucu ve diğer tüm Slave sunucular üzerinde tek tek yapabilirsiniz.

set HEAP=-Xms512m -Xmx4096m

Xms = Başlangıç Belleği (Örneğin 512 MB)

Xmx = Maksimum Heap Belleği (Örneğin 4 GB, RAM belleğe göre ayarlanmalı.)

16 GB Ram bellek ve üzeri büyük yük testleri için aşağıdaki ilk HEAP ayarını SET ederek kullanabilirsiniz. Eğer 8 GB Ram belleğiniz varsa ikinci değeri baz alabilirsiniz.

set HEAP=-Xms2g -Xmx8g -XX:MaxMetaspaceSize=1g

set HEAP=-Xms1g -Xmx4g -XX:MaxMetaspaceSize=512m

Önemli bir not vermek gerekirse; Xms ve Xmx değerlerini çok yüksek verirsen Windows işletim sistemi üzerinde JVM açılmayabilir. RAM değerinin yaklaşık yarısını JMeter uygulamasına ayırmak genelde güvenli bir yaklaşımdır.

4) Donanıma Göre JMeter Thread Kapasitesi (Tek Slave Değeri)

Apache Jmeter sunucularını çalıştırırken GUI yani JMeter yönetim arayüzü açık iken ve optimize edilmiş HEAP ayarları ile birlikte bir Slave sunucusu aşağıdaki donanım bilgisine göre kaç Thread gider, yaklaşık olarak değerleri paylaştım. Kural olarak GUI açıkken, Non-GUI senaryoya göre kapasite genelde %30-50 daha düşük olacaktır. Senaryon karmaşıksa (JSON Parse, Regex, Groovy test kodları gibi) bu düşüş daha da artacaktır.

* 4 GB RAM + 2 CPU (Çekirdek): 150–250 Thread

* 8 GB RAM + 4 CPU (Çekirdek): 500–800 Thread

* 16 GB RAM + 6 CPU (Çekirdek): 1200–1700 Thread

* 16 GB RAM + 8 CPU (Çekirdek): 1500–2000 Thread

* 32 GB RAM + 8 CPU (Çekirdek): 2500–3500 Thread

* 32 GB RAM + 16 CPU (Çekirdek): 4000–6000 Thread

Performans testi koşarken GUI (JMeter Arayüzü) açık iken maksimum verim için aşağıdaki ipuçları uygulayabilirsin.

* Test koşarken View Results Tree ve Graph Results kapalı olsun, sadece Simple Data Writer ile JTL’ye yazdır.

* HEAP ayarını GUI açık iken biraz cömert tut (örnek olarak 16 GB RAM için -Xms1g -Xmx4g) ayarlaman faydalı olur, sunucuyu çok boğma.

* Canlı grafik istiyorsan GUI üzerinde çizdirmek yerine Backend Listener (InfluxDB/Grafana) kullanabilirsin.

* Master Slave senaryolarda mümkünse GUI arayüzünü sadece kontrol için kullan Master sunucuda, yükü Slave üzerinde Non-GUI olarak koştur.

Burak AVCI - Update: 02.09.2025