Kiat JMeter

JMeter adalah alat sumber terbuka yang populer untuk pengujian beban, dengan banyak fitur pemodelan yang berguna seperti grup utas, pengatur waktu, dan elemen sampler HTTP. Artikel ini melengkapi Panduan Pengguna JMeter dan memberikan panduan untuk menggunakan beberapa elemen pemodelan JMeter untuk mengembangkan skrip pengujian kualitas.

Artikel ini juga membahas masalah penting dalam konteks yang lebih besar: menentukan persyaratan waktu respons yang tepat dan memvalidasi hasil tes. Secara khusus, metode statistik yang ketat, analisis interval kepercayaan, diterapkan.

Harap dicatat bahwa saya berasumsi pembaca mengetahui dasar-dasar JMeter. Contoh artikel ini didasarkan pada JMeter 2.0.3.

Tentukan periode peningkatan grup utas

Bahan pertama dalam skrip JMeter Anda adalah grup utas, jadi mari kita tinjau dulu. Seperti yang ditunjukkan pada Gambar 1, elemen Thread Group berisi parameter berikut:

  • Jumlah utas.
  • Periode peningkatan.
  • Frekuensi pengujian dilakukan.
  • Saat dimulai, apakah pengujian langsung dijalankan atau menunggu hingga waktu yang dijadwalkan. Jika yang terakhir, elemen Grup Benang juga harus menyertakan waktu mulai dan waktu berakhir.

Setiap thread menjalankan rencana pengujian secara independen dari thread lain. Oleh karena itu, grup utas digunakan untuk memodelkan pengguna bersamaan. Jika mesin klien yang menjalankan JMeter tidak memiliki cukup daya komputasi untuk memodelkan beban berat, fitur pengujian distributif JMeter memungkinkan Anda untuk mengontrol beberapa mesin JMeter jarak jauh dari satu konsol JMeter.

Periode ramp-up memberi tahu JMeter jumlah waktu untuk membuat jumlah total utas. Nilai defaultnya adalah 0. Jika periode ramp-up dibiarkan tidak ditentukan, yaitu periode ramp-up adalah nol, JMeter akan segera membuat semua thread. Jika periode ramp-up diatur ke T detik, dan jumlah total utas adalah N, JMeter akan membuat utas setiap T / N detik.

Sebagian besar parameter grup utas cukup jelas, tetapi periode ramp-up agak aneh, karena jumlah yang sesuai tidak selalu jelas. Untuk satu hal, periode ramp-up tidak boleh nol jika Anda memiliki banyak thread. Pada awal uji beban, jika periode ramp-up nol, JMeter akan membuat semua utas sekaligus dan segera mengirimkan permintaan, sehingga berpotensi memenuhi server dan, yang lebih penting, meningkatkan beban secara menipu. Artinya, server bisa kelebihan beban, bukan karena rasio klik rata-rata tinggi, tetapi karena Anda mengirim semua permintaan pertama utas secara bersamaan, menyebabkan rasio klik puncak awal yang tidak biasa. Anda dapat melihat efek ini dengan pendengar Laporan Agregat JMeter.

Karena anomali ini tidak diinginkan, maka aturan praktis untuk menentukan periode peningkatan yang wajar adalah dengan menjaga rasio klik awal mendekati rasio klik rata-rata. Tentu saja, Anda mungkin perlu menjalankan rencana pengujian sekali sebelum menemukan angka yang masuk akal.

Dengan cara yang sama, periode ramp-up yang besar juga tidak sesuai, karena beban puncak mungkin diremehkan. Artinya, beberapa utas mungkin belum dimulai, sementara beberapa utas awal sudah dihentikan.

Jadi, bagaimana Anda memverifikasi bahwa periode ramp-up tidak terlalu kecil atau terlalu besar? Pertama, tebak rasio hit rata-rata lalu hitung periode peningkatan awal dengan membagi jumlah untaian dengan rasio klik yang diperkirakan. Misalnya, jika jumlah utas adalah 100, dan perkiraan rasio klik adalah 10 klik per detik, perkiraan periode peningkatan ideal adalah 100/10 = 10 detik. Bagaimana Anda mendapatkan perkiraan rasio klik? Tidak ada cara yang mudah. Anda hanya perlu menjalankan skrip pengujian sekali terlebih dahulu.

Kedua, tambahkan listener Laporan Agregat, yang ditunjukkan pada Gambar 2, ke rencana pengujian; ini berisi rasio klik rata-rata dari setiap permintaan individual (contoh JMeter). Tingkat klik dari sampler pertama (misalnya, permintaan HTTP) terkait erat dengan periode peningkatan dan jumlah untaian. Sesuaikan periode peningkatan sehingga rasio klik sampel pertama rencana pengujian mendekati rasio klik rata-rata dari semua sampel lainnya.

Ketiga, verifikasi di log JMeter (terletak di JMeter_Home_Directory / bin) bahwa utas pertama yang selesai memang selesai setelah utas terakhir dimulai. Perbedaan waktu antara keduanya harus sejauh mungkin.

Singkatnya, penentuan waktu ramp-up yang baik diatur oleh dua aturan berikut:

  • Rasio klik sampel pertama harus mendekati rasio klik rata-rata dari sampel lain, sehingga mencegah periode peningkatan kecil
  • Urutan pertama yang selesai memang selesai setelah utas terakhir dimulai, sebaiknya sejauh mungkin, sehingga mencegah periode ramp-up yang besar

Terkadang kedua aturan tersebut saling bertentangan. Artinya, Anda tidak dapat menemukan periode peningkatan yang sesuai yang melewati kedua aturan tersebut. Rencana pengujian yang sepele biasanya menyebabkan masalah ini, karena, dalam rencana seperti itu, Anda kekurangan sampel yang cukup untuk setiap utas; dengan demikian, rencana pengujian terlalu pendek, dan thread dengan cepat menyelesaikan pekerjaannya.

Pengguna berpikir waktu, timer, dan server proxy

Elemen penting untuk dipertimbangkan dalam uji beban adalah waktu berpikir, atau jeda di antara permintaan yang berurutan. Berbagai keadaan menyebabkan penundaan: pengguna membutuhkan waktu untuk membaca konten, atau untuk mengisi formulir, atau untuk mencari tautan yang tepat. Kegagalan untuk mempertimbangkan waktu berpikir dengan benar sering kali menyebabkan hasil tes yang sangat bias. Misalnya, perkiraan skalabilitas, yaitu, beban maksimum (pengguna bersamaan) yang dapat dipertahankan sistem, akan tampak rendah.

JMeter menyediakan satu set elemen pengatur waktu untuk memodelkan waktu berpikir, tetapi pertanyaan tetap ada: bagaimana Anda menentukan waktu berpikir yang tepat? Untungnya, JMeter menawarkan jawaban yang bagus: elemen JMeter HTTP Proxy Server.

Server proxy merekam tindakan Anda saat Anda menelusuri aplikasi Web dengan browser biasa (seperti FireFox atau Internet Explorer). Selain itu, JMeter membuat rencana pengujian saat merekam tindakan Anda. Fitur ini sangat nyaman untuk beberapa tujuan:

  • Anda tidak perlu membuat permintaan HTTP secara manual, terutama parameter formulir yang membosankan. (Namun, parameter non-Inggris mungkin tidak bekerja dengan benar.) JMeter akan merekam semua yang ada di permintaan yang dibuat secara otomatis, termasuk bidang tersembunyi.
  • Dalam rencana pengujian yang dihasilkan, JMeter menyertakan semua header HTTP yang dibuat browser untuk Anda, seperti User-Agent (misalnya, Mozilla / 4.0), atau AcceptLanguage (misalnya, zh-tw, en-us; q = 0.7, zh- cn; q = 0,3).
  • JMeter dapat membuat pengatur waktu pilihan Anda, di mana waktu tunda diatur sesuai dengan penundaan sebenarnya selama periode perekaman.

Mari kita lihat cara mengkonfigurasi JMeter dengan fitur perekaman. Di konsol JMeter, klik kanan elemen WorkBench dan tambahkan elemen HTTP Proxy Server. Perhatikan bahwa Anda mengklik kanan elemen WorkBench, bukan elemen Test Plan, karena konfigurasi di sini adalah untuk merekam, bukan untuk rencana pengujian yang dapat dijalankan. Tujuan elemen HTTP Proxy Server adalah agar Anda mengonfigurasi server proxy browser sehingga semua permintaan melalui JMeter.

Seperti yang diilustrasikan pada Gambar 3, beberapa bidang harus dikonfigurasi untuk elemen HTTP Proxy Server:

  • Porta : Port mendengarkan yang digunakan oleh server proxy.
  • Pengontrol Target: Pengontrol tempat proxy menyimpan sampel yang dihasilkan. Secara default, JMeter akan mencari pengontrol perekaman dalam rencana pengujian saat ini dan menyimpan sampel di sana. Sebagai alternatif, Anda dapat memilih elemen pengontrol yang terdaftar di menu. Biasanya, defaultnya oke.
  • Pengelompokan: Bagaimana Anda ingin mengelompokkan elemen yang dihasilkan dalam rencana pengujian. Beberapa opsi tersedia, dan yang paling masuk akal mungkin adalah "Simpan sampel pertama dari setiap grup saja", jika tidak, URL yang disematkan di halaman seperti gambar dan JavaScripts juga akan direkam. Namun, Anda mungkin ingin mencoba opsi default "Jangan kelompokkan sampel" untuk mengetahui apa yang sebenarnya dibuat JMeter untuk Anda dalam rencana pengujian.
  • Pola untuk Disertakan dan Pola untuk Dikecualikan: Membantu Anda memfilter beberapa permintaan yang tidak diinginkan.

Ketika Anda mengklik tombol Start, server proxy mulai dan mulai merekam permintaan HTTP yang diterimanya. Tentu saja, sebelum mengklik Mulai, Anda harus mengkonfigurasi pengaturan server proxy browser Anda.

Anda dapat menambahkan pengatur waktu sebagai anak dari elemen HTTP Proxy Server, yang akan menginstruksikan JMeter untuk secara otomatis menambahkan pengatur waktu sebagai anak dari permintaan HTTP yang dihasilkannya. JMeter secara otomatis menyimpan penundaan waktu aktual ke variabel JMeter yang disebut T, jadi jika Anda menambahkan pengatur waktu acak Gaussian ke elemen HTTP Proxy Server, Anda harus mengetik $ {T} di bidang Penundaan Konstan, seperti yang ditunjukkan pada Gambar 4. Ini adalah fitur nyaman lainnya yang menghemat banyak waktu.

Perhatikan bahwa pengatur waktu menyebabkan sampler yang terpengaruh ditunda. Artinya, permintaan pengambilan sampel yang terpengaruh tidak dikirim sebelum waktu tunda yang ditentukan berlalu sejak tanggapan terakhir yang diterima. Oleh karena itu, Anda harus secara manual menghapus timer yang dihasilkan sampler pertama karena sampler pertama biasanya tidak memerlukannya.

Sebelum memulai server proxy HTTP, Anda harus menambahkan grup utas ke rencana pengujian dan kemudian, ke grup utas, menambahkan pengontrol rekaman, tempat elemen yang dihasilkan akan disimpan. Jika tidak, elemen tersebut akan ditambahkan ke WorkBench secara langsung. Selain itu, penting untuk menambahkan elemen Default Permintaan HTTP (elemen Konfigurasi) ke pengontrol perekaman, sehingga JMeter akan mengosongkan bidang yang ditentukan oleh default permintaan HTTP.

Setelah merekam, hentikan server proxy HTTP; klik kanan elemen Recording Controller untuk menyimpan elemen yang direkam dalam file terpisah sehingga Anda dapat mengambilnya nanti. Jangan lupa untuk melanjutkan pengaturan server proxy browser Anda.

Tentukan persyaratan waktu respons dan validasi hasil tes

Meskipun tidak terkait langsung dengan JMeter, menentukan persyaratan waktu respons dan memvalidasi hasil pengujian adalah dua tugas penting untuk pengujian beban, dengan JMeter menjadi jembatan yang menghubungkannya.

Dalam konteks aplikasi Web, waktu respons mengacu pada waktu yang telah berlalu antara pengiriman permintaan dan penerimaan HTML yang dihasilkan. Secara teknis, waktu respons harus menyertakan waktu bagi browser untuk merender halaman HTML, tetapi browser biasanya menampilkan halaman sepotong demi sepotong, membuat waktu respons yang dirasakan lebih sedikit. Selain itu, biasanya, alat uji beban menghitung waktu respons tanpa mempertimbangkan waktu rendering. Oleh karena itu, untuk tujuan praktis pengujian kinerja, kami mengadopsi definisi yang dijelaskan di atas. Jika ragu, tambahkan konstanta ke waktu respons yang diukur, misalnya 0,5 detik.

Ada seperangkat aturan terkenal untuk menentukan kriteria waktu respons:

  • Pengguna tidak melihat penundaan kurang dari 0,1 detik
  • Penundaan kurang dari 1 detik tidak mengganggu alur pemikiran pengguna, tetapi akan terjadi penundaan
  • Pengguna masih akan menunggu respon jika tertunda kurang dari 10 detik
  • Setelah 10 detik, pengguna kehilangan fokus dan mulai melakukan hal lain

Ambang batas ini sudah diketahui dengan baik dan tidak akan berubah karena terkait langsung dengan karakteristik kognitif manusia. Meskipun Anda harus menetapkan persyaratan waktu respons sesuai dengan aturan ini, Anda juga harus menyesuaikannya untuk aplikasi khusus Anda. Misalnya, beranda Amazon.com mematuhi aturan di atas, tetapi karena lebih menyukai tampilan yang lebih bergaya, ini mengorbankan sedikit waktu respons.

Sekilas, tampaknya ada dua cara berbeda untuk menentukan persyaratan waktu respons:

  • Waktu respons rata-rata
  • Waktu respons mutlak; artinya, waktu respons semua respons harus di bawah ambang batas

Menentukan persyaratan waktu respons rata-rata sangatlah mudah, tetapi fakta bahwa persyaratan ini gagal memperhitungkan variasi data sangat mengganggu. Bagaimana jika waktu respons 20 persen sampel lebih dari tiga kali rata-rata? Perhatikan bahwa JMeter menghitung waktu respons rata-rata serta deviasi standar untuk Anda di listener Hasil Grafik.

Di sisi lain, persyaratan waktu respons absolut cukup ketat dan secara statistik tidak praktis. Bagaimana jika hanya 0,5 persen sampel yang gagal lulus tes? Sekali lagi, ini terkait dengan variasi pengambilan sampel. Untungnya, metode statistik yang ketat mempertimbangkan variasi pengambilan sampel: analisis interval kepercayaan.

Mari kita tinjau statistik dasar sebelum melangkah lebih jauh.

Teorema batas pusat

Teorema batas pusat menyatakan bahwa jika distribusi populasi memiliki mean μ dan deviasi standar σ, maka untuk n cukup besar (> 30), distribusi sampling mean sampling mendekati normal, dengan mean μ mean = μ dan deviasi standar σ rata-rata = σ / √n.

Perhatikan bahwa distribusi mean sampling adalah normal. Distribusi pengambilan sampel itu sendiri belum tentu normal. Artinya, jika Anda menjalankan skrip pengujian berkali-kali, distribusi waktu respons rata-rata yang dihasilkan akan normal.

Gambar 5 dan 6 di bawah ini menunjukkan dua distribusi normal. Dalam konteks kami, sumbu horizontal adalah rata-rata pengambilan sampel waktu respons, digeser sehingga rata-rata populasi berada di asal. Gambar 5 menunjukkan bahwa 90 persen dari waktu, rata-rata sampling berada dalam interval ± Zσ, di mana Z = 1.645 dan σ adalah deviasi standar. Gambar 6 menunjukkan kasus 99 persen, di mana Z = 2.576. Untuk probabilitas tertentu, katakanlah 90 persen, kita dapat mencari nilai Z yang sesuai dengan kurva normal dan sebaliknya.