L’aplicació Apache JMeter™ és un programari de codi obert, una aplicació 100% pura Java dissenyada per provar el comportament funcional i mesurar el rendiment.
Apache JMeter pot ser utilitzat per provar el rendiment tant de recursos estàtics com dinàmics, aplicacions web dinàmiques. Pot ser utilitzat per simular una càrrega elevada sobre un servidor, grup de servidors, xarxa o objecte per provar la seva resistència o per analitzar el rendiment global sota diferents tipus de càrrega.
Les característiques d’Apache JMeter inclouen:
Capacitat de càrrega i prova de rendiment de diferents tipus d’aplicacions/servidors/protocols: Web, SOAP, FTP…
IDE de prova complet que permet una gravació ràpida del pla de prova (des dels navegadors o aplicacions natives), construcció i depuració.
Mode CLI (Mode de línia de comandes (anteriorment anomenat No GUI) / mode sense cap) per fer proves de càrrega des de qualsevol sistema operatiu compatible amb Java (Linux, Windows, Mac OSX, …).
Un informe HTML dinàmic complet i llest per presentar.
Fàcil correlació a través de la capacitat d’extreure dades dels formats de resposta més populars, HTML, JSON, XML o qualsevol format textual.
Portabilitat completa i 100% puresa Java.
Marc multithreading complet que permet un mostreig concurrent per molts fils i un mostreig simultani de diferents funcions per grups de fils separats.
Emmagatzematge en memòria caché i anàlisi/reproducció fora de línia dels resultats de les proves.
Nucli altament extensible:
Els mostrejadors connectables permeten capacitats de prova il·limitades.
Mostrejadors scriptables (llenguatges compatibles amb JSR223 com Groovy i BeanShell)
Es poden triar diverses estadístiques de càrrega amb temporitzadors connectables.
Els connectors d’anàlisi i visualització de dades permeten una gran extensibilitat així com una personalització.
Les funcions poden ser utilitzades per proporcionar una entrada dinàmica a una prova o proporcionar una manipulació de dades.
Integració contínua fàcil a través de biblioteques Open Source de tercers per a Maven, Gradle i Jenkins1.
Comprovar que la versió de java i de JDK estan correctament instal·lades
Execució de Jmeter des de l'arxiu jmeter.bat
Navega en la direcció de l'arxiu jmter.bat (C:\apache-jmeter-5.6.2\bin\jmter.bat) descarregat anteriorment i executa l'arxiu.
S'obren la consola i JMeter:
Atenció al missatge mostrat per consola: “Modify current env variableHEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m" in the jmeter batch file”.
Per defecte, el JMeter s'executa amb un munt d'1 GB, això pot no ser suficient per a la vostra prova i depèn del vostre pla de prova i del nombre de fils que voleu executar.
Si és necessari, pots modificar aquests valors en les variables d'entorn.
També pots canviar directament l'arxiu jmter.bat, obrint-ho amb un editor de text.
Execució de Jmeter des la consola (CLI/Mode Sense GUI)
Obre la consola i executa l'arxiu ApacheJMeter.jar amb la instrucció:
Un pla de prova descriu una sèrie de passos que JMeter executarà quan s’executi. Un pla de prova complet constarà d’un o més grups de fils, controladors lògics, controladors generadors de mostres, oients, temporitzadors, afirmacions i elements de configuració.
Existeix una extensió de Chrome que permet gravar les accions en el navegador per a poder exportar-les a JMeter.
En l'exemple d'aquesta guia no es va utilitzar aquest mètode.
Thread Groups (Grups de fils)
Són els punts d’inici de qualsevol pla de prova. Tots els controladors i mostrejadors han d’estar sota un grup de fils. Són els nombre d’usuaris que voleu simular, amb quina freqüència els usuaris han d’enviar peticions i quantes peticions han d’enviar. Els controls d’un grup de fils us permeten establir:
El nombre de fils (Number of Threads): Cada fil executarà el pla de prova en la seva totalitat i completament independentment dels altres fils de prova. Es fan servir múltiples fils per simular connexions concurrents a la vostra aplicació de servidor.
El període d’increment (Ramp Up): indica a JMeter quant de temps (en segonds) ha de trigar a “incrementar” fins al nombre complet de fils escollits.
Per example, si s’utilitzen 10 fils i el període d’increment és de 100 segons, llavors JMeter trigarà 100 segons a posar en marxa tots els 10 fils. Cada fil començarà 10 (100/10) segons després que el fil anterior hagi començat. Si hi ha 30 fils i un període d’increment de 120 segons, llavors cada fil successiu es retardarà 4 segons.
L’increment ha de ser prou llarg per evitar una càrrega de treball massa gran a l’inici d’una prova, i prou curt perquè els últims fils comencin a funcionar abans que els primers acabin (a menys que es vulgui que passi això).
El nombre de vegades que s’executarà la prova (Loop count). També es pot establir com a infinit
La durada (Duration): el temps (en segons) de durada de cada grup de fils. Significa que després que s'hagi complert el temps de duració especificat, tots els fils rebran un senyal de "apagat":
Tots els fils s'inicien dins del període de Ramp Up.
Una vegada iniciats, els fils comencen a executar els Samplers de dalt a baix (o segons els Controladors Lògics).
Els fils executaran els Samplers tantes vegades com hagis definit en "Loops". Quand:
No hi ha més Samplers per executar.
No hi ha més loops per iterar.
S'excedeix la Duració.
Els fils s'apagaran.
Per a afegir els thread groups:
Clic dret sobre Test Pla > Add > Thread (Users) > Thread Group
Aquests paràmetres es poden indicar directament en JMeter (GUI) o parametritzar-los per consola. Més endavant (apartat 4 i 5) s'explica com cobrir estàs propietats dels nombre de fils.
HTTP Request Defaults
En aquesta secció, especificareu els paràmetres per defecte per a les vostres sol·licituds HTTP.
Indica el protocol i el parámetro per la URL. Aquest paràmetre (URL) serà indicat més endavant (veure apartat 4 i 5)
HTTP Cookie Manager
Això assegurarà que cada fil tingui les seves pròpies cookies.
HTTP Request
Afegeix totes les HTTP Request necessàries per al teu Test Plan. Per exemple, en aquest cas n’afegirem dues.
Són components que mostren els resultats de les mostres. Els resultats es poden mostrar en un arbre, taules, gràfics o simplement escrits en un fitxer de registre.
Aquests són alguns exemples de Listeners:
Graph Results
Assertion Results
Simple Data Writer
Aggregate Graph
Mailer Visualizer
BeanShell Listener
Summary Report
View Results Tree
Aggregate Report
View Results in Table
Cadascun d’aquests “Listeners” mostra la informació de resposta de diferents maneres.
Execució del Test Pla per consola
Aquests són els passos a seguir:
Declarar les propietats necessaris en l'aplicació de JMeter (nombre de fils, Ramp Up, Durada, IP…).
Preparar el directori on es guardaran els resultats.
Execució del Test per consola.
Anàlisi de resultats.
Declaració de les propietats en JMeter
Les propietats a JMeter són comunes a tots els fils i s’han de referenciar utilitzant la funció ${__P(prop)}. Això significa que estan disponibles en tots els fils i, a diferència de les variables, les propietats estan específicament vinculades a objectes. Les propietats representen valors als quals pots accedir. Tenen un abast “global”.
Dins dels Grups de Fils (Thread Group):
Nombre de fils (Number of Threads): ${__P(threadCount)}
Període d’increment(Ramp Up): ${__P(rampup)}
Durada (Duration): ${__P(testDuration)}
Dins de la petició HTTP pre defecte (HTTP Request Defaults):
Protocol: ${__P(protocol)}
Nom del servidor o IP: ${__P(url)}
Dins de la primera petició HTTP que navega per la web https://qualitat.solucions.gencat.cat/ es pot indicar com a recomanaci en el nom de la petició les propietats declarades anteriorment per a indicar en la resposta amb quins paràmetres s'està executant:
Dins de la segona petició HTTP que navega per la web https://qualitat.solucions.gencat.cat/qualitygates també es pot indicar en el nom de la petició les propietats declarades anteriorment per a indicar en la resposta amb quins paràmetres s'està executant.
A més, es delcara la path: ${__P(url2)}
Per a l'execució per consola no és necessari afegir listeners.
Preparar el directori on es guardaran els resultats
Es pot indicar per consola el lloc i el format en el qual guardar els resultats obetinidos de l'execució del test pla.
S'utilitzarà el comando “-l” (logfile) que permet guardar els resultats en .csv o .jtl.
Amb els comandos “-e” (reportatendofloadtests) i “-o” (reportoutputfolder) es guardaran els resultats en en un Dashboard html en una carpeta anteriorment creada. Aquesta carpeta pot ser creada per consola abans de l'execució de JMeter o manualment.
Crear les carpetes on s'arxivaran els resultats resultats:
Execució del Test per consola.
Per a executar el test pla creat en JMeter , cal situar-se en el directori on es trobi l'arxiu jmter.bat.
En aquest exemple, la ruta del jmter.bat és: C:\apache-jmeter-5.6.2\bin
Una vegada situats en la ruta del .bat, s'executa la següent instrucció:
Amb aquesta part executem JMeter i l'arxiu .jmx el per consola.
-l C:\Users\...\TestPlanCTTI\
ResultatsTestPlanCTTIBasic\Logs\Resultats.jtl
Amb aquesta part guardem els resultats en un arxiu .jtl (també es poden guardar en format .csv).
*L’arxiu .jtl no existeix en la carpeta (abans d'executar).
-e -o C:\Users\...\CTTI\TestPlanCTTI\
ResultatsTestPlanCTTIBasic\HTML
Oracle JDK 6, Oracle JDK 7
Anàlisi de resultats.
Apache JMeter Dashboard
Obrir l'arxiu index.html dins de C:\Users\...\CTTI\TestPlanCTTI\ResultatsTestPlanCTTIBasic\HTML
Dashboard
Dins de la pestanya de “Dashboard” es pot veure un resum del temps d'execució del Test pla juntament amb la taula de APDEX.
APDEX és un estàndard que mesura el rendiment de les aplicacions.
La fórmula és la següent:
APDEX = 1: Totes les transaccions són satisfactòries per als usuaris. Excel·lent rendiment.
0.7 ≤ APDEX < 1: La majoria de les transaccions són satisfactòries o tolerables. Bon rendiment.
0.5 ≤ APDEX < 0.7: La majoria de les transaccions són tolerables o frustrants. Rendiment acceptable però pot haver-hi àrees de millora.
APDEX < 0.5: La majoria de les transaccions són frustrants. Rendiment deficient i necessita millores urgents.
APDEX es basa en el temps de resposta de les peticions HTTP i es classifica en tres categories: satisfetes, tolerades i frustrades.
Una petició satisfeta: té un temps de resposta menor que un llindar anomenat Toleration Threshold.
Una petició tolerada: té un temps de resposta major que el Toleration Threshold però menor que el Frustration Threshold.
Una petició frustrada: té un temps de resposta major que el Frustration Threshold.
APDEX és la mitjana ponderada de les peticions satisfetes i tolerades, sent les primeres el doble d’importants que les segones.
També es mostra la taula d'Estadístiques.
Està composta per la següents columnes:
Etiqueta (Label): mostra l’etiqueta o nom de la sol·licitud o transacció que s’està provant.
Mostra (Samples): indica el nombre total de mostres o sol·licituds que es van realitzar per a l’etiqueta corresponent durant la prova. En aquest exemple, com que es van establir 5 fils amb Loop infinit durant 60 segons, es mostra un total de 3042 mostres a cada prova. Això significa que el procés es va repetir durant aproximadament 608 vegades (3042/5).
% d’Errors (Error %): mostra el percentatge de mostres que van resultar en errors o fallades durant la prova. Els errors poden incloure respostes amb codis d’estat HTTP diferents de 2xx (èxit).
Mitjana (Average): mostra el temps mitjà (en mil·lisegons) que va prendre completar la sol·licitud o transacció.
Mínim (Min): mostra el temps de resposta mínim registrat per a l’etiqueta durant la prova.
Màxim (Max): el temps de resposta màxim registrat per a l’etiqueta durant la prova.
Mediana (Median): és el valor mitjà de tots els temps de resposta de la mostra. Si tens una gran variabilitat en els temps de resposta, la mediana pot ser una mètrica més representativa que la mitjana.
Línia del 90% (90% Line): indica el temps de resposta que el 90% de les mostres van aconseguir o millorar. En altres paraules, el 90% de les mostres van tenir un temps de resposta igual o inferior a aquest valor. El mateix per a 95% i 99%.
Rendiment (Throughput): la quantitat mitjana de sol·licituds per minut que es van realitzar per a l’etiqueta durant la prova. Aquesta mètrica indica la capacitat de rendiment del sistema sota càrrega.
KB rebuts per segon (Received KB/sec): indica la taxa mitjana de transferència de dades rebudes per segon durant la prova.
Charts
Dins de la pestanya de “Charts” es poden veure diversos gràfics com per exemple Temps de resposta al llarg del temps (Response Times Over Time).
Aquesta gràfica representa de manera visual el comportament de l'aplicació sota càrrega. Permet identificar les tendències i problemes de rendiment.
La gràfica Temps de resposta percentual al llarg del temps (respostes reeixides) (Response Time"C:\apache-jmeter-5.6.2\bin>java -jar ApacheJMeter.jar Percentiles Over Time (successful responses)) mostra el temps que va prendre processar les sol·licituds exitoses al llarg de la prova per als diferents percentils. Mostra com es distribueixen els temps de resposta de les sol·licituds exitoses durant l’execució de la prova.
La gràfica de Resum del temps de resposta (Response Time Overview) mostra una visió general dels temps de resposta de les sol·licituds durant l'execució de la prova.
Aquesta gràfica mostra el temps de resposta de totes les sol·licituds (Data), el temps de resposta mitjà (Average), la mediana del temps de resposta (Median), la desviació en el temps de resposta (Deviation) i el nombre de mostres per minut (throughput).
Cada punt en la gràfica és una mitjana del que ha ocorregut durant aquest interval de mostra.
La gràfica Temps vs Fils (Time Vs Threads) mostra com varia el nombre de fils (usuaris virtuals) concurrents al llarg del temps durant l’execució d’una prova de càrrega. Aquesta gràfica és útil per observar com es distribueix la càrrega d’usuaris durant la prova i si es produeixen pics de càrrega en moments específics.
Eix X (Temps): representa el temps transcorregut durant l’execució de la prova, des de l’inici fins a la finalització. Generalment, es representa en segons o minuts, depenent de la durada de la teva prova.
Eix Y (Nombre de Fils): representa el nombre de fils (usuaris virtuals) concurrents que estan sent utilitzats en un moment específic en el temps.
Les sèries que acaben en "-aggregated" representen el temps de resposta mitjà independentment del nombre de fils actius actuals. Mostren el temps de resposta mitjà per a totes les sol·licituds, sense tenir en compte quants fils estaven actius en aquell moment.
Arxiu .jtl
Aquest arxiu conté tots els detalls i resultats de cada una de les peticions, transaccions o etiquetes que haguem definit en el script de JMeterLa informació que es pot trobar en aquest arxiu inclou:
Temps de resposta.
Codi d’estat HTTP.
Missatges d’error.
Altres detalls de les sol·licituds i respostes.
Execució del Test Pla per l’aplicació de JMeter.
Aquests són els passos a seguir:
Obrir l'aplicació de JMeter.
Declarar les propietats necessaris en l'aplicació de JMeter (nombre de fils, Ramp Up, Durada, IP…).
Execució del Test per l’aplicació.
Anàlisi de resultats.
Obrir l'aplicació de JMeter.
Per a obrir l'aplicació de JMeter cal seguir els passos indicats en l'apartat 2.1.1.
Navega en la direcció de l'arxiu jmter.bat (C:\apache-jmeter-5.6.2\bin\jmter.bat) i executa l'arxiu. Navega en la direcció de l'arxiu jmter.bat (C:\apache-jmeter-5.6.2\bin\jmter.bat) descarregat anteriorment i executa l'arxiu.
Obrir el projecte amb el test pla que es vulgui executar.
Declarar les propietats necessaris en l'aplicació de JMeter (nombre de fils, Ramp Up, Durada, IP…).
Asginar valors als paràmetres de Thread Groups (Grups de fils).
Indicar l'adreça IP principal i el protocol.
No és necessari afegir res en la primera sol·licitud HTTP:
Indicar la següent URL en la segona sol·licitud d'HTTP.
Finalment és necessari afegir els Listeners necessaris per a veure els resultats de l'execució.
En aquest cas, s'afegeixen:
Graph Results.
Summary Report.
View Results Tree.
View Results in Table.
Perquè les dades es bolquin en Grafana, caldria afegir un altre Listener (veure apartat “7.2.3.”)
Execució del Test.
Per a executar el test pla, clic en la icona de Start:
Anàlisi de resultats.
El listener de Informe Resum (Summary Report). Mostra un resultat similar a l'obtingut en la taula d'estadístiques (apartat 4.4.1.1).
El listener de Visualitza l'arbre de resultats (View Results Tree) mostra les mostres que generen els samplers de JMeter i els resultats de les assercions relacionades amb aquestes mostres.
El listener Visualitza els resultats a la taula (View Reults in Table) mostra informació sobre cada mostra. Mostra dades relacionades amb el temps per a cada mostra, les dades de la càrrega útil, el nombre de fils i el resultat de l’execució de la mostra. Els resultats a la taula estan en l’ordre en què es van emetre les mostres de temps.
El listener Resultats del gràfic (Graph Results) traça una gràfica entre el temps de resposta en mil·lisegons i el temps transcorregut. Les línies de la gràfica mostren el temps de resposta de totes les sol·licituds (Data), el temps de resposta mitjà (Average), la mediana del temps de resposta (Median), la desviació en el temps de resposta (Deviation) i el nombre de mostres per minut (throughput). Cada punt en la gràfica és una mitjana del que ha ocorregut durant aquest interval de mostra.
Execució del Test Pla per consola (manant els paràmetres des d'un fitxer extern).
Aquests són els passos a seguir:
Declarar les propietats necessaris en l'aplicació de JMeter (nombre de fils, període d’increment, durada, IP…) (igual que en apartat 4.1).
Preparar l'arxiu de .properties on s'inclouen els paràmetres d'entrada (nombre de fils, període d’increment, durada, IP…).
Preparar el directori on es guardaran els resultats (igual que en apartat 4.2).
Execució del Test per consola.
Anàlisi de resultats (igual que en apartat 4.4).
Declaració de les propietats en JMeter
Igual que en apartat 4.1 es declaren les propietats necessàries per al test.
Preparar l'arxiu de .properties on s'inclouen els paràmetres d'entrada
Navega pel directori de C:\apache-jmeter-5.6.2\bin\user.properties.
Obre l'arxiu i afegeix les propietats necessàries per a l'execució del test.
Amb aquesta part guardem els resultats en un arhivo .jtl (també es poden guardar en format .csv).
*L’arxiu .jtl no existeix en la carpeta (abans d'executar).
-e -o C:\Users\...\CTTI\TestPlanCTTI\
ResultatsTestPlanCTTIwoREAD\HTML
Amb aquesta part guardem els resultats de l'HTML en una carpeta
C:\apache-jmeter-5.6.2\bin\user.properties
Amb aquesta part executem l'arxiu de user.properties on declarem les propietats
Anàlisi de resultats.
Igual que en l'apartat 4.4, en el directori de resultats, es troba un .html amb el Apache JMeter Dashboard i l'arxiu .jtl.
Apache JMeter Dashboard
Obrir l'arxiu index.html dins de C:\Users\...\TestPlanCTTI\ResultatsTestPlanCTTIwoREAD\HTML
Arxiu .jtl
Obrir l'arxiu index.html dins de C:\Users\...\TestPlanCTTI\ResultatsTestPlanCTTIwoREAD\Logs\ResultatsWprop.jtl
Utilització de recursos
JMeter, com a aplicació desenvolupada en Java, utilitza sobretot memòria RAM i CPU. La quantitat exacta depèn de la complexitat i el volum de les nostres proves. Tenint en compte algunes orientacions generals:
Memòria RAM: Pot consumir una gran quantitat de memòria, especialment si estàs processant una gran quantitat de dades o si estàs utilitzant molts fils (usuaris virtuals).
CPU: És intensiu en l'ús de la CPU, especialment si utilitzant molts fils . Cada fil és un usuari virtual (vUser), de manera que si estem simulant molts usuaris, JMeter necessitarà més CPU.
Espai en disc: Generalment, JMeter no necessita gaire espai en disc, llevat que estiguis guardant resultats de proves grans o realitzant proves durant un llarg període de temps.
Xarxa: JMeter pot consumir una quantitat significativa d'ancho de banda de xarxa, especialment si estàs realitzant proves de càrrega en una aplicació web.
Per tant, és important monitoritzar el consum de recursos mentre s'executen les proves per assegurar-se que JMeter té els recursos que necessita per funcionar correctament.
Per tal de determinar quins son els recursos necessaris, hem estressat els sistemes que componen les proves de rendiment al nostre framework MAT.
Partint de la base que l'ús de solucions actuals al CTTI son unes 300 execucions/mensuals, hem determinat que hem de per les proves sobre capacitat de la plataforma, hem determinat que necessitem com a minim dos casos d'usos.
Hauriem d'executar 10 proves concurrents d'una carrega mitjana per exemple 200 vUsers (10 proves · 200 vUsers/prova = 2000 vUsers) i determinar com es comporta el MAT.
Al fer aquesta prova, veiem que el Jenkins genera agents virtuals, la carrega per les 10 proves, son máxims de 6 vCores i 14 GB de memòria, com a referencia, el cluster base de laboratori compta amb 12 vCores (51% d'utilització) i 36 GB de memoria (53%). Es balanceja correctament i escala a nivell de cluster Kubernetes.
Execució de 10 proves de 200 vUsers/prova
Creació de agents de Jenkins, dos lots de 10 proves.
Hauríem d'executar menys proves concurrents, per exemple 3, però amb carregues altes d'usuaris, per exemple, 3000 vUsers per prova (3 proves · 3000 vUsers = 9000 vUsers).
L’instancia 10.0.1.61 es crea degut a la carrega de treball, provocant que es redueixin les carregues de treball, permeten injectar més carrega.
Creació de agents de Jenkins, dos lots de proves, una amb 5 proves i un altre amb 3 proves
Al fer aquesta prova, veiem que el Jenkins genera agents virtuals, la carrega per les 3 proves, son màxims de 1 vCores i 8 GB de memòria, però com les proves les executem contra una aplicació del clúster, es aquesta aplicació la que provoca que es generi una 4ª instancia al clúster, fent que la carrega de treball es balanceja i escali a nivell de clúster i a nivell d’autoescalat de la totalitat del clúster.
En cap de les proves, la base de dades influx no ha rebut carrega que generi cap coll d’ampolla.
Amb la capacitat actual del laboratori sense cap escalat es podrien executar 20 proves concurrents de navegació web.
Exemple Proves Rendiment
En aquest apartat s'explica com realitzar una prova de rendiment completa (bolcant els resultats a Grafana).
Aquest és el arxiu de JMeter on es dissenya el test.
user.properties
Aquest és un arxiu de text on es defineixen les propietats necessàries per a executar el test (nombre de fils, rampup, durada, url...).
devcontainer
Imatge del contenidor on s'executarà el codi.
README
Aquest arxiu conté informació sobre altres arxius en un directori. És una forma de documentació de programari, usualment en un arxiu de text pla en format TXT, o MD.
TestPlanCTTI.jmx
Est l'arxiu generat a través de l'aplicació de JMeter.
L'arxiu jmx està compost pel següent:
HTTP Request Defaults: on s'indica la url d'inici.
HTTP Cookie Manager: on es gestiona el netejat de cookies.
Tests:
Test positiu: navegar per la url de www.qualitat.solucions.gencat.cat
Test negatiu: navegar per una url invàlida
Listeners
User Defined Variables: per a definir la variablede bucket (necessària per a Influx)
Per a crear un test, s'han de seguir els passos explciados en l'apartat en l'apartat 3. Exemple de creació d'un Test Pla Básic. Cadascuna dels elements de la plantilla està explicat en aquest apartat.
ThreadGroup
S'inicialitza cada paràmetre amb la funció de “${__P(nameParameter)}”.
Aquest paràmetre serà després declarat en el moment de l'execució (veure 4. Execució del Test Pla per consola).
HTTP Cookie Manager
Test positiu: navegar per la url de www.qualitat.solucions.gencat.cat
En aquest test n'hi ha prou amb indicar la petició de tipus GET. La url està definida en HTTP Request Default.
Per a verificar un text en la web que s'està provant, s'utilitza l'element Response Assertion.
El Listener Assertion Results, es mostra el resultat del pas anterior.
També es pot incloure una validació en funció del temps necessari per a cada mostra. Per a això, és necessari incorporar l'element de BeanShell Assertion.
En aquest element s'inclou un codi Java que consisteix a registrar el temps transcorregut per a cada mostra. En cas que el temps transcorregut sigui major al permès, es mostrarà un missatge d'error.
Les variables de SLA_elapsedTime_threshold, SLA_elapsedTime_failures i SLA_elapsedTime_maxErrors es defineixen en User Defined Variables.
Test negatiu: navegar per una url invàlida
Per a forçar una fallada en la prova, s'indicarà una url en al Path que sigui invàlida.
Els missatges d'error que es registrin a raiz d'aquest codi de BeanShell Assertion o de Assertion Results, seran després visibles en els Reportis de resultats (tant en Grafana com en l'HTML).
debug();
//Variables - Time & Errors
SLA_elapsedTime_threshold: temps máx permès per a cada mostra (millisegons)
SLA_elapsedTime_failures: nombre de mostres fallades
SLA_elapsedTime_maxErrors: màxim d'errors permesos
//Temps transcorregut en la mostra (millisegons)
long elapsed = SampleResult.getTime();
//Temps máx permès per a cada mostra
long threshold = Long.parseLong(vars.get("SLA_elapsedTime_threshold"));
if (elapsed > threshold) {
int failureCount = Integer.parseInt(vars.get("SLA_elapsedTime_failures"));
failureCount++;
int maxErrors = Integer.parseInt(vars.get("SLA_elapsedTime_maxErrors"));
if (failureCount >= maxErrors) {
Failure = true;
FailureMessage = "failureCount:" + " requests failed to finish in " + threshold + " ms";
SampleResult.setSuccessful(false);
} else {
vars.put("SLA_elapsedTime_failures", String.valueOf(failureCount));
}
SampleResult.setResponseMessage("duration: " + elapsed + "; failureCount= " + failureCount);
}
Exemple de resultat en Grafan
Exemple de resultat en HTML
Listeners
Són els elements que mostres els resultats de les proves.
Veure l'apartat “5.4. Anàlisi de resultats” per a veure la informació dels listeners:
View Results Tree.
Summary Report.
View Results in Table.
Graph Results.
El listener de Backend Listener és l'encarregat de bolcar les dades a Influx i a Grafana (Veure 7.2.3. JMeter).
Nom
Valor
Declaració
influxdbUrl
Url de influx juntament amb els paràmetres d'Organització i Bucket
Execució per consola (Veure 4.3.)
Jenkins.
Arxiu user.properties (caldria adaptar el user properties, ja que la plantilla està preparada per a executar solament per consola o jenkins).
application
Inclou el Project Key de Jira i l'entorn de prova. Aquest paràmetres serà el que es reflecteixi posteriorment en Grafana.
eventTags
Entorn de prova
influxdbToken
Creat automàticament a l'hora de configurar Influx (apartat 7.1.1)
testTitle
Títol de la prova
Arxiu user.properties (aquest paràmetre no és obligatori. Si es mana buit, JMeter posa un títol per defecte).
User Defined Variables
En aquest element es poden incloure totes les variables necessàries per a l'execució. En aquest cas, bucket, per al correcte bolcat a Influx.
Nom
Valor
Declaració
bucket
Bucket definit en apartart 7.2.1. Influx DB.
Execució per consola (Veure 4.3.)
Jenkins.
Arxiu user.properties (caldria adaptar el user.properties, ja que la plantilla està preparada per a executar solament per consola o Jenkins).
user.properties
En aquest arxiu ve per defecte en la instal·lació de JMeter, localitzat dins de C:\...\apache-jmeter-5.6.2\bin\user.properties
És un arxiu de text on es defineixen les variables de url, protocol, durada...
Amb aquesta part guardem els resultats en un arhivo .jtl (també es poden guardar en format .csv). *L’arxiu .jtl no existeix en la carpeta (abans d'executar).
L'ordre en el qual es mana cadascuna de les instruccions en l'execució influeixen a l'hora de llegir els paràmetres.
Exemple
En cas que es dupliqui un paràmetre i es mani tant per Consola com per l'arxiu de user.properties, el test usarà el que tingui preferència.
El paràmetre de threadCount s'inclou per error en l'arxiu user.properties i també en l'execució per consola amb el comando -J.
CAS 1: es mana primer llegir l'arxiu properties i depués els comandos amb -J.
Resultat: El test es realitzarà amb els paràmetres que llegeix en últim lloc (és a dir, els paràmetres manats per consola). Per tant, ignorarà l'arxiu de user.properties.
CAS 2: es mana primer llegir els comandos amb comando -J i depués l'arxiu de user.properties.
Resultat: El test es realitzarà amb els paràmetres que llegeix en últim lloc (és a dir, els paràmetres manats en l'arxiu de user.properties). Per tant, ignorarà els comandos de -J
En el cas que un dels paràmetres (threadCount) solament es mana en l'arxiu de user.properties i no en consola.
CAS 3: es mana primer llegir l'arxiu properties i depués els comandos amb -J,
esultat: El test es realitzarà amb els paràmetres que llegeix en últim lloc (és a dir, els paràmetres manats per consola), excepte el threadCount, que només ho troba en l'arxiu de user.properties
