Ang isa sa mga problema na madalas na kinakaharap ng mga vendor ng software ng maraming produkto ay ang pagdoble ng mga kakayahan ng mga inhinyero - mga developer, tester, at mga administrator ng imprastraktura - sa halos bawat koponan. Nalalapat din ito sa mga mamahaling inhinyero - mga espesyalista sa larangan ng pagsubok sa pagkarga.
Sa halip na gawin ang kanilang mga direktang tungkulin at gamitin ang kanilang natatanging karanasan upang bumuo ng proseso ng pagsubok sa pagkarga, pumili ng isang pamamaraan, pinakamainam na sukatan at magsulat ng mga autotest alinsunod sa mga profile ng pagkarga, kadalasang kailangang i-deploy ng mga inhinyero ang imprastraktura ng pagsubok mula sa simula, i-configure ang mga tool sa pagkarga, at i-embed ang mga ito ang kanilang mga sarili sa mga sistema ng CI, nag-set up ng pagsubaybay at paglalathala ng mga ulat.
Makakahanap ka ng mga solusyon sa ilang problema sa organisasyon sa pagsubok na ginagamit namin sa Positive Technologies sa . At sa isang ito, magsasalita ako tungkol sa posibilidad ng pagsasama ng mga pagsubok sa pagkarga sa isang karaniwang pipeline ng CI gamit ang konsepto ng "pagsusuri ng pagkarga bilang isang serbisyo" (pagsusuri ng pagkarga bilang isang serbisyo). Malalaman mo kung paano at aling mga docker na larawan ng mga pinagmumulan ng pagkarga ang maaaring gamitin sa pipeline ng CI; kung paano ikonekta ang mga mapagkukunan ng pag-load sa iyong proyekto sa CI gamit ang isang build template; kung ano ang hitsura ng demo pipeline para sa pagpapatakbo ng mga pagsubok sa pag-load at pag-publish ng mga resulta. Maaaring maging kapaki-pakinabang ang artikulo para sa mga software testing engineer at automation engineer sa CI na nag-iisip tungkol sa arkitektura ng kanilang load system.
Ang kakanyahan ng konsepto
Ang konsepto ng pagsubok sa pag-load bilang isang serbisyo ay nagpapahiwatig ng kakayahang pagsamahin ang mga tool sa pagkarga Apache JMeter, Yandex.Tank at ang iyong sariling mga balangkas sa isang arbitrary na tuluy-tuloy na sistema ng pagsasama. Ang demo ay para sa GitLab CI, ngunit ang mga prinsipyo ay karaniwan sa lahat ng CI system.
Ang pagsubok sa pag-load bilang isang serbisyo ay isang sentralisadong serbisyo para sa pagsubok sa pagkarga. Ang mga pagsubok sa pag-load ay pinapatakbo sa mga nakalaang pool ng ahente, ang mga resulta ay awtomatikong nai-publish sa Mga Pahina ng GitLab, Influx DB at Grafana o sa mga sistema ng pag-uulat ng pagsubok (TestRail, ReportPortal, atbp.). Ang automation at scaling ay ipinapatupad nang simple hangga't maaari - sa pamamagitan ng pagdaragdag at pag-parameter sa karaniwang template ng gitlab-ci.yml sa proyekto ng GitLab CI.
Ang bentahe ng diskarteng ito ay ang buong imprastraktura ng CI, mga ahente ng pag-load, mga larawan ng docker ng mga mapagkukunan ng pag-load, mga pipeline ng pagsubok, at mga ulat sa pag-publish ay pinapanatili ng isang sentralisadong departamento ng automation (mga inhinyero ng DevOps), habang ang mga inhinyero sa pagsubok ng pagkarga ay maaaring ituon ang kanilang mga pagsisikap sa pagbuo ng pagsubok. at pagsusuri ng kanilang mga resulta, nang hindi nakikitungo sa mga isyu sa imprastraktura.
Para sa pagiging simple ng paglalarawan, ipagpalagay namin na ang target na application o server na nasa ilalim ng pagsubok ay nai-deploy na at na-configure nang maaga (maaaring gamitin ang mga awtomatikong script sa Python, SaltStack, Ansible, atbp. para dito). Pagkatapos ang buong konsepto ng pagsubok sa pag-load bilang isang serbisyo ay umaangkop sa tatlong yugto: paghahanda, pagsubok, paglalathala ng mga ulat. Higit pang mga detalye sa diagram (lahat ng mga larawan ay naki-click):
Mga pangunahing konsepto at kahulugan sa pagsubok ng pagkarga
Kapag nagsasagawa ng mga pagsubok sa pagkarga, sinusubukan naming sumunod , gamitin ang naaangkop na terminolohiya at inirerekomendang sukatan. Magbibigay ako ng maikling listahan ng mga pangunahing konsepto at kahulugan sa pagsubok ng pagkarga.
Mag-load ng ahente - isang virtual machine kung saan ilulunsad ang application - ang pinagmulan ng pagkarga (Apache JMeter, Yandex.Tank o isang self-written load module).
Layunin ng pagsubok (target) - server o application na naka-install sa server na sasailalim sa load.
Sitwasyon sa pagsubok (test case) - isang hanay ng mga naka-parameter na hakbang: mga aksyon ng user at inaasahang reaksyon sa mga pagkilos na ito, na may mga nakapirming kahilingan at tugon sa network, depende sa tinukoy na mga parameter.
Profile o load plan (profile) - sa (Seksyon 4.2.4, p. 43) ang mga profile ng pag-load ay tumutukoy sa mga sukatan na kritikal para sa isang partikular na pagsubok at mga opsyon para sa pagbabago ng mga parameter ng pagkarga sa panahon ng pagsubok. Maaari mong makita ang mga halimbawa ng mga profile sa figure.
Pagsusulit β isang script na may paunang natukoy na hanay ng mga parameter.
Plano ng pagsubok (test-plan) - isang set ng mga pagsubok at isang load profile.
Testran (testrun) - isang pag-ulit ng pagpapatakbo ng isang pagsubok na may ganap na naisakatuparan na senaryo ng pagkarga at ang natanggap na ulat.
Kahilingan sa network (kahilingan) β Isang kahilingan sa HTTP na ipinadala mula sa isang ahente patungo sa isang target.
Tugon sa network (tugon) β Isang tugon ng HTTP na ipinadala mula sa target patungo sa ahente.
HTTP response code (HTTP responses status) - karaniwang response code mula sa application server.
Ang isang transaksyon ay isang kumpletong ikot ng kahilingan-tugon. Ang isang transaksyon ay binibilang mula sa simula ng pagpapadala ng kahilingan (kahilingan) hanggang sa pagkumpleto ng pagtanggap ng tugon (tugon).
Katayuan ng transaksyon - kung posible bang matagumpay na makumpleto ang ikot ng kahilingan-tugon. Kung mayroong anumang error sa cycle na ito, ituturing na hindi matagumpay ang buong transaksyon.
Oras ng pagtugon (latency) - ang oras mula sa pagtatapos ng pagpapadala ng kahilingan (kahilingan) hanggang sa simula ng pagtanggap ng tugon (tugon).
I-load ang mga sukatan β ang mga katangian ng load service at ang load agent na tinutukoy sa proseso ng load testing.
Mga pangunahing sukatan para sa pagsukat ng mga parameter ng pagkarga
Ilan sa mga pinakakaraniwang ginagamit at inirerekomenda sa pamamaraan (p. 36, 52) ang mga sukatan ay ipinapakita sa talahanayan sa ibaba. Ang mga katulad na sukatan para sa ahente at target ay nakalista sa parehong linya.
Mga sukatan para sa ahente ng pagkarga
Mga sukatan ng target na system o application na sinusuri sa ilalim ng pagkarga
Numero vCPU at memorya RAM,
Disko - "bakal" na mga katangian ng ahente ng pagkarga
CPU, Memorya, paggamit ng disk - dinamika ng CPU, memorya at paglo-load ng disk
sa proseso ng pagsubok. Karaniwang sinusukat bilang isang porsyento ng
maximum na magagamit na mga halaga
throughput ng network (sa ahente ng pagkarga) - throughput
interface ng network sa server,
kung saan naka-install ang load agent.
Karaniwang sinusukat sa bytes per second (bps)
throughput ng network(sa target) - bandwidth ng interface ng network
sa target na server. Karaniwang sinusukat sa bytes per second (bps)
Mga virtual na gumagamit- ang bilang ng mga virtual na gumagamit,
pagpapatupad ng mga senaryo ng pagkarga at
ginagaya ang mga totoong aksyon ng user
Katayuan ng mga virtual na user, Pumasa/Nabigo/Kabuuan β bilang ng matagumpay at
hindi matagumpay na mga katayuan ng mga virtual na gumagamit
para sa mga sitwasyon ng pag-load, pati na rin ang kanilang kabuuang bilang.
Karaniwang inaasahan na ang lahat ng mga gumagamit ay nakumpleto
lahat ng iyong mga gawain na tinukoy sa profile ng pag-load.
Ang anumang error ay nangangahulugan na ang isang tunay na gumagamit ay hindi magagawa
lutasin ang iyong problema kapag nagtatrabaho sa system
Mga kahilingan kada segundo (minuto)- ang bilang ng mga kahilingan sa network bawat segundo (o minuto).
Ang isang mahalagang katangian ng isang ahente ng pagkarga ay kung gaano karaming mga kahilingan ang mabubuo nito.
Sa katunayan, ito ay isang imitasyon ng pag-access sa application ng mga virtual na gumagamit
Mga tugon kada segundo (minuto)
- ang bilang ng mga tugon sa network bawat segundo (o minuto).
Isang mahalagang katangian ng target na serbisyo: magkano
bumuo at magpadala ng mga tugon sa mga query na may
ahente ng paglo-load
Status ng tugon ng HTTPβ bilang ng iba't ibang mga response code
mula sa application server na natanggap ng load agent.
Halimbawa, ang 200 OK ay nangangahulugang isang matagumpay na tawag,
at 404 - na hindi natagpuan ang mapagkukunan
Latency (oras ng pagtugon) - oras mula sa katapusan
pagpapadala ng kahilingan (request) bago magsimulang makatanggap ng tugon (response).
Karaniwang sinusukat sa millisecond (ms)
Oras ng pagtugon sa transaksyonβ oras ng isang buong transaksyon,
pagkumpleto ng ikot ng kahilingan-tugon.
Ito ang oras mula sa simula ng pagpapadala ng kahilingan (kahilingan)
hanggang sa makumpleto ang pagtanggap ng tugon (tugon).
Maaaring masukat ang oras ng transaksyon sa mga segundo (o minuto)
sa maraming paraan: isaalang-alang ang pinakamababa,
maximum, average at, halimbawa, ang 90th percentile.
Ang minimum at maximum na pagbabasa ay sukdulan
katayuan ng pagganap ng system.
Ang siyamnapung porsyento ay ang pinakakaraniwang ginagamit,
tulad ng ipinapakita nito sa karamihan ng mga gumagamit,
kumportableng tumatakbo sa threshold ng pagganap ng system
Mga transaksyon kada segundo (minuto) - ang bilang ng kumpleto
mga transaksyon kada segundo (minuto),
ibig sabihin, magkano ang nagawang tanggapin ng aplikasyon at
mga kahilingan sa proseso at mga tugon sa isyu.
Sa katunayan, ito ang throughput ng system
Katayuan ng transaksyon , Pumasa / Nabigo / Kabuuan - numero
matagumpay, hindi matagumpay at ang kabuuang bilang ng mga transaksyon.
Para sa mga tunay na user na hindi matagumpay
ang transaksyon ay talagang ibig sabihin
kawalan ng kakayahan upang gumana sa sistema sa ilalim ng pagkarga
I-load ang Pagsusulit ng Schematic Diagram
Ang konsepto ng pagsubok sa pag-load ay napaka-simple at binubuo ng tatlong pangunahing yugto, na nabanggit ko na: Maghanda-Pagsusulit-Ulat, iyon ay, paghahanda ng mga layunin sa pagsubok at pagtatakda ng mga parameter para sa mga mapagkukunan ng pag-load, pagkatapos ay pagsasagawa ng mga pagsubok sa pag-load at, sa dulo, pagbuo at pag-publish ng isang pagsubok na ulat.
Mga tala ng eskematiko:
- Ang QA.Tester ay isang dalubhasa sa pagsubok sa pagkarga,
- Ang target ay ang target na application kung saan gusto mong malaman ang pag-uugali nito sa ilalim ng pag-load.
Classifier ng mga entity, yugto at hakbang sa diagram
Mga yugto at hakbang
Anong nangyayari
Ano ang nasa pasukan
Ano ang output
Maghanda: yugto ng paghahanda para sa pagsubok
Mga LoadParameter
Pagtatakda at pagsisimula
gumagamit
mga parameter ng pag-load,
pagpili ng mga sukatan at
paghahanda ng plano sa pagsubok
(load profile)
Mga custom na opsyon para sa
pagsisimula ng ahente ng pagkarga
Plano ng pagsubok
Layunin ng pagsubok
VM
Pag-deploy ng ulap
virtual machine na may
kinakailangang katangian
Mga setting ng VM para sa load agent
Automation script para sa
Paglikha ng VM
Naka-configure ang VM
ang ulap
Sinabi ni Env
Pag-setup at paghahanda ng OS
kapaligiran para sa
trabaho ng load agent
Mga setting ng kapaligiran para sa
ahente ng pagkarga
Automation script para sa
mga setting ng kapaligiran
Inihanda na kapaligiran:
OS, mga serbisyo at application,
kailangan para sa trabaho
ahente ng pagkarga
LoadAgents
Pag-install, pagsasaayos at parameterization
ahente ng paglo-load.
O nagda-download ng larawan ng docker mula sa
paunang na-configure na pinagmulan ng pag-load
I-load ang source docker image
(YAT, JM o self-written framework)
Mga setting
ahente ng pagkarga
I-set up at handa na
sa trabaho load agent
Pagsubok: yugto ng pagpapatupad ng mga pagsubok sa pagkarga. Ang mga source ay mga load agent na naka-deploy sa mga nakalaang agent pool para sa GitLab CI
Load
Pagsisimula ng Load Agent
na may napiling plano sa pagsubok
at mga parameter ng pag-load
Mga Pagpipilian sa Gumagamit
para sa initialization
ahente ng pagkarga
Plano ng pagsubok
Layunin ng pagsubok
Mga tala ng pagpapatupad
mga pagsubok sa pagkarga
Mga log ng system
Dynamics ng mga pagbabago sa mga sukatan ng layunin at ahente ng pagkarga
Patakbuhin ang mga Ahente
Pagpapatupad ng Ahente
maraming test script
alinsunod sa
i-load ang profile
Pakikipag-ugnayan ng Load Agent
para sa layunin ng pagsubok
Plano ng pagsubok
Layunin ng pagsubok
Mga tala
Koleksyon ng mga "raw" na log
sa panahon ng pagsubok sa pagkarga:
mga talaan ng aktibidad ng ahente ng pag-load,
estado ng target ng pagsubok
at ang VM ang nagpapatakbo ng ahente
Mga tala ng pagpapatupad
mga pagsubok sa pagkarga
Mga log ng system
Mga Sukatan
Pagkolekta ng "raw" na sukatan sa panahon ng pagsubok
Dynamics ng mga pagbabago sa mga sukatan ng layunin
at ahente ng pagkarga
Ulat: yugto ng paghahanda ng ulat ng pagsusulit
Generator
Nakolekta ang pagproseso
sistema ng paglo-load at
sistema ng pagsubaybay "raw"
mga sukatan at talaan
Pagbuo ng ulat sa
nababasang anyo ng tao
posible sa mga elemento
analista
Mga tala ng pagpapatupad
mga pagsubok sa pagkarga
Mga log ng system
Dynamics ng mga pagbabago sa mga sukatan
target at load agent
Mga naprosesong "raw" na log
sa isang format na angkop para sa
mga pag-upload sa panlabas na imbakan
Static load na ulat,
nababasa ng tao
Maglathala
Paglalathala ng ulat
tungkol sa load
pagsubok sa panlabas
serbisyo
Naproseso na "raw"
mga log sa isang angkop na format
para sa pagbabawas sa panlabas
mga repositoryo
Naka-save sa panlabas
mga ulat sa imbakan sa
load, angkop
para sa pagsusuri ng tao
Pagkonekta ng mga mapagkukunan ng pag-load sa template ng CI
Lumipat tayo sa praktikal na bahagi. Gusto kong ipakita kung paano sa ilang mga proyekto sa kumpanya ipinatupad namin ang konsepto ng load testing bilang isang serbisyo.
Una, sa tulong ng aming mga inhinyero ng DevOps, gumawa kami ng nakalaang grupo ng mga ahente sa GitLab CI para magpatakbo ng mga pagsubok sa pagkarga. Upang hindi malito ang mga ito sa mga template sa iba, tulad ng mga assembly pool, nagdagdag kami ng mga tag sa mga ahente na ito, : load. Maaari kang gumamit ng anumang iba pang naiintindihan na mga tag. Tanong nila Mga Runner ng GitLab CI.
Paano malalaman ang kinakailangang kapangyarihan sa pamamagitan ng hardware? Ang mga katangian ng mga ahente ng pag-load - isang sapat na bilang ng vCPU, RAM at Disk - ay maaaring kalkulahin batay sa katotohanan na ang Docker, Python (para sa Yandex.Tank), ahente ng GitLab CI, Java (para sa Apache JMeter) ay dapat na tumatakbo sa ahente . Para sa Java sa ilalim ng JMeter, inirerekomenda rin na gumamit ng minimum na 512 MB ng RAM at, bilang pinakamataas na limitasyon, .
Kaya, batay sa aming karanasan, inirerekomenda namin ang paggamit ng hindi bababa sa 4 na vCPU, 4 GB RAM, 60 GB SSD para sa mga ahente ng pagkarga. Ang throughput ng network card ay tinutukoy batay sa mga kinakailangan ng load profile.
Pangunahing ginagamit namin ang dalawang pinagmumulan ng pag-load - mga imahe ng Apache JMeter at Yandex.Tank docker.
ay isang open source tool mula sa Yandex para sa pagsubok sa pagkarga. Ang modular na arkitektura nito ay batay sa high-performance na asynchronous na hit-based na HTTP request generator ng Phantom. Ang tangke ay may built-in na pagsubaybay sa mga mapagkukunan ng server sa ilalim ng pagsubok sa pamamagitan ng SSH protocol, maaaring awtomatikong ihinto ang pagsubok sa ilalim ng tinukoy na mga kondisyon, maaaring ipakita ang mga resulta pareho sa console at sa anyo ng mga graph, maaari mong ikonekta ang iyong mga module dito upang mapalawak ang pag-andar. Siyanga pala, ginamit namin ang Tank noong hindi pa ito mainstream. Sa artikulong "Β» mababasa mo ang kuwento kung paano namin isinagawa ang pagsubok sa pag-load dito noong 2013 ay isa sa mga produkto ng aming kumpanya.
ay isang open source load testing tool mula sa Apache. Maaari itong magamit nang pantay-pantay para sa pagsubok ng parehong static at dynamic na mga web application. Sinusuportahan ng JMeter ang isang malaking bilang ng mga protocol at mga paraan upang makipag-ugnayan sa mga application: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, atbp.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) at IMAP(S), mga database sa pamamagitan ng JDBC, ay maaaring magsagawa ng mga utos ng shell at gumana sa mga bagay ng Java. Ang JMeter ay may IDE para sa paggawa, pag-debug at pagsasagawa ng mga plano sa pagsubok. Mayroon ding CLI para sa pagpapatakbo ng command line sa anumang Java compatible na operating system (Linux, Windows, Mac OS X). Ang tool ay maaaring dynamic na bumuo ng isang HTML test report.
Para sa kadalian ng paggamit sa loob ng aming kumpanya, para sa kakayahan ng mga tester mismo na baguhin at idagdag ang kapaligiran, gumawa kami ng mga build ng mga docker na larawan ng mga source ng load sa GitLab CI na may publikasyon sa internal . Ginagawa nitong mas mabilis at mas madaling ikonekta ang mga ito sa mga pipeline para sa mga pagsubok sa pagkarga. Paano gawin ang docker push sa pagpapatala sa pamamagitan ng GitLab CI - tingnan .
Kinuha namin ang pangunahing docker file na ito para sa Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]At para sa Apache JMeter ang isang ito:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Mababasa mo kung paano gumagana ang aming tuluy-tuloy na sistema ng pagsasama sa artikulong "'.
Template at pipeline
Ang isang halimbawa ng isang template para sa pagsasagawa ng mga pagsubok sa pagkarga ay magagamit sa proyekto . Sa Maaari mong basahin ang mga tagubilin para sa paggamit ng template. Sa mismong template (file ) may mga tala tungkol sa kung ano ang responsibilidad ng bawat hakbang.
Napakasimple ng template at ipinapakita ang tatlong yugto ng pagsubok sa pagkarga na inilarawan sa diagram sa itaas: paghahanda, pagsubok, at pag-publish ng mga ulat. Responsable para dito : Maghanda, Subukan at Mag-ulat.
- Stage dapat gamitin upang paunang i-configure ang mga target na pagsubok o tingnan ang kanilang availability. Ang kapaligiran para sa mga mapagkukunan ng pag-load ay hindi kailangang i-configure, ang mga ito ay pre-built bilang mga imahe ng docker at nai-post sa registry ng docker: tukuyin lamang ang nais na bersyon sa yugto ng Pagsubok. Ngunit maaari mong muling buuin ang mga ito at gumawa ng sarili mong binagong mga larawan.
- Stage ginagamit upang tukuyin ang pinagmulan ng pag-load, magpatakbo ng mga pagsubok, at mag-imbak ng mga artifact ng pagsubok. Maaari kang pumili ng anumang pinagmulan ng pag-load: Yandex.Tank, Apache JMeter, sa iyo, o lahat nang magkasama. Para i-disable ang mga hindi kinakailangang source, magkomento lang o tanggalin ang trabaho. Mga entry point para sa mga source ng load:
- Ang mga parameter ng paglunsad para sa Yandex.Tank ay tinukoy sa .,
- Ang mga parameter ng pagsisimula ng Apache JMeter ay tinukoy sa file .
Tandaan: Ang template ng configuration ng assembly ay ginagamit upang i-set up ang pakikipag-ugnayan sa CI system at hindi nagpapahiwatig ng paglalagay ng pansubok na logic dito. Para sa mga pagsubok, tinukoy ang entry point, kung saan matatagpuan ang control bash script. Ang paraan ng pagpapatakbo ng mga pagsubok, pagbuo ng mga ulat, at ang mga script ng pagsubok mismo ay dapat ipatupad ng mga inhinyero ng QA. Sa demo, para sa parehong mga mapagkukunan ng pag-load, ang kahilingan sa pangunahing pahina ng Yandex ay ginagamit bilang ang pinakasimpleng pagsubok. Ang mga script at mga parameter ng pagsubok ay nasa direktoryo .
- Sa entablado kailangan mong ilarawan kung paano i-publish ang mga resulta ng pagsubok na nakuha sa yugto ng Pagsubok sa mga panlabas na imbakan, halimbawa, sa Mga Pahina ng GitLab o mga espesyal na sistema ng pag-uulat. Kinakailangan ng Mga Pahina ng GitLab na ang ./public na direktoryo ay hindi walang laman at naglalaman ng kahit man lang isang index.html file pagkatapos ng mga pagsubok. Maaari mong basahin ang tungkol sa mga nuances ng serbisyo ng GitLab Pages. .
Mga halimbawa ng kung paano mag-export ng data:
- mula sa JMeter hanggang ,
- mula sa Yandex.Tank hanggang .
Pag-post ng mga tagubilin sa pag-setup:
- HTML statics sa ,
- sa InfluxDB at pagkatapos ay sa .
Sa halimbawa ng demo, ganito ang hitsura ng pipeline na may mga pagsubok sa pag-load at dalawang pinagmumulan ng pag-load (maaari mong i-disable ang hindi kailangan):
Ang Apache JMeter ay maaaring bumuo ng isang ulat sa HTML mismo, kaya mas kumikitang i-save ito sa Mga Pahina ng GitLab gamit ang mga karaniwang tool. Ganito ang hitsura ng ulat ng Apache JMeter:
Sa halimbawa ng demo para sa Yandex.Tank, makikita mo lang sa seksyon para sa Mga Pahina ng GitLab. Sa panahon ng pagsubok, maaaring i-save ng Tank ang mga resulta sa database ng InfluxDB, at mula doon ay maipapakita ang mga ito, halimbawa, sa Grafana (ginagawa ang configuration sa file ). Ganito ang hitsura ng ulat ng Tank sa Grafana:
Buod
Sa artikulo, pinag-usapan ko ang konsepto ng "pagsubok ng pag-load bilang isang serbisyo" (pagsusuri ng pag-load bilang isang serbisyo). Ang pangunahing ideya ay gamitin ang imprastraktura ng mga paunang na-configure na pool ng mga load agent, mga docker na larawan ng mga source ng load, mga sistema ng pag-uulat at isang pipeline na pinagsasama ang mga ito sa GitLab CI batay sa isang simpleng .gitlab-ci.yml na template (halimbawa ). Ang lahat ng ito ay sinusuportahan ng isang maliit na pangkat ng mga inhinyero ng automation at ginagaya sa kahilingan ng mga pangkat ng produkto. Umaasa ako na makakatulong ito sa iyo sa paghahanda at pagpapatupad ng katulad na pamamaraan sa iyong kumpanya. Salamat sa atensyon!
PS Nais kong magsabi ng isang malaking pasasalamat sa aking mga kasamahan, sina Sergey Kurbanov at Nikolai Yusev, para sa teknikal na tulong sa pagpapatupad ng konsepto ng pagsubok sa pagkarga bilang isang serbisyo sa aming kumpanya.
May-akda: - Deputy Pinuno ng Mga Teknolohiya at Mga Proseso ng Pag-unlad (DevOps) sa Positive Technologies
Pinagmulan: www.habr.com