80 kişi aynı anda ödeme yaptığında API'nize ne olduğunu bilmek istersiniz. Bu yüzden Locust'u açarsınız ve size yapmanızı istediği ilk şey bir Python sınıfı yazmaktır. Bir HttpUser tanımlayın. Metotları @task ile süsleyin. Bir locustfile.py oluşturun, bir sanal ortam kurun, birkaç bağımlılık belirleyin ve ardından yetkilendirme jetonunuzun istekler arasında neden yeniden kullanılmadığını anlamaya çalışın. Bunların hiçbiri testin kendisi değildir. Bunlar test başlamadan önceki giriş ücretidir.
Locust iyi bir araçtır ve kod öncelikli tasarımının amacı budur. Ancak hedefiniz “giriş noktam 100 eşzamanlı kullanıcıya dayanıyor mu?” sorusuna net bir yanıt almaksa, bir Python koşum takımı yazmak ve sürdürmek tek bir sayı için çok fazla angaryadır. Çekiçlemek istediğiniz API istekleri zaten bir API istemcisinde mevcut olduğunda daha hızlı bir yol vardır. Apidog ile mevcut bir test senaryosuna bir performans testi yönlendirir, sanal kullanıcı sayısını ve süreyi ayarlarsınız ve canlı bir grafikten iş hacmini, yanıt süresini ve hata oranını okursunuz. Ne locustfile ne pip install ne de Python hiçbiri yok.
Locust'un Gerçekten İyi Yaptığı Şeyler
Locust, Python ile yazılmış açık kaynaklı bir yük testi aracıdır ve tasarlandığı işte iyidir. Kullanıcı davranışını kod olarak tanımlarsınız. Sanal bir kullanıcı bir Python sınıfıdır ve bu kullanıcının yaptığı şeyler görev olarak etiketlediğiniz metotlardır. İşte bir locustfile.py dosyasının standart yapısı:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
locust -f locustfile.py ile çalıştırır, localhost:8089 adresindeki web arayüzünü açar, kullanıcı sayısını ve doğma hızını ayarlarsınız ve sayıların yükselişini izlersiniz. Davranış kod olduğu için gerçek bir ifade gücü elde edersiniz. Koşullu mantık, ağırlıklı görev dağılımları, sıralı kullanıcı yolculukları, HTTP dışındaki protokoller için özel istemciler, istekler arasında paylaşılan durum. Yukarıdaki @task(3)'e karşı @task(1) ağırlıklandırması, göz atmanın sepete eklemekten üç kat daha sık gerçekleştiği anlamına gelir ki bu, düz bir istek listesinin yakalayamayacağı türden bir gerçekçiliktir.
Locust yatay olarak da ölçeklenebilir. Birden fazla çalışan süreç veya makine arasında dağıtılmış olarak çalıştırın ve tek bir ana bilgisayar onları koordine eder, böylece tek bir kutunun üretebileceğinin ötesine geçebilirsiniz. Temel olarak olay tabanlıdır, bu nedenle her çalışan, kullanıcı başına bir iş parçacığının bellek tüketimi olmadan binlerce eşzamanlı kullanıcıyı barındırır. Zaten Python kullanan, yük testlerini sürüm kontrollü kod olarak ele alan ve karmaşık çok adımlı kullanıcı davranışlarını modellemesi gereken bir ekip için Locust güçlü bir seçimdir. Bunların hiçbiri tartışmalı değildir.
Maliyet koddur. Her test, yazdığınız, hatalarını ayıkladığınız ve bakımını yaptığınız bir programdır. API'niz değişirse, locustfile de değişir. Yeni bir mühendis testi çalıştırmak isterse, uyumlu bir Python ortamına ihtiyacı olur. Ve zaten Python yazmıyorsanız, dilin kendisi Python ile hiçbir ilgisi olmayan bir soruyu yanıtlamak için bir ön koşul haline gelir.
Kod Öncelikli Modelin Sorun Yarattığı Yerler
Sorun üç yerde ortaya çıkar.
Birincisi, kurulum. Herhangi bir şeyi ölçmeden önce Python'u kurar, bir sanal ortam oluşturur, pip install locust komutunu çalıştırır ve koşum takımını yazarsınız. Hızlı bir “bu uç nokta 50 kullanıcıyı kaldırabilir mi” kontrolü için, bu, yükten çok tesisat işidir.
İkincisi, tekrarlama. Muhtemelen bu istekleri zaten bir yerde tanımlamışsınızdır. Belki Postman'da, belki bir .http dosyasında, belki de ekibinizin her gün kullandığı bir API istemcisinde. locustfile, yetkilendirme akışı, başlıklar, istek gövdeleri dahil olmak üzere zaten mevcut olan istekleri yeniden tanımlar. Artık aynı API bilgisinin iki kopyasını sürdürüyorsunuz ve bunlar zamanla farklılaşıyor.
Üçüncüsü, cevaba ihtiyacı olan insanlar. Bir QA mühendisi, lansman için ter döken bir ürün yöneticisi veya pazarlama e-postasından sonra API'nin hayatta kalıp kalmayacağını bilmek isteyen bir ön uç geliştiricisi, hepsi yük testi sonucuna ihtiyaç duyar. Bunu hak etmek için ille de Python okumaları veya yazmaları gerekmez. Test bir locustfile arkasına kilitlendiğinde, cevap bir beceri setinin arkasına kilitlenir.
Yük testleriniz gerçekten dallanma mantığına ve özel protokol istemcilerine ihtiyaç duyuyorsa, bu sürtünmeyi ödemeye değerdir ve Locust doğru araçtır. Ancak “gerçek API isteklerimi eşzamanlı yük altında çalıştır ve bana sayıları göster” gibi yaygın bir durum için, Python katmanının size bir şey kazandırıp kazandırmadığını sormaya değer.
Apidog Yaklaşımı: Zaten Sahip Olduğunuz İstekleri Yük Testi Yapın
Apidog, yük testine diğer yönden yaklaşır. İstekleri tanımlayan bir betik yazmazsınız. Zaten oluşturduğunuz istekleri alıp yük altında çalıştırırsınız. Bir yük testinin birimi, ortamları, değişkenleri ve onaylamaları zaten eklenmiş sıralı bir API istekleri kümesi olan bir test senaryosudur. Apidog'u bir uç noktayı test etmek veya hata ayıklamak için kullandıysanız, istek zaten oradadır. Performans testi onu yeniden kullanır.
İşte tam akış.
- Yük testi yapmak istediğiniz test senaryosunu açın. Bu, aynı istekler ve aynı ortam değişkenleriyle normal bir fonksiyonel test olarak çalıştıracağınız senaryonun aynısıdır.
- Tek geçiş yerine bir performans testi olarak çalıştırmayı seçin.
- Sanal kullanıcı sayısını ayarlayın. Apidog, her biri senaryodaki her isteği test boyunca paralel olarak döngüye alan 100 adede kadar sanal kullanıcıyı destekler.
- Test süresini ayarlayın. Bu, sanal kullanıcıların ne kadar süre döngüde kalacağıdır.
- Kademeli bir artış istiyorsanız bir ramp-up süresi ayarlayın. Apidog, ilk X dakika boyunca kullanıcıları birden değil, kademeli olarak çevrimiçi hale getirir; bunu 0 olarak ayarlarsanız her sanal kullanıcı hemen başlar.
- Senaryonuz veri odaklıysa, bir eşleştirme modu seçin. “Rastgele Eşleşme”, her sanal kullanıcının her döngüde test verilerinizden rastgele bir satır çekmesini sağlar; “Sıralı Eşleşme” satırları sırayla yürütür.
- Testi başlatın ve canlı paneli izleyin.
Grafik gerçek zamanlı olarak güncellenir. Senaryodaki her API için Toplam İstekler, Ortalama İş Hacmi, Ortalama Yanıt Süresi, Maksimum ve Minimum Yanıt Süresi ve Hatalar elde edersiniz. Belirli bir zaman dilimi için sayıları görmek üzere grafiğin üzerine gelin. Bir “Hata” sekmesi başarısız istekleri ayrıntılandırır, böylece hangi uç noktanın ne zaman çökmeye başladığını görebilirsiniz. Çalışma bittiğinde, “Test Raporları” sekmesi geçmişi tutar, böylece bir değişiklik gönderdikten sonra bugünkü çalıştırmayı geçen haftakiyle karşılaştırabilirsiniz.
Tüm mesele, yazacak bir locustfile ve yönetilecek bir Python ortamının olmamasıdır. Fonksiyonel testinizi geçen istek, yükü oluşturan istektir. Bu, bir yük testini tanımlamak ile bir yük testini çalıştırmak arasındaki farktır. Apidog hepsi bir arada bir API platformudur, bu nedenle bir uç noktanın tasarımı, hata ayıklaması, fonksiyonel testi ve yük testi, o uç noktanın tek bir tanımına göre yapılır.
Somut Bir Karşılaştırma
Diyelim ki bir giriş uç noktasının 100 eşzamanlı kullanıcıyı iki dakika boyunca, 30 saniyelik bir ramp-up ile kaldırıp kaldırmadığını doğrulamak istiyorsunuz.
Locust'ta, kimlik bilgilerini gönderen bir göreve sahip bir kullanıcı sınıfı yazarsınız, yanıtın döndürdüğü jetonu işlersiniz, sonraki tüm çağrılar için saklarsınız, dosyayı kaydedersiniz, locust -f login_test.py komutunu başlatırsınız, web kullanıcı arayüzünü açarsınız ve 100 kullanıcı, bir doğma hızı ve bir çalışma süresi girersiniz. Jeton işleme yanlışsa, API'nizin hatalarını ayıklamadan önce Python'ın hatalarını ayıklarsınız.
Apidog'da, zaten oluşturduğunuz giriş test senaryosunu açar, bir performans testine çevirir, sanal kullanıcılar için 100, süre için 2 dakika, ramp-up için 30 saniye yazarsınız ve başlatırsınız. Fonksiyonel testinizde zaten çalışan kimlik doğrulama hala çalışır, çünkü aynı senaryodur. Yanıt süresi eğrisini ve hata oranını meydana geldikçe okursunuz.
Her ikisi de aynı türden bir cevaba ulaşır. Biri sizden önce bir program yazmanızı ve sürdürmenizi ister. Diğeri ise zaten sahip olduklarınızı yeniden kullanır. Karmaşık, kod tabanlı kullanıcı yolculukları için program buna değerdir. “Uç noktam yük altında hızlı ve kararlı mı?” sorusu için ise yeniden kullanım zaman açısından avantaj sağlar.
Her İki Tarafın Dürüst Sınırları
Takaslar konusunda açık fikirli olun, çünkü yanlış aracı seçmek her iki durumda da bir günü boşa harcar.
Apidog'un performans testi, tek bir çalıştırmadan en fazla 100 sanal kullanıcıya kadar çıkar ve yük, uygulamayı çalıştıran makinenizden üretilir. On binlerce kullanıcıyı simüle etmeniz veya aynı anda birden fazla coğrafi bölgeden yük oluşturmanız gerekiyorsa, bu, uygulama içi performans testinin hedeflerinin ötesindedir ve Locust çalışanları veya özel bir yük oluşturma kümesi gibi dağıtılmış bir kurulum doğru seçimdir. Apidog ayrıca, her başarısızlık için tam istek ve yanıt gövdesini yakalamak yerine, başarısız istekleri istatistiksel olarak kaydeder, bu nedenle yük ortasında belirli bir başarısız çağrının derinlemesine adli hata ayıklaması onun gücü değildir.
Locust'un takası, tüm bu makalenin konusu olan şeydir. Güç koddan gelir ve kod sürekli bir maliyettir. Senaryo başına bir locustfile sürdürür, bir Python ortamını hazır tutar ve testi çalıştırmak isteyen herkesin onu anlamak için Python okuması gerektiğini kabul edersiniz. Çok yüksek sanal kullanıcı sayıları ve özel protokol mantığı için bu maliyet size gerçek bir şey kazandırır. Günlük API yük kontrolü için ise bu bir yüktür.
Makul bir kural: testi “bu istekleri bu eşzamanlılıkta bu süre boyunca çalıştır” olarak tanımlayabiliyorsanız, uygulama içi performans testine yönelin. Koşullu dallanmaya, ağırlıklı görev grafiklerine, özel istemcilere veya altı haneli kullanıcı sayılarına ihtiyacınız varsa, koda yönelin. Her bir seçeneğin nereye oturduğuna dair daha geniş bir inceleme için, en iyi yük testi araçları ve API'ye özgü yük testi araçları karşılaştırması hakkındaki özetimize bakın.
Geri Aldığınız Sayıları Okuma
Bir yük testi, ancak çıktının ne anlama geldiğini biliyorsanız faydalıdır. Dört metrik ağırlığın çoğunu taşır.
İş Hacmi (RPS/TPS), API'nizin gerçekte sunduğu istek veya işlem sayısıdır. Sisteminizin kaldırabileceği tavan noktasıdır. Sanal kullanıcı eklemeye devam ederken iş hacmi düzleşiyorsa, bir doygunluk noktası buldunuz demektir.
Yanıt süresi (gecikme), her isteğin ne kadar sürdüğüdür. Ortalamayı izleyin, ancak maksimuma daha dikkatli bakın. Çirkin bir maksimum ile sağlıklı bir ortalama, çoğu kullanıcı iyi olsa bile bazı kullanıcıların kötü zaman geçirdiği anlamına gelir. Kuyruk gecikmesi, gerçek kullanıcıların acı çektiği yerdir.
Hata oranı, başarısız olan isteklerin oranıdır. Düşük yükte temiz bir testin, sanal kullanıcılar arttıkça 500'ler veya zaman aşımları vermeye başlaması, sistemin nerede bozulduğunu tam olarak gösterir. Hataların başladığı nokta genellikle ham iş hacmi sayısından daha ilgi çekicidir.
Eşzamanlılık, kaç sanal kullanıcının aktif olduğudur. Apidog'da bu, ayarladığınız sanal kullanıcı sayısıdır ve ramp-up, oraya ne kadar hızlı ulaşacağınızı kontrol eder. Ramp-up önemlidir, çünkü kademeli olarak ulaşılan 100 kullanıcıyı kaldırabilen bir sistem, 100 kullanıcının hepsi aynı saniyede gelirse yine de çökebilir.
Bunun daha derin versiyonunu isterseniz, API performans testi kılavuzumuz metrikleri, test türlerini ve eğrilerin nasıl okunacağını açıklar ve performans testi temelleri yazısı daha geniş disiplini kapsar.
Bunun Zaten Karşılaştırdığınız Araçlara Nasıl Uyduğu
JMeter kullandıysanız, her ikisi de bir yük testini kod yerine bir kullanıcı arayüzü aracılığıyla yapılandırmanıza izin verdiği için zihinsel model Apidog'unkine benzer. JMeter bunu daha ağır XML tabanlı bir test planı ve daha dik bir öğrenme eğrisi ile takas eder; JMeter yük testi eğitimimiz bunu ayrıntılı olarak ele alır. Yükü Postman'ın koleksiyon çalıştırıcısı aracılığıyla çalıştırdıysanız, Postman ile yük testi yazımızda ele alınan aynı fikrin daha hafif bir versiyonunu görmüşsünüzdür ve Apidog, Postman olmadan API testi için de kullanabileceğiniz isteklerin üzerine özel performans raporlaması ekler. Apidog, insanların istediği kodsuz basitlik ile ayrı bir koşum takımını sürdürmekten sizi alıkoyan istek yeniden kullanımının ortasında yer alır.
Bunların hepsindeki ortak nokta, yük testinizin halihazırda kodladığınız API bilgisini yeniden kullanması, yeni bir dilde kopyalamaması gerektiğidir. Locust bunu Python'da kopyalar çünkü Python onun gücüdür. Apidog senaryolarınızı yeniden kullanır çünkü yeniden kullanım onun gücüdür.
Başlarken
İstekleriniz zaten Apidog'da yaşıyorsa, önümüzdeki beş dakika içinde bir performans testi çalıştırabilirsiniz. Bir test senaryosunu açın, performans testine geçin, sanal kullanıcıları ve süreyi ayarlayın ve başlatın. Bir locustfile dosyasından geliyorsanız ve Python katmanını sürdürmekten yorulduysanız, senaryoyu uygulamada bir kez yeniden oluşturun ve o uç nokta için bir daha yük testi kodu yazmazsınız.
Apidog'u indirin ve zaten test ettiğiniz bir uç noktaya bir performans testi yönlendirin. Eşdeğer locustfile dosyasını yazmayı bitirmeden önce iş hacmi, gecikme ve hata oranı eğrilerine sahip olacaksınız. Locust, büyük ölçekte dağıtılmış, kod modelli yük için doğru cevap olmaya devam ediyor. Çoğu geliştiricinin aslında sorduğu soru için, zaten sahip olduğunuz istekleri çalıştırın.
Sıkça Sorulan Sorular
Apidog, Locust'un doğrudan bir alternatifi midir?
Her iş için değil. Kod yazmadan 100 sanal kullanıcıya kadar API isteklerini yük testi yapmak için Apidog, mevcut test senaryolarınızı doğrudan çalıştırdığı için tüm Locust iş akışının yerini alır. Çok yüksek kullanıcı sayılarıyla dağıtılmış yük veya kodda modellenen özel HTTP dışı protokoller için Locust hala daha uygundur.
Apidog'da yük testi yapmak için herhangi bir kod yazmam gerekiyor mu?
Hayır. Sanal kullanıcıları, test süresini ve ramp-up süresini kullanıcı arayüzünde yapılandırırsınız ve test, zaten oluşturduğunuz bir test senaryosundaki istekleri çalıştırır. Kurulacak bir locustfile veya Python ortamı yoktur.
Apidog kaç sanal kullanıcıyı simüle edebilir?
Tek bir performans testinde 100 sanal kullanıcıya kadar. Her biri, ayarladığınız süre boyunca senaryodaki her API'yi paralel olarak döngüye alır. Bundan çok daha fazlasına veya birden fazla bölgeden yüke ihtiyacınız varsa, Locust gibi dağıtılmış kod tabanlı bir araç doğru seçimdir.
Apidog performans testi hangi metrikleri raporlar?
Senaryodaki her API için Toplam İstekler, Ortalama İş Hacmi, Ortalama Yanıt Süresi, Maksimum ve Minimum Yanıt Süresi ve Hatalar elde edersiniz ve bunlar bir grafikte canlı olarak güncellenir. Bir Hata sekmesi başarısız istekleri ayrıntılandırır ve Test Raporları sekmesi çalıştırma geçmişini tutar, böylece değişiklikler arasında karşılaştırma yapabilirsiniz.
Veri odaklı isteklerle yük testi yapabilir miyim?
Evet. Senaryonuz test verileriyle destekleniyorsa, her sanal kullanıcının her döngüde rastgele bir satır çekmesini sağlamak için “Rastgele Eşleşme”yi veya satırları sırayla ilerletmek için “Sıralı Eşleşme”yi seçin.
Locust'u hala herhangi bir şey için kullanmalı mıyım?
Evet, güçlü yönleri ihtiyacınıza uyduğunda: dallanma ve ağırlıklı görevlerle kod tanımlı kullanıcı davranışı, özel protokol istemcileri ve 100'den fazla sanal kullanıcıyı zorlayan dağıtılmış yük üretimi. Testin şekline göre doğru aracı kullanın.