Un dels problemes als quals s'enfronten sovint els venedors de programari multiproducte és la duplicació de les competències dels enginyers (desenvolupadors, provadors i administradors d'infraestructures) en gairebé tots els equips. Això també s'aplica als enginyers cars, especialistes en el camp de les proves de càrrega.
En lloc de fer les seves tasques directes i utilitzar la seva experiència única per crear un procés de prova de càrrega, triar una metodologia, mètriques òptimes i escriure autotests d'acord amb els perfils de càrrega, els enginyers sovint han de desplegar la infraestructura de prova des de zero, configurar eines de càrrega i incrustar-les. ells mateixos en els sistemes CI, establir el seguiment i la publicació d'informes.
Podeu trobar solucions a alguns problemes organitzatius a les proves que fem servir a Positive Technologies a . I en aquest, parlaré de la possibilitat d'integrar proves de càrrega en un pipeline CI comú utilitzant el concepte de "prova de càrrega com a servei" (prova de càrrega com a servei). Aprendràs com i quines imatges de docker de fonts de càrrega es poden utilitzar al pipeline CI; com connectar les fonts de càrrega al vostre projecte CI mitjançant una plantilla de compilació; com és el pipeline de demostració per executar proves de càrrega i publicar els resultats. L'article pot ser útil per als enginyers de proves de programari i enginyers d'automatització de CI que estan pensant en l'arquitectura del seu sistema de càrrega.
L'essència del concepte
El concepte de proves de càrrega com a servei implica la capacitat d'integrar les eines de càrrega Apache JMeter, Yandex.Tank i els vostres propis marcs en un sistema d'integració contínua arbitrari. La demostració serà per GitLab CI, però els principis són comuns a tots els sistemes CI.
La prova de càrrega com a servei és un servei centralitzat per a la prova de càrrega. Les proves de càrrega s'executen en grups d'agents dedicats, els resultats es publiquen automàticament a GitLab Pages, Influx DB i Grafana o en sistemes d'informes de proves (TestRail, ReportPortal, etc.). L'automatització i l'escalat s'implementen de la manera més senzilla possible, afegint i parametritzant la plantilla habitual gitlab-ci.yml al projecte GitLab CI.
L'avantatge d'aquest enfocament és que tota la infraestructura CI, els agents de càrrega, les imatges docker de les fonts de càrrega, les canonades de proves i els informes de publicació són mantinguts per un departament d'automatització centralitzat (enginyers DevOps), mentre que els enginyers de proves de càrrega poden centrar els seus esforços en el desenvolupament de proves. i anàlisi dels seus resultats, sense tractar els problemes d'infraestructures.
Per simplificar la descripció, assumirem que l'aplicació o el servidor objectiu que s'està provant ja s'ha desplegat i configurat per endavant (es poden utilitzar scripts automatitzats en Python, SaltStack, Ansible, etc. per a això). Aleshores, tot el concepte de proves de càrrega com a servei s'ajusta a tres etapes: preparació, prova, publicació d'informes. Més detalls sobre el diagrama (totes les imatges es poden fer clic):
Conceptes bàsics i definicions en proves de càrrega
Quan fem proves de càrrega, intentem complir-ho , utilitzeu la terminologia adequada i les mètriques recomanades. Donaré una breu llista dels conceptes i definicions principals de les proves de càrrega.
Agent de càrrega - una màquina virtual en la qual s'iniciarà l'aplicació - la font de càrrega (Apache JMeter, Yandex.Tank o un mòdul de càrrega escrit per si mateix).
Objectiu de prova (objectiu) - servidor o aplicació instal·lada al servidor que serà objecte de càrrega.
Escenari de prova (cas de prova) - un conjunt de passos parametritzats: accions de l'usuari i reaccions esperades a aquestes accions, amb peticions i respostes de xarxa fixes, en funció dels paràmetres especificats.
Perfil o pla de càrrega (perfil) - dins (Secció 4.2.4, p. 43) els perfils de càrrega defineixen mètriques que són crítiques per a una prova concreta i opcions per canviar els paràmetres de càrrega durant la prova. Podeu veure exemples de perfils a la figura.
Prova — un script amb un conjunt predeterminat de paràmetres.
Pla de prova (pla de prova) - un conjunt de proves i un perfil de càrrega.
Testran (testrun) - una iteració d'execució d'una prova amb un escenari de càrrega completament executat i l'informe rebut.
Sol·licitud de xarxa (sol·licitud) — Una sol·licitud HTTP enviada des d'un agent a un objectiu.
Resposta de xarxa (resposta) — Una resposta HTTP enviada des de l'objectiu a l'agent.
Codi de resposta HTTP (estat de respostes HTTP): codi de resposta estàndard del servidor d'aplicacions.
Una transacció és un cicle complet de sol·licitud-resposta. Una transacció es compta des de l'inici de l'enviament d'una sol·licitud (sol·licitud) fins a la finalització de la recepció d'una resposta (resposta).
Estat de la transacció - si va ser possible completar amb èxit el cicle de sol·licitud-resposta. Si hi ha hagut algun error en aquest cicle, la transacció sencera es considera que no ha tingut èxit.
Temps de resposta (latència) - el temps des del final de l'enviament d'una sol·licitud (sol·licitud) fins a l'inici de la recepció d'una resposta (resposta).
Carrega mètriques — les característiques del servei carregat i de l'agent de càrrega determinats en el procés de prova de càrrega.
Mètriques bàsiques per mesurar paràmetres de càrrega
Alguns dels més utilitzats i recomanats en la metodologia (pàg. 36, 52) les mètriques es mostren a la taula següent. A la mateixa línia es mostren mètriques similars per a l'agent i l'objectiu.
Mètriques per a l'agent de càrrega
Mètriques del sistema o aplicació objectiu que s'està provant sota càrrega
Nombre vCPU i memòria RAM,
Disc - Característiques "ferro" de l'agent de càrrega
CPU, Memòria, ús del disc - dinàmica de càrrega de CPU, memòria i disc
en procés de prova. Normalment es mesura com a percentatge de
valors màxims disponibles
rendiment de xarxa (a l'agent de càrrega) - rendiment
interfície de xarxa al servidor,
on està instal·lat l'agent de càrrega.
Normalment es mesura en bytes per segon (bps)
rendiment de xarxa(a l'objectiu) - ample de banda de la interfície de xarxa
al servidor de destinació. Normalment es mesura en bytes per segon (bps)
Usuaris virtuals- el nombre d'usuaris virtuals,
implementació d'escenaris de càrrega i
imitant les accions reals dels usuaris
Estat dels usuaris virtuals, Aprovat/Fallat/Total — nombre d'èxits i
estats no satisfactoris dels usuaris virtuals
per a escenaris de càrrega, així com el seu nombre total.
En general, s'espera que tots els usuaris hagin pogut completar
totes les vostres tasques especificades al perfil de càrrega.
Qualsevol error significarà que un usuari real no podrà fer-ho
solucioneu el vostre problema quan treballeu amb el sistema
Sol·licituds per segon (minut)- el nombre de peticions de xarxa per segon (o minut).
Una característica important d'un agent de càrrega és el nombre de peticions que pot generar.
De fet, es tracta d'una imitació de l'accés a l'aplicació per part dels usuaris virtuals
Respostes per segon (minut)
- el nombre de respostes de xarxa per segon (o minut).
Una característica important del servei objectiu: quant
generar i enviar respostes a consultes amb
agent de càrrega
Estat de resposta HTTP— nombre de codis de resposta diferents
des del servidor d'aplicacions rebut per l'agent de càrrega.
Per exemple, 200 OK significa una trucada correcta,
i 404 - que el recurs no s'ha trobat
Latència (temps de resposta) - temps des del final
enviar una petició (sol·licitud) abans de començar a rebre una resposta (resposta).
Normalment es mesura en mil·lisegons (ms)
Temps de resposta de la transacció- temps d'una transacció completa,
finalització del cicle petició-resposta.
Aquest és el temps des de l'inici de l'enviament de la sol·licitud (sol·licitud)
fins a la finalització de rebre una resposta (resposta).
El temps de transacció es pot mesurar en segons (o minuts)
de diverses maneres: considereu el mínim,
màxima, mitjana i, per exemple, el percentil 90.
Les lectures mínimes i màximes són extremes
estat de rendiment del sistema.
El percentil XNUMX és el més utilitzat,
com mostra la majoria dels usuaris,
operant còmodament al llindar del rendiment del sistema
Transaccions per segon (minut) - el nombre de completes
transaccions per segon (minut),
és a dir, quant va poder acceptar la sol·licitud i
processar les sol·licituds i emetre respostes.
De fet, aquest és el rendiment del sistema
Estat de la transacció , Aprovat / Fallat / Total - nombre
reeixit, no reeixit i el nombre total de transaccions.
Per a usuaris reals sense èxit
la transacció significarà realment
incapacitat per treballar amb el sistema sota càrrega
Diagrama esquemàtic de proves de càrrega
El concepte de prova de càrrega és molt senzill i consta de tres etapes principals, que ja he esmentat: Prepara-Informe-Prova, és a dir, preparar objectius de prova i establir paràmetres per a les fonts de càrrega, després executar proves de càrrega i, al final, generar i publicar un informe de prova.
Notes esquemàtiques:
- QA.Tester és un expert en proves de càrrega,
- Target és l'aplicació de destinació de la qual voleu conèixer el seu comportament sota càrrega.
Classificador d'entitats, etapes i passos del diagrama
Etapes i passos
Que està passant
Què hi ha a l'entrada
Quina és la sortida
Preparació: fase de preparació per a la prova
LoadParameters
Configuració i inicialització
usuari
paràmetres de càrrega,
elecció de mètriques i
preparació del pla de proves
(perfil de càrrega)
Opcions personalitzades per
inicialització de l'agent de càrrega
Pla de prova
Finalitat de la prova
VM
Desplegament al núvol
màquina virtual amb
característiques requerides
Configuració de la màquina virtual per a l'agent de càrrega
Scripts d'automatització per
Creació de VM
VM configurada a
núvol
ca.
Configuració i preparació del SO
entorn per
treball de l'agent de càrrega
Configuració d'entorn per
agent de càrrega
Scripts d'automatització per
configuració de l'entorn
Entorn preparat:
SO, serveis i aplicacions,
necessàries per treballar
agent de càrrega
Agents de càrrega
Instal·lació, configuració i parametrització
agent de càrrega.
O baixant una imatge de Docker de
font de càrrega preconfigurada
Carregueu la imatge d'acoblament d'origen
(YAT, JM o marc escrit per si mateix)
Configuració
agent de càrrega
Preparat i llest
a l'agent de càrrega de treball
Prova: fase d'execució de les proves de càrrega. Les fonts són agents de càrrega desplegats en grups d'agents dedicats per a GitLab CI
Càrrega
Inici de l'agent de càrrega
amb el pla de prova seleccionat
i paràmetres de càrrega
Opcions d'usuari
per a la inicialització
agent de càrrega
Pla de prova
Finalitat de la prova
Registres d'execució
proves de càrrega
Registres del sistema
Dinàmica de canvis en mètriques d'objectius i agent de càrrega
Executar Agents
Agent d'execució
un munt de scripts de prova
d'acord amb
perfil de càrrega
Interacció de l'agent de càrrega
amb la finalitat de provar
Pla de prova
Finalitat de la prova
Registres
Recollida de troncs "crues".
durant la prova de càrrega:
carregar registres d'activitat de l'agent,
estat de l'objectiu de la prova
i la màquina virtual que executa l'agent
Registres d'execució
proves de càrrega
Registres del sistema
Mètrica
Recollida de mètriques "crues" durant les proves
Dinàmica de canvis en mètriques d'objectius
i agent de càrrega
Informe: fase d'elaboració de l'informe de prova
Generador
Tramitació recollida
sistema de càrrega i
sistema de monitorització "en brut"
mètriques i registres
Formació d'un informe en
forma llegible per l'home
possible amb elements
analistes
Registres d'execució
proves de càrrega
Registres del sistema
Dinàmica de canvis en mètriques
objectiu i agent de càrrega
Registres "crues" processats
en un format adequat per
càrregues a l'emmagatzematge extern
Informe de càrrega estàtica,
llegible pels humans
Publicar
Publicació de l'informe
sobre la càrrega
prova en extern
servei
Processat "cru"
registres en un format adequat
per a la descàrrega a l'exterior
repositoris
Desat en extern
informes d'emmagatzematge
càrrega, adequat
per a l'anàlisi humana
Connexió de fonts de càrrega en una plantilla CI
Passem a la part pràctica. Vull mostrar com en alguns projectes de l'empresa hem implementat el concepte de proves de càrrega com a servei.
En primer lloc, amb l'ajuda dels nostres enginyers de DevOps, vam crear un grup dedicat d'agents a GitLab CI per executar proves de càrrega. Per no confondre'ls a les plantilles amb altres, com ara grups d'assemblatge, hem afegit etiquetes a aquests agents, : càrrega. Podeu utilitzar qualsevol altra etiqueta comprensible. pregunten GitLab CI Runners.
Com esbrinar la potència requerida pel maquinari? Les característiques dels agents de càrrega (un nombre suficient de vCPU, RAM i disc) es poden calcular a partir del fet que Docker, Python (per a Yandex.Tank), l'agent GitLab CI, Java (per a Apache JMeter) s'haurien d'executar a l'agent. . Per a Java amb JMeter, també es recomana utilitzar un mínim de 512 MB de RAM i, com a límit superior, .
Així, segons la nostra experiència, recomanem utilitzar almenys 4 vCPU, 4 GB de RAM, 60 GB SSD per als agents de càrrega. El rendiment de la targeta de xarxa es determina en funció dels requisits del perfil de càrrega.
Utilitzem principalment dues fonts de càrrega: les imatges d'Apache JMeter i Yandex.Tank.
és una eina de codi obert de Yandex per a proves de càrrega. La seva arquitectura modular es basa en el generador de sol·licituds HTTP aixíncron d'alt rendiment de Phantom. El dipòsit té un control integrat dels recursos del servidor que s'està provant mitjançant el protocol SSH, pot aturar automàticament la prova en condicions especificades, pot mostrar els resultats tant a la consola com en forma de gràfics, podeu connectar els vostres mòduls a ell per ampliar la funcionalitat. Per cert, vam utilitzar el tanc quan encara no era corrent. A l'article "» podeu llegir la història de com vam fer proves de càrrega amb ell el 2013 és un dels productes de la nostra empresa.
és una eina de prova de càrrega de codi obert d'Apache. Es pot utilitzar igualment bé per provar aplicacions web tant estàtiques com dinàmiques. JMeter admet una gran quantitat de protocols i maneres d'interactuar amb aplicacions: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), Serveis web SOAP / REST, FTP, TCP, LDAP, SMTP(S), POP3( S) ) i IMAP(S), bases de dades mitjançant JDBC, poden executar ordres de shell i treballar amb objectes Java. JMeter té un IDE per crear, depurar i executar plans de prova. També hi ha una CLI per operar en línia d'ordres en qualsevol sistema operatiu compatible amb Java (Linux, Windows, Mac OS X). L'eina pot generar dinàmicament un informe de prova HTML.
Per facilitar-ne l'ús dins de la nostra empresa, per la capacitat dels mateixos provadors de canviar i afegir l'entorn, vam fer compilacions d'imatges docker de fonts de càrrega a GitLab CI amb publicació a l'entorn intern. . Això fa que sigui més ràpid i fàcil connectar-los a canonades per a proves de càrrega. Com fer push de Docker al registre mitjançant GitLab CI - vegeu .
Hem agafat aquest fitxer docker bàsic per a Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]I per a Apache JMeter aquest:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Podeu llegir com funciona el nostre sistema d'integració contínua a l'article "».
Plantilla i pipeline
Un exemple de plantilla per a la realització de proves de càrrega està disponible al projecte . En Podeu llegir les instruccions per utilitzar la plantilla. A la pròpia plantilla (fitxer ) hi ha notes sobre de què és responsable cada pas.
La plantilla és molt senzilla i mostra les tres etapes de les proves de càrrega descrites al diagrama anterior: preparació, prova i publicació d'informes. Responsable d'això : Preparar, provar i informar.
- Etapa s'ha d'utilitzar per preconfigurar objectius de prova o comprovar-ne la disponibilitat. No cal configurar l'entorn per a les fonts de càrrega, ja que estan preconstruïts com a imatges de Docker i es publiquen al registre Docker: només cal que especifiqueu la versió desitjada a l'etapa de prova. Però podeu reconstruir-los i crear les vostres pròpies imatges modificades.
- Etapa s'utilitza per especificar la font de càrrega, executar proves i emmagatzemar els artefactes de prova. Podeu triar qualsevol font de càrrega: Yandex.Tank, Apache JMeter, la vostra o tots junts. Per desactivar les fonts innecessàries, només cal comentar o suprimir la feina. Punts d'entrada per a fonts de càrrega:
- Els paràmetres de llançament de Yandex.Tank s'especifiquen al fitxer .,
- Els paràmetres d'inici d'Apache JMeter s'especifiquen al fitxer .
Nota: La plantilla de configuració del conjunt s'utilitza per configurar la interacció amb el sistema CI i no implica la col·locació de la lògica de prova. Per a les proves, s'especifica el punt d'entrada, on es troba l'script de control bash. El mètode d'execució de proves, generació d'informes i els propis scripts de prova han de ser implementats pels enginyers de control de qualitat. A la demostració, per a ambdues fonts de càrrega, la sol·licitud de la pàgina principal de Yandex s'utilitza com a prova més senzilla. Els scripts i els paràmetres de prova es troben al directori .
- A l'escenari heu de descriure com publicar els resultats de la prova obtinguts en l'etapa de prova a emmagatzematges externs, per exemple, a pàgines de GitLab o sistemes d'informes especials. GitLab Pages requereix que el directori ./public no estigui buit i contingui almenys un fitxer index.html un cop finalitzades les proves. Podeu llegir sobre els matisos del servei de pàgines de GitLab. .
Exemples de com exportar dades:
- de JMeter a ,
- de Yandex.Tank a .
Instruccions de configuració de publicació:
- Estàtica HTML a ,
- a InfluxDB i després a .
A l'exemple de demostració, la canalització amb proves de càrrega i dues fonts de càrrega (podeu desactivar la innecessària) té aquest aspecte:
Apache JMeter pot generar un informe HTML per si mateix, de manera que és més rendible desar-lo a les pàgines de GitLab mitjançant eines estàndard. Així és com es veu l'informe Apache JMeter:
A l'exemple de demostració de Yandex.Tank, només ho veuràs a la secció de pàgines de GitLab. Durant les proves, el Tank pot desar els resultats a la base de dades InfluxDB, i des d'allà es poden mostrar, per exemple, a Grafana (la configuració es fa al fitxer ). Així es veu l'informe de Tank a Grafana:
Resum
A l'article, vaig parlar del concepte de "prova de càrrega com a servei" (prova de càrrega com a servei). La idea principal és utilitzar la infraestructura de grups preconfigurats d'agents de càrrega, imatges docker de fonts de càrrega, sistemes d'informes i un pipeline que els combini a GitLab CI basant-se en una plantilla simple .gitlab-ci.yml (exemple ). Tot això compta amb el suport d'un petit equip d'enginyers d'automatització i replicat a petició dels equips de producte. Espero que això us ajudi a preparar i implementar un esquema similar a la vostra empresa. Gràcies per la seva atenció!
PD Vull donar les gràcies als meus companys, Sergey Kurbanov i Nikolai Yusev, per l'assistència tècnica amb la implementació del concepte de proves de càrrega com a servei a la nostra empresa.
Autor: - Diputat Cap de Tecnologia i Processos de Desenvolupament (DevOps) de Positive Technologies
Font: www.habr.com