Bir API, her işlevsel testi geçebilir ve yine de üretimde başarısız olabilir. Doğru veriyi, doğru durum koduyla, doğru şemaya göre döndürür ve ardından binlerce kullanıcı aynı anda eriştiğinde çöker. İşlevsel testler, API'nin doğru çalıştığını söyler. Performans testleri ise doğru ve gerçek trafiğe dayanacak kadar hızlı olduğunu söyler.
Bu kılavuz, API performans testinin ne olduğunu, önemli test türlerini, izlenecek metrikleri ve Apidog'da adım adım nasıl performans testi yapılacağını açıklamaktadır.
API performans testi nedir
API performans testi, bir API'nin yük altında nasıl davrandığını ölçer: ne kadar hızlı yanıt verdiğini, kaç isteği işleyebildiğini ve hangi noktada performansının düştüğünü veya çöktüğünü. Yanıtın doğru olup olmadığıyla ilgili değildir; bu, işlevsel testtir. Bu, sistem baskı altındayken yanıtın hızlı ve güvenilir bir şekilde gelip gelmediğiyle ilgilidir.
Amaç, kullanıcılarınızdan önce sınırları bulmaktır. Her API'nin bir tavanı vardır; yanıt sürelerinin uzadığı, hataların ortaya çıktığı veya hizmetin yanıt vermeyi durdurduğu bir nokta. Performans testi, bu tavanı kontrollü bir ortamda bulur, böylece onu yükseltebilir, etrafında kapasite planlayabilir veya en azından varlığını bilebilirsiniz.
API'ler, belirleyici ve çağrılması hızlı oldukları için performans testi için iyi bir hedeftir. Oluşturulacak bir tarayıcı veya beklenecek bir kullanıcı arayüzü yoktur. Bir istek gönderir, yanıtı ölçersiniz. Bu, API performans testlerini tam uçtan uca yük testlerinden daha ucuza ve daha kararlı hale getirir.
Performans testinin türleri
"Performans testi" bir şemsiye terimdir. Bunun altında, her biri farklı bir soruyu yanıtlayan birkaç farklı test türü bulunur.
Yük testi, gerçekten beklediğiniz trafiği, normal ve yoğun istek hacminizi uygular ve API'nin kabul edilebilir yanıt süreleri içinde bu trafiği karşıladığını doğrular. Bu, çoğu ekibin ilk çalıştırdığı temel testtir.
Stres testi, beklenen trafiğin ötesine geçer, API'nin performansı düşene veya çökene kadar yükü artırır. Amaç, kırılma noktasını bulmak ve nasıl bozulduğunu görmektir. Yavaş yavaş mı yavaşlar, yoksa hatalar mı döndürür ve veri mi kaybeder?
Ani yük testi (Spike testi), ani bir indirim veya viral bir anın yol açtığı türden, trafikte ani, keskin bir sıçrama uygular ve API'nin bunu absorbe edip etmediğini veya çöküp çökmediğini kontrol eder. Sabit yükü kaldırabilen bir sistem, ani bir yükte yine de başarısız olabilir.
Dayanıklılık testi (Soak testi) olarak da adlandırılan bu test, yavaş sorunları ortaya çıkarmak için saatler veya günler boyunca orta düzeyde bir yükü sürdürür: bellek sızıntıları, bağlantı havuzu tükenmesi, günlük dosyalarının diski doldurması. Bunlar, beş dakikalık bir yük testinde asla ortaya çıkmaz.
Duman testi (Smoke testi), hafif bir ön kontroldür: uzun, maliyetli bir çalışmaya başlamadan önce API ve test kurulumunun çalıştığını doğrulamak için küçük bir yüktür.
Çoğu ekip, en azından yük, stres ve dayanıklılık testlerine ihtiyaç duyar. Trafiğiniz anlık artışlar gösteriyorsa ani yük testi önemlidir.
Önemli metrikler
Bir performans testi sayılar üretir. Bunlar okunması gerekenlerdir.
Yanıt süresi, API'nin bir isteği alması, işlemesi ve döndürmesi için geçen süredir. Sadece ortalamaya değil, yüzdelik dilimlere de bakın. Ortalama sağlıklı görünebilirken, 95. ve 99. yüzdelik dilimler, yani en yavaş %5 ve %1'lik istekler kabul edilemez olabilir. Gerçek kullanıcılar kuyruğu hisseder.
Verim (Throughput), API'nin saniyede tamamladığı istek sayısıdır. Sistemin gerçek kapasitesini, kaç kullanıcının bağlı olduğundan bağımsız olarak gösterir.
Eş zamanlı kullanıcılar veya sanal kullanıcılar, testin simüle ettiği eş zamanlı çağrı yapan kişi sayısıdır. Kapasite genellikle, yanıt süreleri bütçenizi aşmadan önce API'nin sürdürebileceği maksimum eş zamanlılık olarak ifade edilir.
Hata oranı, yük altında başarısız olan isteklerin yüzdesidir. Hızlı kalan ancak yüksek eş zamanlılıkta 500'lü yanıtlar döndürmeye başlayan bir API, testi yine de geçememiştir.
Kaynak kullanımı, sunucudaki CPU ve bellek, performansın neden düştüğünü söyler. Yanıt süreleri tırmanırken CPU %100'de ise, işlem gücü sınırlıdır; CPU boşta ancak gecikme artıyorsa, darboğaz başka bir yerdedir, genellikle bir veritabanı veya aşağı akış çağrısıdır.
İyi bir performans raporu bunları bir araya getirir: bu eş zamanlılıkta verim zirveye ulaştı, 95. yüzdelik dilim yanıt süresi buydu ve hata oranı da şuydu.
Apidog'da bir API performans testi nasıl çalıştırılır
Apidog, API'lerinizi tasarladığınız ve işlevsel olarak test ettiğiniz aynı çalışma alanına entegre edilmiş yük testi içerir, bu nedenle başlamak için ayrı bir araca ihtiyacınız yoktur.
Adım 1: Test edilecek uç noktayı veya senaryoyu seçin. Tek bir kritik uç nokta veya giriş ve ardından veri alma gibi gerçek bir kullanıcı akışını yansıtan çok adımlı bir test senaryosu seçin. Gerçekçi bir akışı test etmek, tek bir uç noktayı izole olarak zorlamaktan daha dürüst sayılar verir.
Adım 2: Önce işlevsel olarak geçtiğini doğrulayın. İsteği onaylamalarıyla bir kez çalıştırın. Yanlış veri döndüren bir uç noktanın yük testini yapmanın bir değeri yoktur; hızı ölçmeden önce doğruluğu düzeltin.
Adım 3: Yükü yapılandırın. Sanal kullanıcı sayısını ve test süresini ayarlayın. Apidog, kullanıcıların aniden değil, zamanla katıldığını simüle ederek yükü kademeli olarak artırmanıza olanak tanır, bu da daha gerçekçi bir tablo oluşturur ve performansın değiştiği eş zamanlılık seviyesini belirlemeye yardımcı olur.
Adım 4: Testi çalıştırın. Apidog yükü yürütür ve canlı olarak raporlar: yanıt süreleri, verim, hata oranı ve her bir metriğin eş zamanlılık arttıkça nasıl değiştiği. Yanıt süresinin yükten daha hızlı tırmanmaya başladığı bükülme noktasını izleyin.
Adım 5: Sonuçları okuyun ve darboğazı bulun. Eğer 95. yüzdelik dilim yanıt süresi 300 eş zamanlı kullanıcıda bütçenizi aşıyorsa, bu sizin mevcut tavanınızdır. Nedeni anlamak için sunucu CPU ve belleğiyle karşılaştırın. Bir düzeltmeden sonra tavanın değiştiğini doğrulamak için tekrar çalıştırın.
Adım 6: Daha ağır ihtiyaçlar için JMeter'a aktarın. Tek bir makinenin ötesinde dağıtılmış yük üretimine ihtiyacınız olduğunda, Apidog senaryoyu JMeter'a aktarabilir, böylece yük kaynağını ölçeklendirirken aynı test tanımını korursunuz.
Mevcut bir uç noktanıza karşı ilk yük testinizi çalıştırmak için Apidog'u indirin.
Gerçek bir performans sonucunu okumak
Yorumlanmayan sayılar gürültüdür. Somut bir çalışmayı ele alalım: GET /products uç noktasını beş dakika içinde 0'dan 500'e yükselen sanal kullanıcılarla yük testi yapıyorsunuz.
İlk 200 kullanıcı için, 95. yüzdelik dilim yanıt süresi 180 ms civarında sabit kalır ve verim yükle birlikte artar. Bu sağlıklı bölgedir; API yetişmektedir. Yaklaşık 280 kullanıcıda, 95. yüzdelik dilim süresi yükselmeye başlar, 240 ms, sonra 400 ms, sonra 900 ms, bu sırada verim yükselmek yerine düzleşir. Bu düzleşme sinyaldir: API tavanına ulaşmıştır. Artık daha fazla kullanıcı eklemek, daha fazla tamamlanmış iş değil, daha yavaş yanıtlar üretir. 420 kullanıcının ötesinde, istekler zaman aşımına uğramaya başladıkça hata oranı %1'in üzerine çıkar.
Karar somuttur. Bu API, 200 ms'lik bir bütçe dahilinde yaklaşık 250 eş zamanlı kullanıcıya rahatça hizmet verir. Pratik tavanı 280 civarındadır ve 420 civarında başarısız olmaya başlar. Eğer 200 eş zamanlı kullanıcıdan oluşan yoğun bir trafik bekliyorsanız, bir boşluğunuz var demektir. Eğer 350 bekliyorsanız, lansmandan sonra değil, öncesinde düzeltmeniz gereken bir sorununuz var demektir.
Bir performans testinin sunduğu budur: "geçti" veya "kaldı" değil, API'nin nerede rahat olduğu, nerede zorlandığı ve nerede çöktüğüne dair net bir harita.
Yaygın API performans darboğazları
Bir test bir tavanı ortaya çıkardığında, neden genellikle birkaç tanıdık suçludan biridir.
Yavaş veritabanı sorguları en yaygın olanıdır. Dizinlenmemiş bir sütun, bir N+1 sorgu deseni veya eksik bir sorgu limiti, veri hacmi veya eş zamanlılık arttığı anda hızlı bir uç noktayı yavaşlatır. Sunucu CPU'su düşük kalırken gecikme tırmanıyorsa, önce veritabanından şüphelenin.
Harici çağrıları engellemek, bir uç noktayı en yavaş bağımlılığının hızına düşürür. Bir ödeme sağlayıcısını veya üçüncü taraf bir hizmeti eşzamanlı olarak çağıran bir API, o hizmetin gecikmesini ve kesintilerini miras alır.
Bağlantı havuzu tükenmesi, sürekli yük altında ortaya çıkar: API'nin veritabanı bağlantıları veya HTTP istemcileri tükenir ve istekler beklemeye başlar. Bu, klasik bir dayanıklılık testi bulgusudur.
Büyük yanıt yüklerinin verimsiz serileştirilmesi CPU'yu yakar. Müşterinin ihtiyaç duyduğundan daha fazla veri döndürmek, her yanıtı oluşturmayı ve aktarmayı yavaşlatır.
Bir performans testi, tavanın nerede olduğunu gösterir; bunu sunucu tarafı metriklerle eşleştirmek, size neden olduğunu söyler.
Performans testini sürecinize dahil etmek
Büyük bir lansmandan önce bir kez yapılan performans testi faydalıdır. Düzenli olarak çalışan bir performans testi çok daha değerlidir, çünkü performans sessizce geriler. Yeni bir veritabanı sorgusu, eklenen bir aşağı akış çağrısı veya dizinlenmemiş bir sütun, hiçbir işlevsel testin fark etmediği bir gecikme ekleyebilir.
Kritik uç noktalarınız için bir yanıt süresi ve hata oranı bütçesi belirleyin ve bir ihlali, bozuk bir onayı ele aldığınız gibi bir hata olarak kabul edin. CI/CD'nin bir parçası olarak daha hafif bir yük testi çalıştırın, böylece bir regresyon çekme isteğinde ortaya çıksın ve ağır stres ve dayanıklılık çalışmalarını planlanmış sürüm öncesi testler için ayırın.
Performans testlerini işlevsel testlerin yanında tutun. İkisi bir arada yaşadığında, her API değişikliği hem doğruluk hem de hız açısından kontrol edilir ve "çalışıyor" ve "yeterince hızlı çalışıyor" ayrı, kolayca unutulan sorular olmaktan çıkar.
Sıkça sorulan sorular
Yük testi ve stres testi arasındaki fark nedir? Yük testi, beklediğiniz trafiği uygular ve API'nin bunu karşıladığını doğrular. Stres testi, kırılma noktasını bulmak için bunun ötesine geçer. Yük testi normal çalışmayı doğrular; stres testi arıza modunu haritalar.
Ortalama mı yoksa yüzdelik yanıt sürelerine mi bakmalıyım? Yüzdelik dilimlere. Ortalama, yavaş kuyruğu gizler. 95. ve 99. yüzdelik dilimler, en şanssız kullanıcılarınızın gerçekte ne deneyimlediğini gösterir ve şikayetlere neden olan budur.
Arka uç bitmeden bir API'nin performans testini yapabilir miyim? Sözleşmeyi ve tasarımı test edebilirsiniz, ancak anlamlı gecikme sayıları gerçek altyapıya ihtiyaç duyar. Erken işlevsel çalışmalar için bir sahte sunucu kullanın ve gerçek uygulamaya karşı yük testleri çalıştırın.
Performans testleri ne sıklıkla çalıştırılmalıdır? Kritik uç noktalardaki her değişiklik için CI'da hafif bir yük testi ve her büyük sürümden önce tam stres ve dayanıklılık testleri çalıştırın. Performans sessizce gerilediği için düzenli kontroller, lansman öncesi tek büyük bir çalışmadan daha iyidir.