Les proves de rendiment tenen una complexitat superior a la d’altres tipus de proves i cal que es planifiquin, dissenyin i executin tenint en compte diferents patrons i pràctiques, per tal que el seu ús sigui eficient i no es malbaratin esforços i costos.
Identificar els objectius de les proves
- Mesurar el rendiment amb una càrrega esperada
- Exposar defectes que no apareixen en proves de rendiment aïllades, com fugues de memòria, overflows, …
- Assegurar que l’aplicació compleix la línia base que es va mesurar en una versió anterior
- Provar quin és el llindar màxim per fer caure la màquina
En base als objectius podrem establir si volem fer una prova de càrrega, una d’estrès, …
Identificar l’entorn de proves
Identificar en quin entorn es realitzaran les proves, així com les eines que requerirem (injectors, …). El factor clau és entendre les similituds i diferències entre l’entorn de proves (preproducció, p.ex.) i l’entorn de producció:
- Maquinari (configuracions, volum de dades, processador, RAM, …)
- Xarxa:
- Arquitectura i ubicació dels usuaris finals
- Balanceig i configuracions de clúster
- Eines. Limitació de l’eina en la generació de càrrega (per injector, p.ex. un màxim de 15 peticions concurrents) i possible impacte en les eines de monitorització
- Programari:
- Factors externs:
- Volum de tràfic adicional a la xarxa
- Processos planificats
- Interaccions amb altres sistemes externs
Identificar els criteris d’acceptació del rendiment
Identificar els criteris d’acceptació per:
- Temps de resposta. P.ex. La safata de tràmits s’ha de mostrar en menys de 3 segons
- Throughput. P.ex. El sistema ha de suportar 10 peticions de cerca per segon
- Utilització de recursos. P.ex. L’ús de CPU no pot ser superior al 75% i la memòria ha de ser menys de 1Gb
Planificar i dissenyar les proves
Per objectivar quin serà el rendiment en producció, és important que es dissenyin escenaris o simulacions reals, considerant:
- Retards de l’usuari i think times
- Abandonaments
- Errors d’usuari comuns
S’ha de definir el model de càrrega, seguint la guia Definició del Model de Càrrega
Configurar l’entorn de proves
Instal·lar els injectors de càrrega si és necessari.
Implementar la prova
Aquest pas inclou la creació dels scripts i escenaris usant l’eina corporativa](/eines/hp-pc)
Assegurar que:
- S’han preparat correctament els jocs de dades a simular (mitjançant graelles o spreadsheets)
- Les proves han estat parametritzades, de forma que qualsevol variable és externa al joc de dades
- S’han validat correctament les transaccions. P.ex. el servidor pot respondre amb OK a una petició però no mostrar-se correctament a la pàgina la informació.
- Tots els valors que s’haurien de correlacionar s’han correlacionat (atenció especial a les cookies de sessió)
- Totes les peticions al servidor (‘web_url’, ‘web_submit_data’) són mesurades dins una transacció (lr_start_transaction, lr_end_transaction, lr_set_transaction)
Executar la prova
Abans d’executar les proves reals, executar una prova de fum per verificar que el script i l’eina corporativa funcionen correctament (injectors, …).
Assegurar-se que es recullen els indicadors de rendiment.
Caldrà executar totes les proves almenys 3 vegades. Això és important perquè els resultats de les primeres proves poden ser afectats per l’ús de cachés del servidor, càrrega de llibreries, …. Si el resultat de la segona iteració i de la tercera no són similars tornar a executar les proves.
Mentre es realiza la prova de càrrega, accedir a l’aplicació de forma manual per comparar posteriorment amb els resultats de les proves.
Recordar simular la rampa de pujada i de baixa d’acord amb el model definit.
En la configuració de l’execució considerar:
- S’ha sel·leccionat un pacing aleatori entre un interval acordat
- S’ha marcat que es faci el log (“Enable logging” dins “General>Log”), però que només s’enviin els missatges quan hi hagi un error (“Send messages only when an error occurs”)
- S’ha marcat un percentatge aleatori entre 50% i 100% dels think times registrats amb VUGen
- S’ha establert un argument “ServerName” (dins “Additional attributes”) amb l’adreça del servidor per poder simular la mateixa prova en diferents entorns
- S’usa una taula de paràmetres d’entrada per simular diferents usuaris
Analitzar els resultats
Abans d’informar dels resultats finals, cal analitzar les dades obtingudes amb l’eina
L’execució de la mateixa prova (repetició) sempre donarà temps de resposta diferents, ja que les condicions en les que s’executen no són exactament al 100% les mateixes (càrrega a la xarxa, servidors, temporitzadors, fils d’execució que entren en diferents moments del temps, etc.). Això vol dir que si executem la mateixa prova dos vegades obtindrem, per exemple, temps de resposta diferents.
Avaluar les dades recollides i comparar-les amb els criteris d’acceptació establerts.
Si en base a l’avaluació del cicle es troben colls d’ampolla o problemes, afegir noves mètriques a capturar i realitzar un nou cicle de proves.