Taula de continguts
Descàrrega i instal·lació de la eina Analysis
Accedir a l’eina ALM LoadRunner i seguir les següents indicacions:
- Anar a: Tools -> “Donwload Standalone Aplications”
- Descarregar i executar tots els components d’instal·lació Standalone Analysis i seguir les intruccions d’instal.lació
- A l’execució del component d’instal•lació, seleccionar producte LoadRunner a la configuració d’Analysis (surt per defecte)
Generar informe d’anàlisi
Per a generar el document d’anàlisi s’han de seguir aquests passos:
A ALM LoadRunner seleccionar el menú Testing –> Test Lab i obrir el fitxer Results.zip corresponent al Test Set
- Seleccionar el Test Set.
- Download del fitxer Results.zip.
- Descomprimir el fitxer .zip i fer doble clic sobre el fitxer ‘Result.lra’ per tal d’obrir l’aplicació ALM LoadRunner Analysis
Seguint a Analysis: Seleccionar el menú Reports –> New Report…
- Al camp “Based on template” seleccionar “Customer facing (for cross session)”.
A la pestanya “General”:
- Indicar les dades de l’autor de l’informe
- Indicar el títol de l’informe
IMPORTANT: Desmarcar el check “Include Think Time” per NO incloure el temps d’espera de l’usuari en els càlculs de temps.
A la pestanya “Content”:
- A Content Items -> Executive Sumary: fer un resum executiu de la prova.
- A Content Items -> Placeholder Section - Conclusions: redactar les conclusions de la prova, indicant si els resultats han superat els criteris d’acceptació.
Prémer el botó “Generate”.
Gravar l’informe en format PDF (menú Save –> Adobe PDF File…) i incloure’l al document Informe de resultat de proves, a la secció corresponent a l’escenari que documenta l’informe.
Es pot trobar més informació sobre la configuració del LoadRunner Analysis al manual d’usuari ALM LoadRunner - Analysis User Guide.
Interpretar l’informe d’anàlisi
L’informe obtingut durant l’execució de les proves de rendiment (Executar proves de rendiment a ALM LoadRunner) conté informació detallada amb indicadors que cal avaluar i interpretar.
És important avaluar els diferents indicadors per esbrinar si podem determinar que l’aplicació està o no preparada pel seu “rollout” o posada en producció. Per exemple, l’aplicació pot donar uns temps de resposta raonables, però tenir una taxa d’error inacceptable (a un conjunt d’usuaris que se’ls retorna una pantalla d’error per indisponibilitat, tot i que d’altres no tenen problemes, …)
Seguidament es descriuen els punts a tenir en compte en la interpretació dels resultats, en referència a les seccions/apartats en que s’estructura l’informe generat des de l’eina ALM LoadRunner Analysis,. En qualsevol cas per tal de poder extreure conclusions globals, s’ha de fer una anàlisi comparativa entre els diferents escenaris. Veure, per exemple, com es degrada el temps de resposta a mesura que hem incrementat el nombre d’usuaris.
Agrupem les diferents seccions de l’informe segons cinc categories:
- Detalls Generals
- Processos provats i Scripts
- Temps de resposta i estat de les transaccions
- Usuaris i estat
- Respostes del servidor
Detalls generals
- General Details: Fixar-se en que la durada de la prova hagi estat representativa (mínim de 30 minuts, recomanable 1h). Si s’ha executat en menys temps revisar si és perquè s’estaven trobant molts errors i s’ha aturat manualment.
- Workload Characteristics: Revisar quants usuaris virtuals màxims s’han simulat.
- Performance Overview: Revisar la ràtio de transaccions fallides respecte passades.
Processos provats i Scripts
A l’apartat ‘Business Process’:
- Revisar els scripts definits, la concurrència d’usuaris per cadascun d’ells (‘Concurrent users’) i si encaixa amb la realitat que es volia simular.
Revisar el nombre de transaccions per hora que hem pogut executar en cada script i que es correspongui amb els requisits que s’havien establert al fer el càlcul de la concurrència d’usuaris per cada script.
Exemple : 2.500 preinscripcions en 2 hores de la convocatòria normal. Això vol dir 1.250 per hora. Si mirem la taula, hem aconseguit 26.000 en una hora (hem superat les expectatives, però també hem de veure després quantes han finalitzat amb error)
Revisar que “Browser cache” té el valor “No”, és a dir, no s’ha activat la caché en els navegadors que simulen la càrrega. Habitualment, volem simular una navegació diverses vegades com si fossin usuaris diferents entrant dades. Si repetim una navegació amb les mateixes dades i la catxe està activada, obtindrem millors temps de resposta a partir de la segona petició, quan en realitat el que volíem era simular diferents usuaris.
Comprovar els passos que conté cada script ( Transactions ) i comparar amb l’especificació de proves que es va lliurar a l’eina del cicle de vida del software ValueEdge.
Temps de resposta i estat de les transaccions
Transaction Summary
Revisar el temps que apareix a la columna del percentil, valor establert per defecte en un 90%. Els temps mitjos no són del tot rellevants, és més rellevant el percentil 90%, ja que mesura els valors “habituals” i no els valors que estan en les fronteres (inclosos al temps mig)
A la primera transacció de l’exemple es llegeix que el temps de resposta del 90% de les transaccions ’01-TransactionPantalla1’, ha estat menor que 2,6 segons. Durant les proves s’han executat correctament 17239 transaccions (‘Pass Count’) i han fallat 25 (Fail Count).
Average Transaction Response Time: En aquest punt es presenta el gràfic més important per a la interpretació del resultat de les proves, on es pot veure el temps de resposta obtingut per a cada transacció durant la durada de la prova.
IMPORTANT: A diferència de l’informe de Transaction Summary, en aquesta secció només s’inclouen les transaccions que han finalitzat amb èxit.
- Les transaccions haurien de seguir una temps de resposta mig relativament estable, sense valls i pics.
- Ens hem de fixar en els valors mostrats i especialment en la desviació estàndard, ja que representa quina dispersió de temps perceben els usuaris. Com més gran sigui la desviació estàndard més disperses o volàtils són els valors, i per tant l’aplicació no funciona de forma correcta i predeterminista (a alguns usuaris molt més ràpid, a altres més lent, etc.).
En aquest exemple, el camp “Granularity” veiem que és de 128 segons. Això vol dir que en els eixos es calculen les mètriques dins d’intervals de 128 segons.
Es pot escollir la granularitat de l’eix d’abscisses (temps) en fer la generació del report. Cal seleccionar abans de generar l’informe el paràmetre ‘Global Settings –> Granularity’ adient. Ens pot interessar veure-ho cada 5 minuts, cada 5 segons, etc.
Transaction Response Time (Percentile): Comparar aquest gràfic amb el de “Average Transaction Response Time”. Un temps de resposta alt per algunes transaccions pot incrementar la mitja total. Si en canvi, el nombre de transaccions amb un alt temps de resposta és inferior al 5% del temps, aquest factor pot ser insignificant.
En aquest cas veiem que el temps de resposta de totes les transaccions es troba entre 0 i 120 segons. És això acceptable?
Les 4 últimes transaccions de la taula anterior (04-AcceptarFinalFamilia, …) , tenen molta dispersió. Per exemple, si prenem la transacció 04-AceptarFinalGF, que s’ha executat 643 vegades (segons ‘Transaction summary’), i mirem al gràfic veurem que un 5% s’han executat amb menys de 10 segons, un 5% més entre 10 i 20 segons i així successivament. La dispersió dóna idea de què cal fer un ‘tuning’, és a dir, fer focus en optimitzar el rendiment.
Usuaris i estat
Running Vusers: Revisar quants usuaris s’han simulat en total i si la seva entrada i sortida de la prova ha estat esglaonada.
A l’exemple mostrat, els 200 usuaris virtuals (el total), entren en el segon zero quan s’inicia la prova.
Vusers Summary: Revisar l’estat en què han finalitzat les execucions dels diferents usuaris concurrents.
En el cas mostrat a dalt, tots han estat aturats abans de la seva finalització. En aquest cas ens hem de qüestionar perquè el provador ha decidit aturar la prova abans que acabés.
Respostes del servidor
- HTTP Response Summary : Analitzar quantes respostes hi han amb error.
A primera vista la taula no diferencia el què són errors i no. S’han de conèixer els codis i el seu significat, que poden trobar en el següent enllaç List of HTTP status codes: 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error i 5xx Server Error.
* HTTP 200 'OK'
* HTTP 302 són redireccions, un esdeveniment normal
* HTTP 404 'resource not found'. Manca alguna imatge, alguna pàgina, etc.
* HTTP 500 Servidor ocupat. No ha pogut contestar en el temps necessari.
* HTTP 503 Errors d’autenticació.
Throughpput (MB): Aquest gràfic ens dóna la quantitat de megas que es transfereixen per la xarxa per totes les sol·licituds realitzades durant les proves.
De nou veiem, que al minut 15 de la prova aproximadament hi ha hagut algun problema, ja que ha baixat a zero el nombre de bytes transferits.
Host Resources : Revisar quina és la càrrega dels injectors per avaluar si hi ha un ús intensiu de recursos en els PCs que simulen la càrrega que poden desvirtuar els temps de resposta obtinguts. En aquest cas caldria repetir les proves amb més injectors repartits.
En aquest exemple, veiem al gràfic un ús molt proper al 100% en el minut 15.