Web Uygulamasında Stres Testi Yapmak Mı?

Geçmişte, test web uygulamalarını vurgulamak için Microsoft Web Uygulaması Stres Aracı ve Pylot'u kullandım. Basit bir giriş sayfası, giriş betiği ve site açıklamasını yazmıştım (bir e-ticaret sitesinde bir sepete ve kasaya birkaç öğe ekleyerek).

Sadece bir avuç geliştirici ile ana sayfaya sert vurmak neredeyse her zaman büyük bir sorun bulacaktır. Daha fazla ölçeklenebilirlik sorunu ikinci aşamada ve daha da fazlası - lansmandan sonra ortaya çıkacaktır.

Kullandığım araçların URL'si Microsoft Homer ( Microsoft Web Uygulaması Stres Aracı olarak da bilinir ) ve Pylot idi .

Bu araçlar tarafından oluşturulan raporlar bana hiç mantıklı gelmedi ve sitenin ne tür eşzamanlı yükü destekleyebileceğini anlamaya çalışmak için saatler harcadım. Her zaman buna değdi çünkü en aptal böcekler ve darboğazlar her zaman ortaya çıkacaktı (örneğin, web sunucusu yanlış yapılandırmaları).

Ne yaptınız, hangi araçları kullandınız ve yaklaşımınızda ne gibi başarılar elde ettiniz? Benim için en ilginç kısım, bir uygulamanın stres testi uygulaması tarafından bildirilen sayılardan destekleyebileceği eşzamanlı kullanıcı sayısını hesaplamak için bir tür anlamlı formül bulması.

JMeter için bir oy daha .

JMeter, Java ile yazılmış açık kaynaklı bir yük test aracıdır. Bir dizi farklı sunucu türünü test edebilir (örneğin, web, web hizmetleri, veritabanı, temel olarak istekleri kullanan hemen hemen her şey).

Bununla birlikte, karmaşık testlere başladıktan sonra dik bir öğrenme eğrisi vardır, ancak buna değer. Çok hızlı bir şekilde çalışmaya başlayabilirsiniz ve ne tür bir stres testi yapmak istediğinize bağlı olarak, bu iyi olabilir.

Artıları:

• Apache projesinden Açık Kaynak / Ücretsiz araç (katılımda yardımcı olur)
• Başlamak kolay ve temel kavramları kavradığınızda kullanımı kolay. (Yani, bir talep nasıl oluşturulur, bir iddia nasıl oluşturulur, değişkenlerle nasıl çalışır vb.).
• Çok ölçeklenebilir. Neredeyse bir milyon vuruş / saat ayarlamak için sunucuda yük üreten 11 makine ile testler yaptım. O was çok ben bekliyordum daha kurulumu daha kolay.
• Aktif bir topluluğa ve kalkmanıza yardımcı olacak iyi kaynaklara sahiptir. Önce öğreticileri okuyun ve bir süre onunla oynayın.

Eksileri:

• UI Swing dilinde yazılmıştır. (Ugh!)
• JMeter, sunucu tarafından döndürülen yanıt metnini ayrıştırarak çalışır. Bu nedenle, herhangi bir javascript davranışını doğrulamak istiyorsanız, şansınız kalmaz.
• Öğrenme eğrisi programcı olmayanlar için diktir. Düzenli ifadelere aşina iseniz, zaten oyunun ilerisindesiniz.
• Destek forumunda, belgelere bir cüretsel bakış bile verseler bile kolayca çözülebilecek aptalca sorular soran çok sayıda ( tamamlayıcı ekle ) aptal var. ('Windows GUI'mi stres testi için JMeter'i nasıl kullanırım' oldukça sık görülür).
• 'Kutudan çıktığı hali' bildirmek, özellikle daha büyük testler için arzulanan çok şey bırakıyor. Yukarıda bahsettiğim testte, bazı 'xml-logfile' den 'html' dönüşümlerine kadar hızlı bir konsol uygulaması yazmak zorunda kaldım. Bu birkaç yıl önceydi, bu yüzden artık gerekli olmayacaktı.

Öğütücü kullandım . Açık kaynak kodlu, kullanımı oldukça kolay ve çok yapılandırılabilir. Java tabanlıdır ve komut dosyaları için Jython kullanır. Bir .NET web uygulamasına karşı çalıştırdık, bu yüzden sadece bir Java aracı olduğunu düşünmeyin (doğası gereği, herhangi bir web stres aracı kullandığı platforma bağlı olmamalıdır).

Onunla bazı düzgün şeyler yaptık ... web tabanlı bir telekom uygulamasıydık, bu yüzden kurduğum bir harika kullanım, web uygulamamızdan bir numara çevirmeyi taklit etmekti, sonra sahip olduğumuz bir otomatik cevaplama aracını kullandık (temelde bir öğretici idi) Microsoft Office Communicator'ın yerel bir ağda bağlandığı şey olan RTC LCS sunucularına bağlanmak için ... Bu, daha sonra Hammer (veya bunun gibi) adlı pahalı bir telefon aracı yerine bunu kullanmamızı sağladı.

Her neyse, aracı uygulamamızın yüksek yük altında nasıl tutulduğunu görmek için kullandık ve darboğazları bulmakta çok etkili oldu. Araç, taleplerin ne kadar sürdüğünü göstermek için raporlar oluşturdu, ancak hiç kullanmadık. Günlükler ayrıca tüm yanıtları ve ne olursa olsun ya da özel günlüğe kaydetmeyi de saklayabilir.

Bu araç, fiyat için çok yararlı tavsiye ederim ... ama onunla bazı özel kurulum yapmayı bekliyoruz (bir komut dosyası kaydetmek için yerleşik bir proxy var, ama oturumlar gibi bir şey yakalamak için özelleştirme gerekebilir ... biliyorum Ben iş parçacığı başına benzersiz bir oturum kullanmak için özelleştirmek zorunda kaldı).

Bu partiye biraz geç. Pylot'un gelecek en iyi açık kaynak aracı olduğu konusunda hemfikirim . Kullanımı basittir ve harika bir adam ( Corey Goldberg ) tarafından aktif olarak çalışılmaktadır . OpenQA'nın kurucusu olarak Pylot'un şimdi ana sayfamızda listelendiğinden ve altyapımızın (forumlar gibi) bazılarını kullandığı için mutluyum.

Bununla birlikte, son zamanlarda yük testi kavramının tamamının kusurlu olduğuna karar verdim: HTTP trafiğini taklit etmek, oldukları gibi karmaşık uygulamalar ile popodaki bir acıdır. Bu yüzden BrowserMob ticari aracını yarattım. Bu bir var dış yük testi hizmeti kullanan Selenyum geri yükünü oynarken gerçek web tarayıcılarını kontrol etmek.

Yaklaşım , normal yük testi tekniklerinden bir ton daha fazla donanım gerektiriyor , ancak bulut bilişim kullanırken donanım aslında oldukça ucuz. Bunun güzel bir yan etkisi, kodlamanın normal yük testinden çok daha kolay olmasıdır. Çerezleri, .NET oturum durumunu, Ajax istek parametrelerini vb. Ayıklamak için gelişmiş regex eşleştirmesi (JMeter gerektirdiği gibi) yapmak zorunda değilsiniz. Gerçek tarayıcılar kullandığınızdan, yapmaları gerekeni yaparlar.

Açıkça ticari bir ürün sunduğum için üzgünüm, ancak umarım konsept bazı insanlar için ilginçtir ve en azından bir sürü ekstra donanıma eriştiğinizde yük testi ile başa çıkmanın bazı yeni yollarını düşünmelerini sağlar!

JMeter kullandım . Web sunucusunu test etmenin yanı sıra veritabanı arka ucunuzu, mesajlaşma servislerini ve e-posta sunucularını da test edebilirsiniz.

ab , kuşatma , tsung , httperf , çiğnemek , Pylot, istek-log-analizörü , perftools

Basit kullanım için ab (apache benchmark) ve kuşatmayı perfer yapıyorum, ab çerezleri desteklemediğinden ve dinamik siteden sonsuz oturumlar oluşturacağından daha sonra bir tane gerekli.

her ikisini de başlatmak basit:

ab -c n -t 30 url

siege -b -c n -t 30s url

kuşatma daha fazla url ile çalışabilir.

son kuşatma sürümü rahatsız edici olan siegerc'de ayrıntılı olarak açın. yalnızca bu dosyayı düzenleyerek devre dışı bırakabilirsiniz ( /usr/local/etc/siegerc).

Web tabanlı bir hizmet için loader.io adresine bakın .

Özet:

loader.io, binlerce eşzamanlı bağlantıyla web uygulamalarınızı / apislerinizi test etmenizi sağlayan ücretsiz bir yük test hizmetidir.

Ayrıca bir API var .

Bu soru hala açık olduğundan, tartım da yapabilirim.

İyi haber şu ki, geçtiğimiz 5 yıl boyunca Açık Kaynak araçları gerçekten olgunlaştı ve uzayda kalktı, kötü haber orada çok fazla var.

İşte düşüncelerim: -

Jmeter vs Öğütücü

Jmeter, bir GUI aracılığıyla oluşturulan bir XML stil belirtiminden tahrik edilir.

Grinder Jython komut dizisini muti iş parçacıklı bir Java çerçevesi içinde kullanır, böylece programcılara daha fazla yöneliktir.

Her iki araç da HTTP ve HTTPS'yi işleyecek ve başlamanız için bir proxy kaydediciye sahip olacaktır. Her iki araç da birden fazla test aracısı çalıştırmak için Kontrolör modelini kullanır, bu nedenle ölçeklenebilirlik sorun değildir (Bulut'a erişim verilir).

Hangisi daha iyi:-

Url yeniden yazma, korelasyon, Sanal Kullanıcı başına benzersiz veri sağlama ve ilk kez simüle etme veya Kullanıcıları döndürme (HTTP Üstbilgilerini manipüle ederek) için daha karmaşık komut dosyası oluşturma gereksinimlerine girerken, öğrenme eğrisi olarak zor bir arama her iki araçla da diktir.

Bu araç büyük bir takip var ve bu aracı kullanmak için web üzerinde birçok örnek ve öğreticiler olduğu için Jmeter ile başlayacağım dedi. Eğer bir 'yol bloğuna' gelirseniz ve bu Jmeter ile 'kolayca' yapamayacağınız bir şeydir ve öğütücüye bir göz atın. İyi haber, hem bu araçların aynı Java gereksinimine sahip olması ve 'karıştır ve eşleştir' çözümü söz konusu değil.

Eklenecek yeni bir şey - Selenium WebDriver'ın birden çok örneğini çalıştıran başsız tarayıcılar.

Bu nispeten yeni bir yaklaşımdır, çünkü artık Bulut'tan sağlanabilecek kaynakların kullanılabilirliğine dayanmaktadır. Bu yaklaşımla, bir Selenium (WebDriver) komut dosyası, birden çok iş parçacığında başsız bir tarayıcı (yani WebDriver = Yeni HtmlUnitDriver ()) sürücüsü içinde alınır ve çalıştırılır.

Deneyimden, Amazon M1 Small Instance'dan yaklaşık 25 başsız tarayıcı örneği çalıştırılabilir.

Bunun anlamı, performans testi komut dosyaları haline gelmek için işlevsel test komut dosyalarınızı yeniden kullandıkça tüm korelasyon, URL yeniden yazma sorunlarının ortadan kalkmasıdır.

Öğütücü veya Jmeter gibi bir HTTP sürücüsü ile karşılaştırıldığında yükü sürmek için daha fazla VM'ye ihtiyaç duyulacağından ölçeklenebilirlik tehlikeye girer. Bununla birlikte, 500 Sanal Kullanıcıyı sürmek istiyorsanız, saatte sadece 1,20 $ maliyetle 20 Amazon Small Instances (saatte 6 sent) ile Gerçek Kullanıcı Deneyimi'ne çok yakın bir yük verir.

Ayrıca müthiş bir açık kaynak saf piton dağıtılan ve ölçeklenebilir olduğu keçiboynuzu kullandığı bu çerçeve greenlets . Çok sayıda eşzamanlı kullanıcıyı simüle etmek harika.

Kısa süre önce Gatling'i yük testi için kullanmaya başladık. Yük testi için bu aracı denemenizi şiddetle tavsiye ederim. Geçmişte SOASTA ve JMETER kullanmıştık. Gatling'i dikkate almamızın temel nedeni:

• Senaryoyu kaydetmek için kaydedici
• Jmeter Diş Açma modeline kıyasla daha iyi performans veren Akka ve Netty kullanma
• Jmeter XML ile karşılaştırıldığında çok daha sürdürülebilir olan DSL Scala
• Testleri yazmak kolaydır, scala ise korkmayın.
• Raporlama

Kodu Gatling Code kullanarak yazmak için basit bir örnek vereyim:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Ancak mümkün olduğunca karmaşık hale getirebilirsiniz. Gatling için öne çıkan özelliklerden biri, çok ayrıntılı olan raporlamadır.

İşte bazı bağlantılar:
Gatling
Gatling Tutorial

Son zamanlarda üzerinde konuştum, burada konuşmayı geçebilirsiniz:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Bu eski bir soru, ama bence daha yeni çözümler söylemeye değer. Checkout LoadImpact: http://www.loadimpact.com .

WebLoad'ı denedim , oldukça düzgün bir araç. Bir web sitesinde kullanıcı eylemini kaydetmenizi sağlayan IDE test komut dosyası ile birlikte gelir. Ayrıca web sunucunuzda stres testi yaparken bir grafik çizer. Deneyin, kesinlikle tavsiye ederim.

Burada bahsedilen tüm denemek, curl-loader benim için en iyi buldum. çok kolay arayüz, gerçek zamanlı izleme, kullanışlı istatistikler, hangi performans grafikleri oluşturmak. Libcurl'un tüm özellikleri dahildir.

Blaze sayacı, oturumları kaydetmek ve bunları JMeter'e aktarmak için bir krom uzantısına sahiptir (şu anda giriş gerektirir). Ayrıca JMeter sunucuları kümesinde çalıştırmak için onlara para ödeme seçeneğiniz de var (fiyatları sadece kullanmayı bıraktığım LoadImpact'ten çok daha iyi görünüyor):

• BlazeMeter Krom Uzantısı
• Bununla ilgili blog girişi

Onlarla herhangi bir ilişkim yok, henüz ücretli sürümünü kullanmama rağmen hizmetlerinin görünümünü seviyorum.

Bu soruyu neredeyse bir yıl önce sordunuz ve hala web sitenizi karşılaştırmanın başka bir yolunu aradığınızı bilmiyorum. Ancak bu soru hala çözülmüş olarak işaretlenmediğinden ücretsiz webservis LoadImpact (btw. Bağlı değil) önermek istiyorum . Sadece bu bağlantıyı twitter üzerinden aldım ve bu bulguyu paylaşmak istiyorum. Onlar makul iyi bir genel bakış oluşturmak ve birkaç dolar daha için "tam etki modu" olsun. Bu muhtemelen garip geliyor, ancak hizmetinizi itmek ve frenlemek iyi şanslar :)

IBM Page Detailer'ı da çalışmak için ilginç bir araç buldum .

OpenSTA kullandım .

Bu, bir web sitesi ile bir oturumun kaydedilmesini ve daha sonra nispeten basit bir kod dili ile oynatılmasını sağlar.

Web hizmetlerini kolayca test edebilir ve kendi komut dosyalarınızı yazabilirsiniz.

Komut dosyalarını istediğiniz şekilde bir testte bir araya getirmenize ve yineleme sayısını, her yinelemedeki kullanıcı sayısını, her yeni kullanıcıyı tanıtmak için rampa süresini ve her yineleme arasındaki gecikmeyi yapılandırmanıza olanak tanır. Testler gelecekte de planlanabilir.

Açık kaynak kodlu ve ücretsiz.

Bir e-tabloya kaydedilebilecek bir dizi rapor üretir. Daha sonra sonuçları kolayca analiz etmek ve grafiklendirmek için bir pivot tablo kullanıyoruz.

Belirtilen Microsoft aracını kullanıyoruz - Microsoft Web Uygulaması Stres Aracı. Kullandığım en kolay araçtır. Manuel olarak oluşturulan testlerde sadece 80 numaralı bağlantı noktasını vurabilmek de dahil olmak üzere birçok açıdan sınırlıdır. Ancak, kullanım kolaylığı aslında kullanıldığı anlamına gelir.

Bu araçtan gelen yükü OpenSTA ve bağlantı kontrol örümcekleri gibi diğer araçlarla destekliyoruz.

JMeter ilk değerlendirmemden iyi görünüyor, umarım bunu sürekli entegrasyonumuza dahil edeceğiz. Ancak, JMeter karmaşıktır ve uygulanması önemsizdir.

MS stres aracı sonuçlarını yorumlamakla ilgili başka bir soru açmanızı öneririm.

Visual Studio Test Edition 2010 (2008 iyi de). Bu web / yük testleri oluşturmak için gerçekten kolay ve güçlü bir araçtır.

Windows sunucularına karşı kullanıldığında bu aracın avantajı, raporunuzdaki tüm perfmon sunucu istatistiklerine entegre erişim sağlamanızdır. Gerçekten kullanışlı.

Diğer bonus, Visual Studio projesi ile web sitenizin kod yürütme profilini olacak bir "Performans Oturumu" entegre edebilirsiniz.

Web sayfalarını bir Windows sunucusundan sunuyorsanız, buradaki en iyi araçtır.

Ancak uygulamayı test etmek için birkaç makine kullanmak için ayrı ve pahalı bir lisans gerekir.

Yük ve performans ölçümünü birinci sınıf bir endişe olarak ele alan bir süreç geliştirdik - dediğiniz gibi, projenin sonuna bırakmak hayal kırıklığına yol açma eğilimindedir ...

Bu nedenle, geliştirme sırasında, kırık oturum yönetimi, bariz eşzamanlılık sorunları ve açık kaynak çekişme sorunları gibi temel deliliği kontrol eden çok temel çok kullanıcılı testleri (selenyum kullanarak) içerir. Önemsiz projeler bunu sürekli entegrasyon sürecine dahil eder, bu yüzden çok düzenli geri bildirim alırız.

Aşırı performans gereksinimleri olmayan projeler için, testlerimize temel performans testlerini dahil ediyoruz; genellikle, BadBoy'u kullanarak testleri senaryo haline getirir ve giriş bilgilerini ve iş parçacığına özgü diğer şeyleri değiştirerek JMeter'e aktarırız. Daha sonra bunları sunucunun saniyede 100 istekle uğraştığı düzeye yükseltiriz; tepki süresi 1 saniyeden azsa, bu genellikle yeterlidir. Hayatlarımızla fırlatıp ilerliyoruz.

Aşırı performans gereksinimleri olan projeler için hala BadBoy ve JMeter kullanıyoruz, ancak test donanımımızdaki (genellikle web ve veritabanı sunucuları) sunuculardaki darboğazları anlamak için çok fazla enerji harcıyoruz. Microsoft olay günlüklerini analiz etmek için bu konuda çok yardımcı olan iyi bir araç var . Genellikle, mümkünse optimize ettiğimiz beklenmedik darboğazlar buluruz; "1 web sunucusu, 1 veritabanı sunucusu" üzerinde olabildiğince hızlı bir uygulama sunuyor. Daha sonra genellikle hedef altyapımıza dağıtılır ve testleri ölçekte yeniden çalıştırmak için "buluttaki Jmeter" hizmetlerinden birini kullanırız.

Yine, PAL raporları testler sırasında neler olduğunu analiz etmeye yardımcı olur - genellikle üretim ortamlarında çok farklı darboğazlar görürsünüz.

Önemli olan sadece stres testlerinizi yapmakla kalmayıp, aynı zamanda uygulamanızın performansını anlamak için ihtiyacınız olan bilgileri de topladığınızdan emin olmaktır.

Burada bahsedilen birçok iyi araç var. Araçların bir cevap olup olmadığını merak ediyorum: "Bir web uygulamasını nasıl test edersiniz?" Araçlar gerçekten bir Web uygulamasını vurgulamak için bir yöntem sağlamaz. İşte bildiklerim:

Stres testi, artan bir kullanıcı popülasyonuna yanıt verirken bir Web uygulamasının nasıl başarısız olduğunu gösterir. Stres testi, Web uygulamasının başarısız olduğu sırada nasıl çalıştığını gösterir. Günümüzde çoğu Web uygulaması - özellikle Sosyal / Mobil Web uygulamaları - hizmetlerin entegrasyonlarıdır. Örneğin, Facebook Mayıs 2011'de kesinti yaptığında Pepsi.com'un Web uygulamasında oturum açamazsınız. Uygulama tamamen başarısız olmadı, normal işlevinin sadece büyük bir kısmı kullanıcılar tarafından kullanılamıyor.

Performans testi, bir Web uygulamasının, uygulamayı kaç kullanıcının aynı anda kullandığından bağımsız olarak yanıt sürelerini koruma yeteneğini gösterir. Örneğin, 10 eşzamanlı kullanıcıyla saniyede 10 işlem gerçekleştiren bir uygulama, 20 kullanıcıda saniyede 20 işlem gerçekleştirmelidir. Uygulama saniyede 20'den az işlem gerçekleştirirse yanıt süreleri uzar ve uygulama doğrusal ölçeklenebilirlik sağlayamaz.

Ayrıca, yukarıdaki örnekte, saniye başına işlem sayısı, yalnızca bir test kullanım durumu / iş akışının başarılı işlemlerinden olmalıdır. Arızalar genellikle daha kısa zaman aralıklarında olur ve TPS ölçümünü aşırı derecede iyimser hale getirir. Arızalar, uygulama üzerinde yük oluşturdukları için bir stres ve performans testi için önemlidir.

PushToTest metodolojisini http://www.pushtotest.com/pushtotest-testmaker-6-methodology adresindeki TestMaker Kullanıcı Kılavuzu'na yazdım . TestMaker iki çeşittir: Açık Kaynak (GPL) Topluluk sürümü ve TestMaker Enterprise (büyük profesyonel destekle ticari).

-Frank

LoadBooster'a bir göz atın ( https://www.loadbooster.com ). Web sitelerini test etmek için başsız komut dosyası tarayıcı PhantomJS / CasperJs kullanır. Phantomjs her sayfayı ayrıştırır ve oluşturur, istemci tarafı komut dosyasını yürütür. Başsız tarayıcı yaklaşımı, karmaşık AJAX ağır Web 2.0 uygulaması ， tarayıcıda gezinme, fare tıklaması ve tuş vuruşlarını tarayıcıya desteklemek veya DOM'da bir öğe bulunana kadar beklemek için test senaryoları yazmak daha kolaydır. LoadBooster selenyum HTML betiğini de destekler.

Feragatname: LoadBooster için çalışıyorum.

Kullanımı jMeter'den çok daha kolay olan ZebraTester'ı deneyin . Uzun süredir jMeter kullandım ancak bir yük testi için toplam kurulum süresi her zaman bir sorundu. ZebraTester açık kaynak olmasa da, son altı ayda kaydettiğim zaman bunu telafi ediyor. Ayrıca yük jeneratörlerini kullanarak testleri hızlı bir şekilde yapmak için kullanılabilecek bir SaaS portalı da var.

Bir not daha, web uygulamamız için, kilitler üzerindeki dişler arasındaki çekişme nedeniyle büyük performans sorunlarımız olduğunu gördüm ... bu yüzden ahlaki kilitleme şemasını çok dikkatli düşünmekti. Biz asenkron http işleyici kullanarak çok fazla istek kısmak için işçi iş parçacığı sahip sona erdi, aksi takdirde uygulama sadece bunalmış ve çökmesine ve yanmak. Bu, büyük bir birikmiş iş yığınının toplanabileceği anlamına geliyordu, ancak en azından site kaldı.

TestComplete'a bir göz atın .

İkinci openta önerisini. Sadece SMTP kullanarak test ettiğiniz sunucuyu izlemek için bir şeyler yapmanıza izin verdiğini ekleyeceğim. İşlemci yükünü, kullanılan belleği, gönderilen byes, vb. kaynağın sürümü çoğu OSS'den daha zor.

JMeter ile oynadım. Test edilemediğini düşünen bir tanesi ASP.NET Webforms idi. Görüşlerim sınavlarımı kırdı. Ben neden shure değilim, ama orada görüş durumu doğru ele dont birkaç araç vardır. Şu anki projem ASP.NET MVC ve JMeter onunla iyi çalışıyor.

FunkLoad ile iyi sonuçlar elde ettim :

• komut dosyası kullanıcı etkileşimi kolay
• raporlar açık
• sunucu yükünü izleyebilir

Utanmaz bir kendini tanıtmakla suçlanma riski altında, ücretsiz yük testi aracı arayışımda bu makaleye gittiğimi belirtmek isterim: http://www.devcurry.com/2010/07/10-free- araçlar-to-loadstress-testi-your.html

Ya istediğim verimi alamadım ya da istediğim esnekliği alamadım. VE Test sonrası analizde çoklu yük testi oluşturma ana bilgisayarlarının sonuçlarını kolayca toplamak istedim.

Listedeki her aracı denedim ve hayal kırıklığımdan hiçbirinin yapmak istediğim şeyi yapmadıklarını gördüm. Ben de bir tane yaptım ve paylaşıyorum.

İşte: http://sourceforge.net/projects/loadmonger

Not: Kentsel argoya aşina olan kişilerin isimleri hakkında gizli yorumlar yok. Şimdi değilim ama biraz daha dünyeviyim.

Ben oy Jmeter de ben @PeterBernier cevap için bazı tırnak eklemek istiyorum.

Yük testi cevaplarının ana sorusu, web uygulamamın eşzamanlı kullanıcı sayısını destekleyebilmesidir. Doğru bir cevap almak için, yük testi mümkün olduğunca yakın gerçek uygulama kullanımını temsil etmelidir .

Yukarıda aklınızda bulundurun, jMeter size bu konuda yardımcı olabilecek birçok yapı taşı Mantıksal Denetleyiciler , Yapılandırma Öğeleri , Ön İşlemciler , Dinleyiciler , ... içerir.

JMeter ile gerçek dünyadaki durumu taklit edebilirsiniz, örneğin:

1. Jmeter yapılandır yapılandırarak gerçek Tarayıcı gibi davranmaya ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Yapılandırma Jmeter kullanıcı istekleri oluşturmak (tanımlayarak number of users per second, ramp-up time, scheduling, ...)
3. Dağıtılmış bir yük testi yapmak için çok sayıda istemciyi jMeter ile yapılandırın.
4. Sunucunun sınama sırasında doğru yanıt verip vermediğini bulmak için yanıtı işleyin. (Örneğin, assertiçindeki bir metni bulma yanıtı)

Düşünün lütfen:

• Dakikada jMeter ile gerçek bir web uygulaması testi başlatmak kolaydır. JMeter, test senaryolarınızı kaydeden çok kolay bir araca sahiptir (olarak bilinir HTTP(S) Test Script Recorder).
• jMeter'de http://jmeter-plugins.org adresinde birçok eklenti vardır .
• JMeter UI salınım tabanlıdır ve jMeter 3.2'de iyi değişiklikler yapmıştır. Öte yandan, JMeter GUI sadece test ve hata ayıklama için kullanılmalıdır. Gerçek test için GUI modunda kullanmak iyi bir uygulama değildir. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Senaryonuzu yapılandırın ve test edin ve GUI olmayan modda çalıştırın.
• JMeter'de (Bilinen listeners) araçları gösteren çok sayıda raporlama vardır, ancak test sırasında açık değildir. Testinizi çalıştırmalı ve raporlar ( .jtldosyalar) oluşturmalısınız. O zaman sonucu analiz etmek için bu araçları kullanmalısınız. Lütfen https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats veya https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm adresine bakın .

Https://www.blazemeter.com/jmeter Eğer test ortamı yapılandırmak yardımına çok iyi ve pratik bilgiler vardır.