Salah sahiji masalah anu sering disanghareupan ku padagang parangkat lunak multi-produk nyaéta duplikasi kompeténsi insinyur - pamekar, panguji, sareng pangurus infrastruktur - dina ampir unggal tim. Ieu ogé lumaku pikeun insinyur mahal - spesialis dina widang nguji beban.
Gantina ngalakukeun tugas langsung maranéhanana sarta ngagunakeun pangalaman unik maranéhna pikeun ngawangun prosés nguji beban, milih hiji metodologi, metrics optimal sarta nulis autotests luyu jeung profil beban, insinyur mindeng kudu nyebarkeun infrastruktur test ti scratch, ngonpigurasikeun parabot beban, sarta embed aranjeunna. sorangan dina sistem CI, nyetél monitoring sarta publikasi laporan.
Anjeun tiasa mendakan solusi pikeun sababaraha masalah organisasi dina nguji anu kami anggo di Positive Technologies di . Sareng dina ieu, kuring bakal ngobrol ngeunaan kamungkinan ngahijikeun tés beban kana pipa CI umum nganggo konsép "uji beban salaku jasa" (uji beban salaku jasa). Anjeun bakal diajar kumaha sareng gambar docker mana sumber beban tiasa dianggo dina pipa CI; kumaha nyambungkeun sumber beban ka proyék CI anjeun ngagunakeun template ngawangun; naon pipa demo Sigana pikeun ngajalankeun tés beban sarta medarkeun hasil. Tulisan éta tiasa kapaké pikeun insinyur tés parangkat lunak sareng insinyur otomatisasi di CI anu mikirkeun arsitektur sistem bebanna.
Hakekat konsep
Konsep tés beban salaku jasa nunjukkeun kamampuan pikeun ngahijikeun alat beban Apache JMeter, Yandex.Tank sareng kerangka anjeun sorangan kana sistem integrasi kontinyu anu sawenang. Demo bakal kanggo GitLab CI, tapi prinsipna umum pikeun sadaya sistem CI.
Uji beban salaku jasa mangrupikeun jasa terpusat pikeun uji beban. Tes beban dijalankeun dina pools agén khusus, hasil diterbitkeun sacara otomatis ka GitLab Pages, Influx DB sareng Grafana atanapi pikeun nguji sistem pelaporan (TestRail, ReportPortal, jsb.). Automation sareng skala dilaksanakeun sabisa-gancang - ku nambihan sareng parameterisasi template gitlab-ci.yml biasa dina proyék GitLab CI.
Kauntungannana pendekatan ieu nyaéta sakabéh infrastruktur CI, agén beban, gambar docker tina sumber beban, pipelines nguji, sarta laporan penerbitan dijaga ku departemén automation terpusat (insinyur DevOps), sedengkeun insinyur nguji beban bisa museurkeun usaha maranéhanana dina ngembangkeun test. jeung analisis hasil maranéhanana, tanpa kaayaan masalah infrastruktur.
Pikeun kesederhanaan déskripsi, urang bakal nganggap yén aplikasi target atanapi server anu diuji parantos dipasang sareng dikonpigurasi sateuacanna (skrip otomatis dina Python, SaltStack, Ansible, jsb. tiasa dianggo pikeun ieu). Teras sadayana konsép tés beban salaku jasa pas kana tilu tahapan: persiapan, nguji, publikasi laporan. Langkung rinci ngeunaan diagram (sadaya gambar tiasa diklik):
Konsep dasar sareng definisi dina uji beban
Nalika ngalaksanakeun tés beban, urang nyobian taat , ngagunakeun terminologi luyu jeung metrics dianjurkeun. Kuring bakal masihan daptar pondok tina konsép sareng definisi utama dina uji beban.
Agén beban - mesin virtual dimana aplikasi bakal dibuka - sumber beban (Apache JMeter, Yandex.Tank atawa modul beban ditulis sorangan).
Tujuan tés (sasaran) - server atawa aplikasi dipasang dina server anu bakal tunduk kana beban.
Skenario tés (kasus tés) - sakumpulan léngkah-léngkah anu diparameterkeun: tindakan pangguna sareng réaksi anu dipiharep kana tindakan ieu, kalayan pamundut sareng réspon jaringan tetep, gumantung kana parameter anu ditangtukeun.
Propil atanapi rencana beban (profil) - at (Bagian 4.2.4, p. 43) beban profil nangtukeun metrics anu kritis pikeun test husus sarta pilihan pikeun ngarobah parameter beban salila ujian. Anjeun tiasa ningali conto profil dina gambar.
Tes - Aksara kalawan set predetermined parameter.
Rencana uji (rencana uji) - sakumpulan tés sareng profil beban.
Testran (testrun) - hiji iterasi ngajalankeun hiji tés kalawan skenario beban pinuh dieksekusi jeung laporan narima.
Paménta jaringan (paménta) - Hiji pamundut HTTP dikirim ti agén ka udagan.
réspon jaringan (réspon) - Réspon HTTP dikirim ti udagan ka agén.
Kode réspon HTTP (status réspon HTTP) - kode réspon standar tina server aplikasi.
Transaksi mangrupikeun siklus pamundut-réspon lengkep. Transaksi diitung ti mimiti ngirim paménta (request) nepi ka réngsé narima respon (respon).
Status transaksi - naha éta mungkin pikeun suksés ngalengkepan siklus pamundut-réspon. Upami aya kasalahan dina siklus ieu, maka sadaya transaksi dianggap gagal.
waktos réspon (latency) - waktu ti ahir ngirim pamenta (request) nepi ka mimiti narima respon (respon).
Métrik beban - Karakteristik jasa anu dimuat sareng agén beban ditangtukeun dina prosés uji beban.
Métrik dasar pikeun ngukur parameter beban
Sababaraha anu paling sering dianggo sareng disarankeun dina metodologi (kc. 36, 52) métrik ditémbongkeun dina tabél di handap. Métrik anu sami pikeun agén sareng target didaptarkeun dina garis anu sami.
Métrik pikeun agén beban
Métrik tina sistem target atanapi aplikasi anu diuji dina beban
jumlah vCPU jeung memori Ram,
cakram - "beusi" ciri tina agén beban
CPU, Mémori, Pamakéan disk - dinamika CPU, mémori sareng beban disk
dina prosés nguji. Biasana diukur salaku perséntase
nilai maksimum sadia
throughput jaringan (dina agén beban) - throughput
panganteur jaringan dina server,
dimana agén beban dipasang.
Biasana diukur dina bait per detik (bps)
throughput jaringan(dina sasaran) - rubakpita panganteur jaringan
dina server target. Biasana diukur dina bait per detik (bps)
pamaké maya- jumlah pamaké virtual,
ngalaksanakeun skenario beban sarta
niru tindakan pamaké nyata
Status pamaké maya, Lulus/Gagal/Total — jumlah suksés jeung
statuses gagal pamaké virtual
pikeun skenario beban, kitu ogé jumlah total maranéhanana.
Umumna diperkirakeun yén sadaya pangguna tiasa ngalengkepan
sadaya pancén anjeun dieusian dina profil beban.
Kasalahan naon waé hartosna yén pangguna nyata moal tiasa
ngajawab masalah anjeun nalika gawé bareng sistem
Paménta per detik (menit)- Jumlah pamundut jaringan per detik (atanapi menit).
Karakteristik penting tina agén beban nyaéta sabaraha pamundut anu tiasa dibangkitkeun.
Kanyataanna, ieu tiruan aksés ka aplikasi ku pamaké virtual
Tanggapan per detik (menit)
- jumlah réspon jaringan per detik (atawa menit).
Hiji ciri penting tina jasa target: sabaraha
ngahasilkeun sarta ngirimkeun réspon kana queries kalawan
agén loading
Status respon HTTP- Jumlah kode respon béda
ti pangladén aplikasi anu ditampi ku agén beban.
Contona, 200 OK hartina telepon suksés,
jeung 404 - yén sumberdaya teu kapanggih
Latency (waktos respon) - waktos ti tungtung
ngirimkeun pamenta (request) samemeh mimiti narima jawaban (response).
Biasana diukur dina milidetik (ms)
waktos respon transaksi- waktos hiji transaksi lengkep,
parantosan siklus pamundut-réspon.
Ieu waktos ti mimiti ngirim pamundut (paménta)
nepi ka réngsé narima jawaban (respon).
Waktos transaksi tiasa diukur dina detik (atanapi menit)
ku sababaraha cara: mertimbangkeun minimum,
maksimum, rata jeung, contona, persentil 90th.
Bacaan minimum sareng maksimal ekstrim
status kinerja sistem.
Persentil kasalapan puluh mangrupikeun anu paling sering dianggo,
sabab nunjukkeun kalolobaan pangguna,
comfortably beroperasi dina bangbarung kinerja sistem
Transaksi per detik (menit) - jumlah lengkep
transaksi per detik (menit),
éta, sabaraha aplikasi éta bisa nampa na
requests prosés jeung réspon masalah.
Nyatana, ieu mangrupikeun throughput sistem
Status transaksi , Lulus / Gagal / Total - angka
suksés, gagal jeung total jumlah transaksi.
Pikeun pamaké nyata gagal
urus sabenerna bakal hartosna
henteu mampuh pikeun digawe sareng sistem dina beban
Diagram Skématik Uji beban
Konsep tés beban saderhana pisan sareng diwangun ku tilu tahapan utama, anu ku kuring parantos disebatkeun: Nyiapkeun-Test-Laporan, nyaéta, nyiapkeun tujuan tés sareng netepkeun parameter pikeun sumber beban, teras ngalaksanakeun tés beban sareng, dina tungtungna, ngahasilkeun sareng nyebarkeun laporan tés.
Catetan Skema:
- QA.Tester mangrupikeun ahli dina uji beban,
- Target mangrupikeun aplikasi target anu anjeun hoyong terang kalakuanana dina beban.
Klasifikasi éntitas, tahapan sareng léngkah dina diagram
Tahap jeung léngkah
Aya naon
Naon di lawang
Naon kaluaran
Nyiapkeun: tahap persiapan pikeun nguji
LoadParameters
Setélan jeung initialization
pamaké
parameter beban,
pilihan métrik jeung
persiapan rencana tés
(muatan profil)
pilihan custom pikeun
initialization agén beban
Rencana tés
Tujuan tina nguji
VM
Panyebaran awan
mesin virtual kalawan
ciri diperlukeun
Setélan VM pikeun agén beban
Aksara Automation pikeun
kreasi VM
VM dikonpigurasi dina
awan
Ngirim
Setélan sareng persiapan OS
lingkungan pikeun
karya agén beban
Setélan lingkungan pikeun
agén beban
Aksara Automation pikeun
setélan lingkungan
Lingkungan anu disiapkeun:
OS, jasa sareng aplikasi,
diperlukeun pikeun digawé
agén beban
LoadAgents
Pamasangan, konfigurasi sareng parameterisasi
agén loading.
Atawa ngundeur gambar docker ti
sumber beban preconfigured
Muatkeun gambar docker sumber
(YAT, JM atawa kerangka tulisan sorangan)
Setélan
agén beban
Siapkeun sareng siap
pikeun dianggo agén beban
Tés: tahap palaksanaan tés beban. Sumberna mangrupikeun agén beban anu disebarkeun dina kolam agén khusus pikeun GitLab CI
momotkeun
Ngamimitian Agen Beban
kalawan rencana test dipilih
jeung parameter beban
Pilihan pamaké
pikeun initialization
agén beban
Rencana tés
Tujuan tina nguji
Log palaksanaan
tés beban
Log Sistim
Dinamika parobahan métrik gawang sareng agén beban
Jalankeun Agén
Palaksanaan Agen
beban naskah tés
dumasarkeun kana
beban profil
Beban Agén Interaksi
pikeun tujuan nguji
Rencana tés
Tujuan tina nguji
log
Koléksi log "atah".
salila uji beban:
rékaman kagiatan agén beban,
kaayaan udagan tés
jeung VM ngajalankeun agén
Log palaksanaan
tés beban
Log Sistim
metrics
Ngumpulkeun métrik "atah" salami tés
Dinamika parobahan dina métrik gawang
jeung agén beban
Laporan: tahap persiapan laporan tés
generator
Ngolah dikumpulkeun
sistem loading jeung
sistem monitoring "atah"
métrik jeung log
Pembentukan laporan dina
wangun dibaca manusa
mungkin kalawan elemen
analis
Log palaksanaan
tés beban
Log Sistim
Dinamika parobahan dina métrik
target jeung agén beban
Diolah "atah" log
dina format cocog pikeun
unggah ka panyimpenan éksternal
Laporan beban statik,
bisa dibaca ku manusa
nyebarkeun
Publikasi laporan
ngeunaan beban
nguji dina éksternal
palayanan
Diolah "atah"
log dina format cocog
pikeun unloading ka éksternal
repositories
Disimpen dina éksternal
laporan gudang on
beban, cocog
pikeun analisis manusa
Nyambungkeun sumber beban dina citakan CI
Hayu urang ngaléngkah ka bagian praktis. Abdi hoyong nunjukkeun kumaha dina sababaraha proyék di perusahaan kami parantos ngalaksanakeun konsép tés beban salaku jasa.
Mimiti, kalayan bantosan insinyur DevOps kami, kami nyiptakeun kolam renang khusus agén di GitLab CI pikeun ngajalankeun tés beban. Pikeun henteu ngabingungkeun aranjeunna dina témplat sareng anu sanés, sapertos pools assembly, kami nambihan tag kana agén ieu, : beban. Anjeun tiasa nganggo tag anu sanés anu kaharti. Aranjeunna nanya GitLab CI Runners.
Kumaha carana manggihan kakuatan diperlukeun ku hardware? Karakteristik agén beban - sajumlah vCPU, RAM sareng Disk anu cekap - tiasa diitung dumasar kana kanyataan yén Docker, Python (pikeun Yandex.Tank), agén GitLab CI, Java (pikeun Apache JMeter) kedah dijalankeun dina agén. . Pikeun Java dina JMeter, disarankeun ogé ngagunakeun minimum 512 MB RAM sareng, salaku wates luhur, .
Ku kituna, dumasar kana pangalaman urang, kami nyarankeun ngagunakeun sahenteuna 4 vCPUs, 4 GB RAM, 60 GB SSD pikeun agén beban. The throughput tina kartu jaringan ditangtukeun dumasar kana sarat tina profil beban.
Urang utamana ngagunakeun dua sumber beban - Apache JMeter jeung Yandex.Tank docker gambar.
mangrupa alat open source ti Yandex pikeun nguji beban. Arsitéktur modularna didasarkeun kana generator pamundut HTTP dumasar hit-kinerja tinggi Phantom. Tangki ngagaduhan ngawaskeun sumber daya pangladén anu diuji ku protokol SSH, tiasa otomatis ngeureunkeun tés dina kaayaan anu ditangtukeun, tiasa ningalikeun hasilna dina konsol sareng dina bentuk grafik, anjeun tiasa nyambungkeun modul anjeun. ka dinya pikeun ngalegaan fungsionalitas. Ku jalan kitu, kami nganggo Tank nalika éta henteu acan mainstream. Dina artikel "» Anjeun tiasa maca carita kumaha urang ngalaksanakeun uji beban sareng éta dina 2013 mangrupa salah sahiji produk parusahaan urang.
mangrupa alat nguji beban open source ti Apache. Éta tiasa dianggo ogé pikeun nguji aplikasi wéb statik sareng dinamis. JMeter ngadukung sajumlah ageung protokol sareng cara pikeun berinteraksi sareng aplikasi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, jsb.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) jeung IMAP(S), basis data via JDBC, bisa ngaéksekusi paréntah cangkang jeung gawé bareng objék Java. JMeter boga IDE pikeun nyieun, debugging na executing rencana test. Aya ogé CLI pikeun operasi garis paréntah dina sagala sistem operasi Java cocog (Linux, Windows, Mac OS X). alat nu dinamis bisa ngahasilkeun laporan test HTML.
Pikeun gampang dianggo dina perusahaan kami, pikeun kamampuan para panguji nyalira ngarobih sareng nambihan lingkungan, kami ngadamel gambar docker tina sumber beban dina GitLab CI sareng publikasi ka internal. . Hal ieu ngajadikeun eta gancang sarta gampang pikeun nyambungkeun aranjeunna dina pipelines pikeun tés beban. Kumaha docker push ka pendaptaran via GitLab CI - tingali .
Kami nyandak file docker dasar ieu pikeun Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Sareng pikeun Apache JMeter ieu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Anjeun tiasa maca kumaha sistem integrasi kontinyu urang jalanna dina tulisan "".
Citakan jeung pipa
Conto template pikeun ngalaksanakeun tés beban sayogi dina proyék éta . The Anjeun tiasa maca parentah pikeun ngagunakeun citakan. Dina template sorangan (file ) aya catetan ngeunaan naon tanggung jawab unggal hambalan.
Témplatna saderhana pisan sareng nunjukkeun tilu tahapan tés beban anu dijelaskeun dina diagram di luhur: nyiapkeun, nguji, sareng nyebarkeun laporan. Tanggung jawab ieu : Nyiapkeun, Test jeung Laporan.
- Panggung kudu dipaké pikeun preconfigure target test atawa pariksa kasadiaan maranéhanana. Lingkungan pikeun sumber beban henteu kedah dikonpigurasikeun, aranjeunna tos diwangun salaku gambar docker sareng dipasang dina pendaptaran docker: ngan tangtukeun versi anu dipikahoyong dina tahap Test. Tapi anjeun tiasa ngawangun deui sareng ngadamel gambar anu dirobih nyalira.
- Panggung dipaké pikeun nangtukeun sumber beban, ngajalankeun tés, sarta nyimpen artefak tés. Anjeun tiasa milih mana wae sumber beban: Yandex.Tank, Apache JMeter, anjeun sorangan, atanapi sadayana babarengan. Pikeun nganonaktipkeun sumber anu teu dipikabutuh, ngan ukur mairan atanapi ngahapus padamelan éta. Titik asup pikeun sumber beban:
- Parameter peluncuran pikeun Yandex.Tank dieusian dina .,
- Parameter ngamimitian Apache JMeter dieusian dina file .
Catetan: Citakan konfigurasi assembly dipaké pikeun nyetél interaksi jeung sistem CI na teu imply panempatan logika test di dinya. Pikeun tés, titik éntri dieusian, dimana aya skrip bash kontrol. Metodeu ngajalankeun tés, ngahasilkeun laporan, sareng skrip tés sorangan kedah dilaksanakeun ku insinyur QA. Dina demo, pikeun duanana sumber beban, pamundut halaman utama Yandex dianggo salaku tés pangbasajanna. Skrip sareng parameter uji aya dina diréktori .
- Dina panggung Anjeun kudu ngajelaskeun kumaha carana nyebarkeun hasil tés diala dina tahap Test ka panyimpenan éksternal, contona, ka GitLab Kaca atawa sistem ngalaporkeun husus. GitLab Pages meryogikeun yén diréktori ./public janten non-kosong sareng ngandung sahenteuna file index.html saatos tés réngsé. Anjeun tiasa maca ngeunaan nuansa jasa GitLab Pages. .
Conto cara ngékspor data:
- ti JMeter ka ,
- ti Yandex.Tank ka .
Pitunjuk pangaturan masang:
- HTML statik dina ,
- ka InfluxDB lajeng ka .
Dina conto demo, jalur pipa sareng tés beban sareng dua sumber beban (anjeun tiasa nganonaktipkeun anu teu perlu) sapertos kieu:
Apache JMeter tiasa ngahasilkeun laporan HTML sorangan, janten langkung nguntungkeun pikeun nyimpen dina GitLab Pages nganggo alat standar. Ieu kumaha laporan Apache JMeter sapertos kieu:
Dina conto demo pikeun Yandex.Tank, anjeun ngan bakal ningali dina bagian pikeun GitLab Pages. Salila tés, Tank tiasa nyimpen hasil kana database InfluxDB, sareng ti dinya aranjeunna tiasa ditampilkeun, contona, dina Grafana (konfigurasi dilakukeun dina file. ). Ieu kumaha laporan Tank di Grafana:
singgetan
Dina tulisan éta, kuring nyarioskeun konsép "uji beban salaku jasa" (uji beban salaku jasa). Gagasan utama nyaéta ngagunakeun infrastruktur pools agén beban anu tos dikonpigurasikeun, gambar docker sumber beban, sistem ngalaporkeun sareng pipa anu ngagabungkeun aranjeunna dina GitLab CI dumasar kana template .gitlab-ci.yml basajan (conto. ). Sadaya ieu dirojong ku tim leutik insinyur automation sareng ditiru dina pamundut tim produk. Abdi ngarepkeun ieu bakal ngabantosan anjeun dina nyiapkeun sareng ngalaksanakeun skéma anu sami di perusahaan anjeun. Hatur nuhun kana perhatosanana!
PS Abdi hoyong ngucapkeun hatur nuhun badag ka kolega kuring, Sergey Kurbanov jeung Nikolai Yusev, pikeun bantuan teknis jeung palaksanaan konsép nguji beban salaku layanan di parusahaan urang.
nu ngarang: - Timbalan Kepala Téknologi sareng Proses Pangembangan (DevOps) di Positive Technologies
sumber: www.habr.com