Unu di i prublemi chì i venditori di software multi-prodottu spessu affruntà hè a duplicazione di e cumpetenze di l'ingegneri - sviluppatori, testatori è amministratori di l'infrastruttura - in quasi ogni squadra. Questu hè ancu applicà à ingegneri caru - specialisti in u campu di teste di carica.
Invece di fà e so funzioni dirette è di utilizà a so sperienza unica per custruisce un prucessu di prova di carica, sceglite una metodulugia, metriche ottimali è scrive autotest in cunfurmità cù i profili di carica, l'ingegneri spessu anu da implementà l'infrastruttura di prova da zero, cunfigurà l'arnesi di carica, è incrustà. stessi in i sistemi CI, stabiliscenu u monitoraghju è a publicazione di rapporti.
Pudete truvà suluzioni à certi prublemi di l'urganisazione in teste chì usemu in Tecnologie Positive in . È in questu, parleraghju di a pussibilità di integrà e teste di carica in un pipeline CI cumuni utilizendu u cuncettu di "test di carica cum'è serviziu" (test di carica cum'è serviziu). Ampararete cumu è quale l'imaghjini docker di e fonti di carica pò esse usatu in u pipeline CI; cumu cunnette e fonti di carica à u vostru prughjettu CI utilizendu un mudellu di creazione; ciò chì u pipeline demo pare per eseguisce e teste di carica è publicà i risultati. L'articulu pò esse utile per ingegneri di teste di software è ingegneri d'automatizazione in CI chì pensanu à l'architettura di u so sistema di carica.
L'essenza di u cuncettu
U cuncettu di teste di carica cum'è serviziu implica a capacità di integrà l'arnesi di carica Apache JMeter, Yandex.Tank è i vostri propri frameworks in un sistema di integrazione cuntinuu arbitrariu. A demo serà per GitLab CI, ma i principii sò cumuni à tutti i sistemi CI.
A prova di carica cum'è serviziu hè un serviziu centralizatu per a prova di carica. I testi di carica sò eseguiti in pool di agenti dedicati, i risultati sò publicati automaticamente in Pagine GitLab, Influx DB è Grafana o in sistemi di rapportu di teste (TestRail, ReportPortal, etc.). L'automatizazione è a scala sò implementate cum'è simpliciamente pussibule - aghjustendu è parametrizendu u solitu mudellu gitlab-ci.yml in u prughjettu GitLab CI.
U vantaghju di questu approcciu hè chì l'intera infrastruttura CI, l'agenti di carica, l'imaghjini docker di e fonti di carica, i pipeline di teste è i rapporti di pubblicazione sò mantinuti da un dipartimentu d'automatizazione centralizatu (ingegneri DevOps), mentre chì l'ingegneri di teste di carica ponu concentrà i so sforzi in u sviluppu di teste. è l'analisi di i so risultati, senza trattà di prublemi di infrastruttura.
Per a simplicità di descrizzione, assumeremu chì l'applicazione di destinazione o u servitore in prova hè digià stata implementata è cunfigurata in anticipu (scritture automatizati in Python, SaltStack, Ansible, etc. ponu esse usatu per questu). Allora u cuncettu tutale di a prova di carica cum'è serviziu si mette in trè tappe: preparazione, prova, pubblicazione di rapporti. Più dettagli nantu à u schema (tutte l'imaghjini ponu cliccà):
Cuncepzioni basi è definizione in a prova di carica
Quandu eseguite e teste di carica, pruvemu di aderisce , Aduprate a terminologia appropritata è e metriche cunsigliate. Daraghju una breve lista di i cuncetti principali è e definizioni in a prova di carica.
Agente di carica - una macchina virtuale nantu à quale l'applicazione serà lanciata - a fonte di carica (Apache JMeter, Yandex.Tank o un modulu di carica auto-scrittu).
Scopu di prova (obiettivu) - servitore o applicazione installata nantu à u servitore chì serà sottumessu à carica.
Scénario d'essai (cas d'essai) - un inseme di passi parametrizzati: l'azzioni di l'utilizatori è e reazioni previste à queste azzioni, cù richieste di rete fissa è risposte, secondu i paràmetri specificati.
Profilu o pianu di carica (profilu) - in (Section 4.2.4, p. 43) i profili di carica definiscenu metriche chì sò critichi per una prova particulare è opzioni per cambià i paràmetri di carica durante a prova. Pudete vede esempi di profili in a figura.
Testu - un script cù un settore predeterminatu di parametri.
Pianu di prova (pianu di prova) - un inseme di teste è un prufilu di carica.
Testran (testrun) - una iterazione di eseguisce una prova cù un scenariu di carica cumplettamente eseguitu è u rapportu ricevutu.
Richiesta di rete (richiesta) - Una dumanda HTTP mandata da un agente à un destinazione.
Risposta di a rete (risposta) - Una risposta HTTP mandata da u destinazione à l'agente.
Codice di risposta HTTP (statu di risposta HTTP) - codice di risposta standard da u servitore di l'applicazione.
Una transazzione hè un ciculu cumpletu di dumanda-risposta. Una transazzione hè cuntata da u principiu di mandà una dumanda (richiesta) à a fine di riceve una risposta (risposta).
Status di transazzione - s'ellu era pussibili à compie cù successu u ciclu dumanda-risposta. S'ellu ci hè statu qualchì errore in stu ciculu, allura a transazzione sana hè cunsiderata senza successu.
Tempu di risposta (latenza) - u tempu da a fine di l'inviu di una dumanda (dumanda) à u principiu di riceve una risposta (risposta).
Carica metrica - e caratteristiche di u serviziu caricatu è l'agente di carica determinate in u prucessu di prova di carica.
Metriche basiche per a misurazione di i paràmetri di carica
Alcune di i più cumunimenti utilizati è cunsigliati in a metodulugia (p. 36, 52) i metrici sò mostrati in a tavula sottu. Metri simili per l'agente è u target sò listati nantu à a stessa linea.
Metriche per l'agente di carica
Metriche di u sistema di destinazione o di l'applicazione chì sò pruvati sottu a carica
Numeru di vCPU è memoria RAM,
u discu - caratteristiche "ferru" di l'agentu di carica
CPU, Memoria, usu di discu - dinamica di CPU, memoria è carica di discu
in u prucessu di prova. Di solitu misurata cum'è percentuale di
i valori massimi dispunibili
throughput di a rete (nantu à l'agente di carica) - throughput
interfaccia di rete nantu à u servitore,
induve l'agente di carica hè stallatu.
Di solitu misurata in byte per seconda (bps)
throughput di a rete(in destinazione) - larghezza di banda di l'interfaccia di a rete
nantu à u servitore di destinazione. Di solitu misurata in byte per seconda (bps)
utilizatori virtuale- u numeru di utilizatori virtuale,
implementazione di scenarii di carica è
imitando l'azzioni di l'utilizatori reali
Status di utilizatori virtuale, Passed / Failed / Total - numeru di successu è
stati senza successu di utilizatori virtuale
per i scenarii di carica, è ancu u so numeru tutale.
In generale, hè aspittatu chì tutti l'utilizatori puderanu compie
tutte e vostre attività specificate in u prufilu di carica.
Qualchese errore significarà chì un veru utilizatore ùn puderà micca
risolve u vostru prublema quandu u travagliu cù u sistema
Richieste per seconda (minutu)- u numeru di dumande di rete per seconda (o minutu).
Una caratteristica impurtante di un agente di carica hè quante richieste pò generà.
In fatti, questu hè una imitazione di l'accessu à l'applicazione da l'utilizatori virtuale
Risposte per seconda (minutu)
- u numeru di risposti di rete per seconda (o minutu).
Una caratteristica impurtante di u serviziu di destinazione: quantu
generà è mandà risposte à e dumande cù
agente di carica
Statu di risposta HTTP- numeru di diversi codici di risposta
da u servitore di l'applicazione ricevutu da l'agente di carica.
Per esempiu, 200 OK significa una chjama successu,
è 404 - chì a risorsa ùn hè micca stata truvata
Latenza (tempu di risposta) - tempu da a fine
mandendu una dumanda (request) prima di cumincià à riceve una risposta (risposta).
Di solitu misurata in millisecondi (ms)
Tempu di risposta di a transazzione- tempu di una transazzione completa,
cumpiimentu di u ciclu dumanda-risposta.
Questu hè u tempu da u principiu di mandà a dumanda (richiesta)
finu à a fine di riceve una risposta (risposta).
U tempu di transazzione pò esse misurata in seconde (o minuti)
in parechje manere: cunzidira u minimu,
massimu, mediu è, per esempiu, u 90 percentile.
A lettura minima è massima hè estrema
u statutu di u rendiment di u sistema.
U novantesimu percentile hè u più cumunimenti utilizatu,
cum'è mostra a maiò parte di l'utilizatori,
funziunamentu cunfortu à a soglia di u rendiment di u sistema
Transazzione per seconda (minutu) - u numeru di cumpleta
transazzione per seconda (minutu),
vale à dì quantu l'applicazione hà pussutu accettà è
processà e dumande è emette risposte.
In fatti, questu hè u throughput di u sistema
Status di transazzione , Passatu / Fallatu / Totale - numeru
successu, senza successu è u numeru tutale di transacciones.
Per l'utilizatori veri senza successu
a transazzione veramente significarà
incapacità di travaglià cù u sistema sottu carica
Diagramma schematicu di prova di carica
U cuncettu di a prova di carica hè assai simplice è si compone di trè tappe principali, chì aghju digià citatu: Preparate-Test-Report, vale à dì, a preparazione di scopi di teste è a paràmetri di e fonti di carica, poi eseguisce e teste di carica è, à a fine, generà è pubblicà un rapportu di prova.
Note schematiche:
- QA.Tester hè un espertu in teste di carica,
- Target hè l'applicazione di destinazione per quale vulete sapè u so cumpurtamentu sottu carica.
Classificatore di entità, tappe è passi in u diagramma
Tappe è passi
Ciò chì accade
Chì ci hè à l'entrata
Chì ghjè l'output
Preparate: tappa di preparazione per a prova
LoadParameters
Impostazione è inizializazione
utilizatore
paràmetri di carica,
scelta di metrica è
preparazione di u pianu di prova
(carricà u prufilu)
Opzioni persunalizati per
l'inizializazione di l'agentu di carica
Pianu di prova
U scopu di a prova
VM
Impiegazione in nuvola
macchina virtuale cun
caratteristiche richieste
Paràmetri di VM per l'agente di carica
Scripts d'automatizazione per
Creazione di VM
VM cunfigurata in
nuvulu
Mandate
Configurazione è preparazione OS
ambiente per
travagliu di l'agente di carica
Paràmetri di l'ambiente per
agente di carica
Scripts d'automatizazione per
paràmetri ambientali
Ambiente preparatu:
OS, servizii è applicazioni,
necessariu per u travagliu
agente di carica
Agenti di carica
Installazione, cunfigurazione è parametrizzazione
agente di carica.
O scaricate una maghjina docker da
fonte di carica preconfigurata
Caricà l'imaghjini docker source
(YAT, JM o quadru auto-scrittu)
Settings
agente di carica
Installa è pronta
per travaglià l'agente di carica
Test : tappa di esecuzione di teste di carica. I fonti sò agenti di carica implementati in pools di agenti dedicati per GitLab CI
Load
Cumincià l'agente di carica
cù u pianu di prova sceltu
è i paràmetri di carica
Opzioni d'utilizatori
per l'inizializazione
agente di carica
Pianu di prova
U scopu di a prova
I registri di esecuzione
prove di carica
Logs di u sistema
Dinamica di cambiamenti in metrica di u scopu è agente di carica
Run Agents
Esecuzione di l'agente
un saccu di script di prova
in cunfurmità cù
prufilu di carica
L'interazione di l'agente di carica
à u scopu di pruvà
Pianu di prova
U scopu di a prova
FIRMA
Raccolta di logs "crudi".
durante a prova di carica:
carica i registri di l'attività di l'agente,
statu di u scopu di prova
è a VM chì esegue l'agente
I registri di esecuzione
prove di carica
Logs di u sistema
Metrics
Raccolta di metrica "cruda" durante a prova
Dinamica di cambiamenti in metrica di u scopu
è agenti di carica
Rapportu: tappa di preparazione di u rapportu di prova
Generator
Trattamentu cullatu
sistema di carica è
sistema di surviglianza "cru"
metriche è logs
Formazione di un rapportu in
forma leggibile umana
pussibule cù elementi
analisti
I registri di esecuzione
prove di carica
Logs di u sistema
Dinamica di cambiamenti in metrica
destinazione è agente di carica
Logs "crudi" processati
in un formatu adattatu per
carica à u almacenamentu esternu
Rapportu di carica statica,
leggibile da l'omu
Publicate
Publicazione di u rapportu
circa a carica
prova in esterni
u serviziu
Travagliatu "cru"
logs in un formatu adattatu
per u scaricamentu à l'esterno
repositorii
Salvatu in esterni
rapporti di almacenamentu nantu à
carica, adattatu
per l'analisi umana
Cunnettendu i Load Sources in un Template CI
Passemu à a parte pratica. Vogliu dimustrà cumu nantu à certi prughjetti in a cumpagnia avemu implementatu u cuncettu di teste di carica cum'è serviziu.
Prima, cù l'aiutu di i nostri ingegneri DevOps, avemu creatu un gruppu di agenti dedicatu in GitLab CI per eseguisce teste di carica. Per ùn cunfundirli in mudelli cù l'altri, cum'è e piscine di assemblea, avemu aghjustatu tag à questi agenti, : carica. Pudete utilizà qualsiasi altre tag comprensibile. Si dumandanu GitLab CI Runners.
Cumu truvà a putenza necessaria per hardware? E caratteristiche di l'agenti di carica - un numeru abbastanza di vCPU, RAM è Disk - pò esse calculatu basatu annantu à u fattu chì Docker, Python (per Yandex.Tank), GitLab CI agent, Java (per Apache JMeter) deve esse in esecuzione nantu à l'agente. . Per Java sottu JMeter, hè ancu cunsigliatu di utilizà un minimu di 512 MB di RAM è, cum'è un limitu superiore, .
Cusì, basatu annantu à a nostra sperienza, ricumandemu di utilizà almenu 4 vCPU, 4 GB RAM, 60 GB SSD per l'agenti di carica. U throughput di a carta di rete hè determinatu basatu annantu à i requisiti di u prufilu di carica.
Utilizemu principalmente duie fonti di carica - Apache JMeter è Yandex.Tank docker images.
hè un strumentu open source da Yandex per a prova di carica. A so architettura modulare hè basatu annantu à u generatore di richieste HTTP asincrone asincrone d'altu rendiment di Phantom. U cisterna hà un monitoraghju integratu di e risorse di u servitore in prova via u protokollu SSH, pò piantà automaticamente a prova in cundizioni specificate, ponu vede i risultati sia in a cunsola sia in forma di grafici, pudete cunnette i vostri moduli. per espansione e funziunalità. Per via, avemu usatu u Tank quandu ùn era ancu mainstream. In l'articulu "» pudete leghje a storia di cumu avemu fattu a prova di carica cun ellu in 2013 hè unu di i prudutti di a nostra cumpagnia.
hè un strumentu di teste di carica open source da Apache. Pò esse usatu ugualmente bè per pruvà l'applicazioni web statiche è dinamiche. JMeter supporta un gran numaru di protokolli è modi per interagisce cù l'applicazioni: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) è IMAP (S), basa di dati via JDBC, ponu eseguisce cumandamenti di shell è travaglià cù oggetti Java. JMeter hà un IDE per creà, debugging è eseguisce piani di prova. Ci hè ancu una CLI per l'operazione di linea di cumanda in qualsiasi sistema operatore compatible Java (Linux, Windows, Mac OS X). L'uttellu pò generà dinamicamente un rapportu di teste HTML.
Per facilità d'utilizazione in a nostra cumpagnia, per a capacità di i testatori stessi di cambià è aghjunghje l'ambiente, avemu fattu custruzzioni di l'imaghjini docker di fonti di carica in GitLab CI cù publicazione à l'internu. . Questu rende più veloce è più faciule per cunnette in pipeline per teste di carica. Cumu fà docker push à u registru via GitLab CI - vede .
Avemu pigliatu stu schedariu docker di basa per Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]È per Apache JMeter questu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Pudete leghje cumu funziona u nostru sistema di integrazione cuntinuu in l'articulu "».
Template è pipeline
Un esempiu di un mudellu per a realizazione di teste di carica hè dispunibule in u prugettu . L' Pudete leghje l'istruzzioni per aduprà u mudellu. In u mudellu stessu (file ) Ci sò note nantu à ciò chì ogni passu hè rispunsevule.
U mudellu hè assai simplice è mostra e trè fasi di teste di carica descritte in u diagramma sopra: preparazione, teste è publicità di rapporti. Rispunsevuli di questu : Preparate, Testate è Reportate.
- Stage deve esse usatu per preconfigurate i miri di teste o verificate a so dispunibilità. L'ambiente per e fonti di carica ùn hè micca bisognu di cunfigurazione, sò pre-custruiti cum'è imaghjini di docker è publicati in u registru docker: basta à specificà a versione desiderata in a fase di Test. Ma pudete ricustruisce è fà e vostre propiu imagine mudificate.
- Stage utilizatu per specificà a fonte di carica, eseguite e teste è almacenà l'artefatti di prova. Pudete sceglie qualsiasi fonte di carica: Yandex.Tank, Apache JMeter, u vostru propiu, o tutti inseme. Per disattivà e fonti inutili, basta à cumentà o sguassate u travagliu. Punti d'entrata per e fonti di carica:
- I paràmetri di lanciamentu per Yandex.Tank sò specificati in u .,
- I paràmetri di startup di Apache JMeter sò specificati in u schedariu .
Nota: U mudellu di cunfigurazione di l'assemblea hè utilizatu per stabilisce l'interazzione cù u sistema CI è ùn implica micca a piazzamentu di a logica di prova in questu. Per i testi, u puntu di entrata hè specificatu, induve si trova u script bash di cuntrollu. U metudu di eseguisce e teste, generà rapporti, è i script di teste stessu deve esse implementatu da ingegneri QA. In a demo, per e duie fonti di carica, a dumanda di a pagina principale di Yandex hè usata cum'è a prova più simplice. I scripts è i paràmetri di teste sò in u cartulare .
- À u palcuscenicu avete bisognu di discrive cumu pubblicà i risultati di a prova ottenuti in a fase di Test à i magazzini esterni, per esempiu, à Pagine GitLab o sistemi di rapportu speciale. GitLab Pages richiede chì u cartulare ./public ùn sia micca viotu è cuntene almenu un schedariu index.html dopu chì i testi anu finitu. Pudete leghje nantu à i sfumaturi di u serviziu di Pagine GitLab. .
Esempii di cumu esportà dati:
- da JMeter à ,
- da Yandex.Tank à .
Istruzzioni di stallazione di pubblicazione:
- Statistiche HTML in ,
- à InfluxDB è dopu à .
In l'esempiu demo, u pipeline cù teste di carica è duie fonti di carica (pudete disattivà l'innecessariu) pare cusì:
Apache JMeter pò generà un rapportu HTML stessu, per quessa, hè più prufittu di salvà in GitLab Pages utilizendu strumenti standard. Eccu cumu si vede u rapportu Apache JMeter:
In l'esempiu demo per Yandex.Tank, vi vede solu in a sezione per e Pagine GitLab. Durante a prova, u Tank pò salvà i risultati à a basa di dati InfluxDB, è da quì ponu esse visualizati, per esempiu, in Grafana (a cunfigurazione hè fatta in u schedariu ). Eccu cumu si vede u rapportu di Tank in Grafana:
Resumen
In l'articulu, aghju parlatu di u cuncettu di "prova di carica cum'è serviziu" (test di carica cum'è serviziu). L'idea principale hè di utilizà l'infrastruttura di pools pre-configurati di agenti di carica, imagine docker di fonti di carica, sistemi di rapportu è un pipeline chì li combina in GitLab CI basatu annantu à un mudellu simplice .gitlab-ci.yml (esempiu). ). Tuttu chistu hè sustinutu da una piccula squadra di ingegneri d'automatizazione è riplicatu à a dumanda di squadre di produttu. Spergu chì questu vi aiuterà à preparà è implementà un schema simili in a vostra cumpagnia. Grazie per l'attenzione!
PS Vogliu dì un grande ringraziu à i mo culleghi, Sergey Kurbanov è Nikolai Yusev, per l'assistenza tecnica cù l'implementazione di u cuncettu di teste di carica cum'è serviziu in a nostra cumpagnia.
auturi: - Diputatu Capu di Tecnulugie è Processi di Sviluppu (DevOps) in Tecnologie Positive
Source: www.habr.com