Melakukan Tes Stres pada Aplikasi Web?

Di masa lalu, saya menggunakan Alat Stres Aplikasi Web Microsoft dan Pylot untuk menekankan aplikasi web pengujian. Saya telah menulis beranda sederhana, skrip login, dan penelusuran situs (di situs e-niaga menambahkan beberapa item ke troli dan checkout).

Memukul beranda dengan keras dengan beberapa pengembang akan hampir selalu menemukan masalah besar. Lebih banyak masalah skalabilitas akan muncul pada tahap kedua, dan bahkan lebih - setelah peluncuran.

URL alat yang saya gunakan adalah Microsoft Homer (alias Microsoft Web Application Stress Tool ) dan Pylot .

Laporan yang dihasilkan oleh alat-alat ini tidak masuk akal bagi saya, dan saya akan menghabiskan berjam-jam mencoba untuk mencari tahu seperti apa beban serentak yang dapat didukung situs. Itu selalu sepadan karena bug dan kemacetan paling bodoh akan selalu muncul (misalnya, kesalahan konfigurasi server web).

Apa yang telah Anda lakukan, alat apa yang telah Anda gunakan, dan keberhasilan apa yang Anda miliki dengan pendekatan Anda? Bagian yang paling menarik bagi saya adalah menghasilkan semacam formula yang bermakna untuk menghitung jumlah pengguna bersamaan yang dapat didukung aplikasi dari angka yang dilaporkan oleh aplikasi stress test.

Ini suara lain untuk JMeter .

JMeter adalah alat pengujian beban sumber terbuka, ditulis dalam Java. Itu mampu menguji sejumlah jenis server yang berbeda (misalnya, web, layanan web, database, hampir semua hal yang menggunakan permintaan pada dasarnya).

Namun itu memiliki kurva belajar yang curam setelah Anda mulai menjalani tes yang rumit, tetapi itu sangat berharga. Anda dapat bangun dan berlari dengan sangat cepat, dan tergantung pada jenis stress testing yang ingin Anda lakukan, itu mungkin baik-baik saja.

Pro:

• Alat Open-Source / Gratis dari proyek Apache (membantu dengan buy-in)
• Mudah untuk memulai, dan mudah digunakan setelah Anda memahami konsep inti. (Yaitu, cara membuat permintaan, cara membuat pernyataan, cara bekerja dengan variabel dll).
• Sangat scalable. Saya sudah menjalankan tes dengan 11 mesin yang menghasilkan beban di server hingga hampir sejuta hit / jam. Itu jauh lebih mudah untuk diatur daripada yang saya harapkan.
• Memiliki komunitas aktif dan sumber daya yang baik untuk membantu Anda bangkit dan berjalan. Baca tutorialnya terlebih dahulu dan mainkan sebentar.

Cons:

• UI ditulis dalam Swing. (ugh!)
• JMeter bekerja dengan mem-parsing teks respons yang dikembalikan oleh server. Jadi jika Anda ingin memvalidasi segala jenis perilaku javascript, Anda kurang beruntung.
• Kurva pembelajaran curam untuk non-programmer. Jika Anda terbiasa dengan ekspresi reguler, Anda sudah di depan permainan.
• Ada sejumlah besar idiot ( sisipkan sumpah serapah ) di forum dukungan yang mengajukan pertanyaan bodoh yang dapat dengan mudah diselesaikan jika mereka akan memberikan dokumentasi bahkan pandangan sekilas. ('Bagaimana saya menggunakan JMeter untuk stress-test Windows GUI saya' cukup sering muncul).
• Melaporkan 'out of the box' menyisakan banyak yang diinginkan, terutama untuk tes yang lebih besar. Dalam tes yang saya sebutkan di atas, saya akhirnya harus menulis aplikasi konsol cepat untuk melakukan beberapa konversi 'xml-logfile' ke 'html'. Itu beberapa tahun yang lalu, jadi mungkin saja ini tidak lagi diperlukan.

Saya telah menggunakan The Grinder . Ini open source, cukup mudah digunakan, dan sangat dapat dikonfigurasi. Ini berbasis Java dan menggunakan Jython untuk skrip. Kami menjalankannya terhadap aplikasi web .NET, jadi jangan pikir itu hanya alat Java (menurut sifatnya, alat stres web apa pun tidak boleh dikaitkan dengan platform yang digunakannya).

Kami melakukan beberapa hal yang rapi dengan itu ... kami adalah aplikasi telekomunikasi berbasis web, jadi salah satu penggunaan keren yang saya buat adalah untuk meniru nomor panggilan melalui aplikasi web kami, kemudian menggunakan alat jawab otomatis yang kami miliki (yang pada dasarnya adalah tutorial aplikasi dari Microsoft untuk terhubung ke server RTC LCS mereka ... yang terhubung dengan Microsoft Office Communicator di jaringan lokal ... kemudian dimodifikasi untuk hanya menerima panggilan secara otomatis). Ini kemudian memungkinkan kami untuk menggunakan ini alih-alih alat telepon yang mahal yang disebut Hammer (atau sesuatu seperti itu).

Bagaimanapun, kami juga menggunakan alat untuk melihat bagaimana aplikasi kami bertahan di bawah beban tinggi, dan itu sangat efektif dalam menemukan kemacetan. Alat ini telah dibuat dalam pelaporan untuk menunjukkan berapa lama permintaan, tetapi kami tidak pernah menggunakannya. Log juga dapat menyimpan semua respons dan yang lainnya, atau log kustom.

Saya sangat merekomendasikan alat ini, sangat berguna untuk harganya ... tetapi berharap untuk melakukan beberapa pengaturan khusus dengannya (memiliki proxy bawaan untuk merekam skrip, tetapi mungkin perlu penyesuaian untuk menangkap sesuatu seperti sesi ... Saya tahu Saya harus menyesuaikannya untuk memanfaatkan sesi unik per utas).

Sedikit terlambat ke pesta ini. Saya setuju bahwa Pylot adalah alat open source terbaik yang akan datang di sana. Ini mudah digunakan dan secara aktif dikerjakan oleh orang hebat ( Corey Goldberg ). Sebagai pendiri OpenQA , saya juga senang bahwa Pylot sekarang terdaftar di halaman rumah kami dan menggunakan beberapa infrastruktur kami (yaitu forum).

Namun, saya juga baru-baru ini memutuskan bahwa seluruh konsep pengujian beban cacat: meniru lalu lintas HTTP, dengan aplikasi serumit mereka, adalah rasa sakit di pantat. Itu sebabnya saya membuat alat komersial BrowserMob. Ini adalah layanan pengujian beban eksternal yang menggunakan Selenium untuk mengontrol browser web nyata saat memutar kembali.

Pendekatan ini jelas membutuhkan satu ton lebih banyak perangkat keras daripada teknik pengujian beban normal, tetapi perangkat keras sebenarnya cukup murah ketika Anda menggunakan komputasi awan. Dan efek samping yang bagus dari ini adalah bahwa skrip jauh lebih mudah daripada pengujian beban normal. Anda tidak harus melakukan pencocokan regex lanjutan (seperti yang diperlukan JMeter) untuk mengekstrak cookie, status sesi .NET, parameter permintaan Ajax, dll. Karena Anda menggunakan browser nyata, mereka hanya melakukan apa yang seharusnya mereka lakukan.

Maaf telah secara terang-terangan meluncurkan produk komersial, tetapi mudah-mudahan konsep ini menarik bagi sebagian orang dan setidaknya membuat mereka memikirkan beberapa cara baru untuk menangani pengujian beban ketika Anda memiliki akses ke banyak perangkat keras tambahan!

Saya telah menggunakan JMeter . Selain menguji server web, Anda juga dapat menguji backend basis data, layanan pengiriman pesan, dan server email.

ab , pengepungan , tsung , httperf , Trample , Pylot, request-log-analyzer , perftools

Untuk penggunaan sederhana, saya perfer ab (benchmark apache) dan pengepungan, kemudian diperlukan karena ab tidak mendukung cookie dan akan membuat sesi tanpa akhir dari situs dinamis.

keduanya mudah untuk memulai:

ab -c n -t 30 url

siege -b -c n -t 30s url

pengepungan dapat berjalan dengan lebih banyak url.

versi pengepungan terakhir mengaktifkan verbose di dalam siegerc, yang mengganggu. Anda hanya dapat menonaktifkannya dengan mengedit file itu ( /usr/local/etc/siegerc).

Untuk layanan berbasis web, lihat loader.io .

Ringkasan:

loader.io adalah layanan pengujian beban gratis yang memungkinkan Anda menekankan pengujian aplikasi web / apis Anda dengan ribuan koneksi bersamaan.

Mereka juga memiliki API .

Karena pertanyaan ini masih terbuka, saya mungkin juga mempertimbangkan.

Berita baiknya adalah bahwa selama 5 tahun terakhir atau lebih, perangkat Open Source benar-benar telah matang dan lepas landas, kabar buruknya adalah ada begitu banyak dari mereka di luar sana.

Inilah pikiran saya: -

Jmeter vs Grinder

Jmeter didorong dari spesifikasi gaya XML, yang dibangun melalui GUI.

Grinder menggunakan skrip Jython dalam kerangka Java muti-threaded, jadi lebih berorientasi pada programmer.

Kedua alat akan menangani HTTP dan HTTPS dan memiliki perekam proksi untuk membantu Anda memulai. Kedua alat menggunakan model Pengendali untuk mendorong beberapa agen pengujian sehingga skalabilitas bukan merupakan masalah (diberikan akses ke Cloud).

Mana yang lebih baik:-

Panggilan yang sulit karena kurva belajarnya curam dengan kedua alat saat Anda masuk ke persyaratan skrip yang lebih rumit untuk penulisan ulang url, korelasi, menyediakan data unik per Pengguna Virtual dan mensimulasikan pertama kali atau mengembalikan Pengguna (dengan memanipulasi HTTP Header).

Yang mengatakan saya akan mulai dengan Jmeter karena alat ini memiliki banyak pengikut dan ada banyak contoh dan tutorial di web untuk menggunakan alat ini. Jika dan ketika Anda datang ke 'blok jalan', itu adalah sesuatu yang Anda tidak bisa 'dengan mudah' lakukan dengan Jmeter kemudian lihat di Grinder. Berita baiknya adalah kedua alat ini memiliki persyaratan Java yang sama dan solusi 'campur aduk' tidak keluar dari pertanyaan.

Sesuatu yang baru untuk ditambahkan - Browser tanpa kepala menjalankan banyak contoh Selenium WebDriver.

Ini adalah pendekatan yang relatif baru karena bergantung pada ketersediaan sumber daya yang sekarang dapat disediakan dari Cloud. Dengan pendekatan ini skrip Selenium (WebDriver) diambil dan dijalankan dalam browser tanpa kepala (yaitu WebDriver = New HtmlUnitDriver ()) driver di banyak utas.

Dari pengalaman sekitar 25 contoh 'browser tanpa kepala' dapat dijalankan dari Amazon M1 Small Instance.

Apa artinya ini adalah bahwa semua masalah korelasi, penulisan ulang url hilang saat Anda menggunakan kembali skrip pengujian fungsional Anda menjadi skrip pengujian kinerja.

Skalabilitas terganggu karena lebih banyak VM akan diperlukan untuk mendorong beban, dibandingkan dengan driver HTTP seperti Grinder atau Jmeter. Yang mengatakan, jika Anda mencari untuk mendorong 500 Pengguna Virtual maka dengan 20 Amazon Small Instances (masing-masing 6 sen per jam) dengan biaya hanya $ 1,20 per jam memberi Anda beban yang sangat dekat dengan Pengalaman Pengguna Nyata.

Juga, ada mengagumkan open-source murni python didistribusikan dan scalable belalang kerangka yang menggunakan greenlets . Ini hebat dalam mensimulasikan sejumlah besar pengguna simultan.

Kami baru-baru ini mulai menggunakan Gatling untuk pengujian beban. Saya akan sangat merekomendasikan untuk mencoba alat ini untuk pengujian beban. Kami telah menggunakan SOASTA dan JMETER di masa lalu. Alasan utama kami untuk mempertimbangkan Gatling adalah sebagai berikut:

• Perekam untuk merekam skenario
• Menggunakan Akka dan Netty yang memberikan kinerja lebih baik dibandingkan dengan model Jmeter Threading
• DSL Scala yang sangat mudah dikelola dibandingkan dengan Jmeter XML
• Mudah untuk menulis tes, jangan takut jika itu scala.
• Pelaporan

Biarkan saya memberi Anda contoh sederhana untuk menulis kode menggunakan Kode Gatling:

// 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)))       

Namun Anda dapat membuatnya serumit mungkin. Salah satu fitur yang menonjol bagi Gatling adalah pelaporan yang sangat detail.

Berikut adalah beberapa tautan:
Gatling
Gatling Tutorial

Saya baru-baru ini memberi ceramah tentang hal itu, Anda dapat melalui ceramah di sini:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Ini adalah pertanyaan lama, tapi saya pikir solusi yang lebih baru layak disebutkan. Checkout LoadImpact: http://www.loadimpact.com .

Saya mencoba WebLoad itu alat yang sangat rapi. Muncul dengan dan menguji skrip IDE yang memungkinkan Anda untuk merekam tindakan pengguna di situs web. Itu juga menggambar grafik saat melakukan stress test di server web Anda. Cobalah, saya sangat merekomendasikannya.

Mencoba semua yang disebutkan di sini, saya menemukan curl-loader sebagai yang terbaik untuk tujuan saya. antarmuka yang sangat mudah, pemantauan real-time, statistik yang berguna, dari mana saya membangun grafik kinerja. Semua fitur libcurl disertakan.

Blaze meter memiliki ekstensi chrome untuk sesi perekaman dan mengekspornya ke JMeter (saat ini membutuhkan login). Anda juga memiliki opsi untuk membayar mereka untuk menjalankannya di cluster server JMeter mereka (harga mereka tampaknya jauh lebih baik daripada LoadImpact yang baru saja saya hentikan penggunaannya):

• Ekstensi Chrome BlazeMeter
• Entri blog tentang hal itu

Saya tidak memiliki hubungan dengan mereka, saya hanya menyukai tampilan layanan mereka, meskipun saya belum menggunakan versi berbayar.

Anda mengajukan pertanyaan ini hampir setahun yang lalu dan saya tidak tahu apakah Anda masih mencari cara lain untuk membuat tolok ukur situs web Anda. Namun karena pertanyaan ini masih belum ditandai sebagai diselesaikan, saya ingin menyarankan layanan web gratis LoadImpact (btw. Tidak berafiliasi). Baru saja mendapatkan tautan ini melalui twitter dan ingin membagikan temuan ini. Mereka membuat ikhtisar yang baik dan wajar untuk beberapa dolar lebih Anda mendapatkan "mode dampak penuh". Ini mungkin terdengar aneh, tetapi semoga berhasil mendorong dan mengerem layanan Anda :)

Saya menemukan IBM Page Detailer juga merupakan alat yang menarik untuk dikerjakan.

Saya telah menggunakan openSTA .

Ini memungkinkan sesi dengan situs web direkam dan kemudian diputar ulang melalui bahasa skrip yang relatif sederhana.

Anda dapat dengan mudah menguji layanan web dan menulis skrip Anda sendiri.

Ini memungkinkan Anda untuk menempatkan skrip bersama-sama dalam tes dengan cara apa pun yang Anda inginkan dan mengonfigurasi jumlah iterasi, jumlah pengguna di setiap iterasi, waktu tanjakan untuk memperkenalkan setiap pengguna baru dan keterlambatan antara setiap iterasi. Tes juga dapat dijadwalkan di masa depan.

Ini open source dan gratis.

Ini menghasilkan sejumlah laporan yang dapat disimpan ke spreadsheet. Kami kemudian menggunakan tabel pivot untuk dengan mudah menganalisis dan membuat grafik hasil.

Kami menggunakan alat Microsoft yang disebutkan - Alat Stres Aplikasi Web Microsoft. Ini adalah alat termudah yang saya gunakan. Ini terbatas dalam banyak hal, termasuk hanya bisa mencapai port 80 pada tes yang dibuat secara manual. Tapi, kemudahan penggunaannya berarti benar-benar digunakan.

Kami menambah beban dari alat ini dengan alat lain termasuk OpenSTA dan tautan spider cek.

JMeter terlihat bagus dari evaluasi awal saya, saya berharap untuk memasukkannya dalam integrasi berkelanjutan kami ke depan. Tapi, JMeter rumit dan tidak mudah untuk diluncurkan.

Saya sarankan membuka pertanyaan lain tentang menafsirkan hasil alat stres MS.

Visual Studio Test Edition 2010 (2008 juga bagus). Ini adalah alat yang sangat mudah dan kuat untuk membuat pengujian web / load.

Bonus dengan alat ini saat digunakan melawan server Windows adalah Anda mendapatkan akses terintegrasi ke semua statistik server perfmon dalam laporan Anda. Sangat bermanfaat.

Bonus lainnya adalah bahwa dengan proyek Visual Studio Anda dapat mengintegrasikan "Sesi Kinerja" yang akan memprofilkan eksekusi kode situs web Anda.

Jika Anda melayani halaman web dari server windows, ini adalah alat terbaik di luar sana.

Namun, diperlukan lisensi terpisah dan mahal untuk menggunakan beberapa mesin untuk memuat pengujian aplikasi.

Kami telah mengembangkan proses yang memperlakukan pengukuran beban dan kinerja sebagai masalah kelas satu - seperti yang Anda katakan, membiarkannya sampai akhir proyek cenderung mengarah pada kekecewaan ...

Jadi, selama pengembangan, kami menyertakan pengujian multi-pengguna yang sangat dasar (menggunakan selenium), yang memeriksa kegilaan dasar seperti manajemen sesi yang rusak, masalah konkurensi yang jelas, dan masalah pertentangan sumber daya yang jelas. Proyek non-sepele memasukkan ini dalam proses integrasi berkelanjutan, jadi kami mendapatkan umpan balik yang sangat teratur.

Untuk proyek yang tidak memiliki persyaratan kinerja ekstrem, kami menyertakan pengujian kinerja dasar dalam pengujian kami; biasanya, kami membuat skrip tes menggunakan BadBoy, dan mengimpornya ke JMeter, mengganti detail login dan hal-hal khusus utas lainnya. Kami kemudian meningkatkan ini ke tingkat yang dihadapi server dengan 100 permintaan per detik; jika waktu respons kurang dari 1 detik, itu biasanya cukup. Kami memulai dan melanjutkan kehidupan kami.

Untuk proyek-proyek dengan persyaratan kinerja ekstrem, kami masih menggunakan BadBoy dan JMeter, tetapi menggunakan banyak energi untuk memahami hambatan pada server pada rig pengujian kami (biasanya server web dan database). Ada alat yang bagus untuk menganalisis log peristiwa Microsoft yang sangat membantu dalam hal ini. Kami biasanya menemukan hambatan yang tidak terduga, yang kami optimalkan jika memungkinkan; yang memberi kita aplikasi yang secepat mungkin di "1 server web, 1 server basis data". Kami kemudian biasanya menggunakan infrastruktur target kami, dan menggunakan salah satu layanan "Jmeter in the cloud" untuk menjalankan kembali pengujian pada skala.

Sekali lagi, laporan PAL membantu menganalisis apa yang terjadi selama pengujian - Anda sering melihat hambatan yang sangat berbeda pada lingkungan produksi.

Kuncinya adalah memastikan Anda tidak hanya menjalankan tes stres Anda, tetapi juga bahwa Anda mengumpulkan informasi yang Anda butuhkan untuk memahami kinerja aplikasi Anda.

Ada banyak alat bagus yang disebutkan di sini. Saya bertanya-tanya apakah alat adalah jawaban pertanyaan: "Bagaimana Anda bisa menguji aplikasi web?" Alat tidak benar-benar menyediakan metode untuk menekankan aplikasi Web. Inilah yang saya tahu:

Pengujian stres menunjukkan bagaimana aplikasi Web gagal saat melayani respons terhadap peningkatan populasi pengguna. Pengujian stres menunjukkan bagaimana aplikasi Web berfungsi saat gagal. Sebagian besar aplikasi Web saat ini - terutama aplikasi Web Sosial / Mobile - adalah integrasi layanan. Misalnya, ketika Facebook mengalami pemadaman pada Mei 2011 Anda tidak bisa masuk ke aplikasi Web Pepsi.com. Aplikasi ini tidak gagal sepenuhnya, hanya sebagian besar dari fungsi normalnya menjadi tidak tersedia bagi pengguna.

Pengujian kinerja menunjukkan kemampuan aplikasi Web untuk mempertahankan waktu respons terlepas dari berapa banyak pengguna yang menggunakan aplikasi secara bersamaan. Misalnya, aplikasi yang menangani 10 transaksi per detik dengan 10 pengguna bersamaan harus menangani 20 transaksi per detik pada 20 pengguna. Jika aplikasi menangani kurang dari 20 transaksi per detik, waktu respons tumbuh lebih lama dan aplikasi tidak dapat mencapai skalabilitas linier.

Juga, dalam contoh di atas jumlah transaksi per detik harus hanya dari operasi yang sukses dari kasus penggunaan / alur kerja pengujian. Kegagalan biasanya terjadi dalam rentang waktu yang lebih pendek dan akan membuat pengukuran TPS terlalu optimis. Kegagalan penting untuk uji tekanan dan kinerja karena mereka menghasilkan beban pada aplikasi juga.

Saya menulis metodologi PushToTest di Panduan Pengguna TestMaker di http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker hadir dalam dua rasa: Versi Komunitas Open Source (GPL) dan TestMaker Enterprise (komersial dengan dukungan profesional yang hebat.)

-Jujur

Lihatlah LoadBooster ( https://www.loadbooster.com ). Ini menggunakan browser skrip tanpa kepala PhantomJS / CasperJs untuk menguji situs web. Phantomjs akan menguraikan dan membuat setiap halaman, menjalankan skrip sisi klien. Pendekatan browser tanpa kepala lebih mudah untuk menulis skenario pengujian untuk mendukung aplikasi Web 2.0 berat AJAX yang kompleks, navigasi browser, klik mouse dan penekanan tombol ke dalam browser atau menunggu hingga ada elemen di DOM. LoadBooster mendukung skrip selenium HTML juga.

Penafian: Saya bekerja untuk LoadBooster.

Coba ZebraTester yang jauh lebih mudah digunakan daripada jMeter. Saya telah menggunakan jMeter untuk waktu yang lama tetapi total waktu setup untuk tes beban selalu menjadi masalah. Meskipun ZebraTester bukan open source, waktu yang saya simpan dalam enam bulan terakhir merupakan pengganti. Mereka juga memiliki portal SaaS yang dapat digunakan untuk menjalankan tes dengan cepat menggunakan generator beban mereka.

Satu lagi catatan, untuk aplikasi web kami, saya menemukan bahwa kami memiliki masalah kinerja yang sangat besar karena pertentangan antara utas-utas ... jadi moralnya adalah memikirkan skema penguncian dengan sangat hati-hati. Kami akhirnya memiliki utas pekerja untuk membatasi terlalu banyak permintaan menggunakan asinkron http handler, jika tidak aplikasi akan kewalahan dan macet dan terbakar. Itu berarti tumpukan besar bisa menumpuk, tetapi setidaknya situs akan tetap terjaga.

Lihatlah TestComplete .

Saya mendukung saran opensta. Saya hanya akan menambahkan bahwa ini memungkinkan Anda untuk melakukan hal-hal untuk memantau server yang Anda uji menggunakan SMTP. Kami melacak beban prosesor, memori yang digunakan, bye yang dikirim, dll. Satu-satunya downside adalah jika Anda menemukan sesuatu yang boken dan ingin melakukan perbaikan, hal itu bergantung pada beberapa pustaka sumber terbuka yang tidak lagi terpelihara, sehingga mendapatkan kompilasi versi sumber lebih rumit daripada kebanyakan OSS.

Saya bermain dengan JMeter. Satu berpikir itu tidak bisa menguji adalah ASP.NET Webforms. Kondisi tampilan memecahkan tes saya. Saya tidak tahu mengapa, tetapi ada beberapa alat di luar sana yang tidak menangani kondisi tampilan dengan benar. Proyek saya saat ini adalah ASP.NET MVC dan JMeter bekerja dengan baik dengannya.

Saya mendapat hasil yang baik dengan FunkLoad :

• interaksi pengguna skrip mudah
• laporannya jelas
• dapat memonitor beban server

Dengan risiko dituduh mempromosikan diri yang tidak tahu malu, saya ingin menunjukkan bahwa dalam pencarian saya untuk alat pengujian beban gratis, saya pergi ke artikel ini: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

Entah saya tidak bisa mendapatkan throughput yang saya inginkan, atau saya tidak bisa mendapatkan fleksibilitas yang saya inginkan. DAN saya ingin dengan mudah mengumpulkan hasil dari beberapa penghasil uji generasi beban dalam analisis post test.

Saya mencoba setiap alat dalam daftar dan frustrasi saya menemukan bahwa tidak ada dari mereka yang benar-benar melakukan apa yang saya inginkan. Jadi saya membangun satu dan membagikannya.

Ini dia: http://sourceforge.net/projects/loadmonger

PS: Tidak ada komentar sinis tentang nama dari orang-orang yang akrab dengan bahasa gaul perkotaan. Saya tidak tetapi sekarang sedikit lebih duniawi.

Saya memilih jMeter juga dan saya ingin menambahkan beberapa kutipan ke jawaban @PeterBernier.

Pertanyaan utama yang memuat jawaban pengujian adalah berapa banyak pengguna bersamaan yang dapat didukung aplikasi web saya? Untuk mendapatkan jawaban yang tepat, pengujian beban harus mewakili penggunaan aplikasi nyata, sedekat mungkin .

Perlu diingat, jMeter memiliki banyak blok bangunan Pengontrol Logis , Elemen Konfigurasi , Pra Prosesor , Pendengar , ... yang dapat membantu Anda dalam hal ini.

Anda dapat meniru situasi dunia nyata dengan jMeter, misalnya Anda dapat:

1. Konfigurasi JMeter untuk bertindak sebagai Browser nyata dengan mengkonfigurasi ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Konfigurasi JMeter untuk menghasilkan permintaan pengguna (dengan mendefinisikan number of users per second, ramp-up time, scheduling, ...)
3. Konfigurasikan banyak klien dengan jMeter pada mereka, untuk melakukan tes beban terdistribusi.
4. Proses respons untuk mengetahui apakah server merespons dengan benar selama pengujian. (Misalnya assertrespons untuk menemukan teks di dalamnya)

Tolong pertimbangkan:

• Sangat mudah untuk memulai tes aplikasi web nyata dengan jMeter dalam hitungan menit. JMeter memiliki alat yang sangat mudah yang merekam skenario pengujian Anda (kenal sebagai HTTP(S) Test Script Recorder).
• jMeter memiliki banyak plugin di http://jmeter-plugins.org .
• UI jMeter berbasis ayunan dan telah membuat perubahan yang baik dalam jMeter 3.2. Di sisi lain, harap pertimbangkan bahwa JMeter GUI hanya boleh digunakan untuk pengujian dan debugging. Bukan praktik yang baik untuk menggunakannya dalam mode GUI untuk pengujian yang sebenarnya. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-westout-using-jmeter-gui . Konfigurasikan dan uji skenario Anda dan jalankan pada mode non-gui.
• Ada banyak alat pelaporan pelaporan di jMeter (Dikenal sebagai listeners) tetapi tidak dimaksudkan untuk aktif selama pengujian. Anda harus menjalankan pengujian dan menghasilkan laporan ( .jtlfile). Maka Anda harus menggunakan alat ini untuk menganalisis hasil. Silakan lihat di https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats atau https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

The https://www.blazemeter.com/jmeter memiliki informasi yang sangat baik dan praktis untuk membantu Anda mengkonfigurasi lingkungan pengujian Anda.