Les proves de rendiment són proves no funcionals que tenen com objectiu validar l’eficiència de l’aplicació en temps de resposta i throughput. 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 els diferents subtipus, segons el seu objectiu

Tipus de proves de rendiment Objectiu Resultats Punts a considerar
Proves de càrrega (la més habitual) Verificar el comportament en les condicions esperades: condicions normals i condicions de pics (per exemple en períodes de la matriculació). Es realitza comprovant el resultats amb una càrrega creixent d’usuaris. S’obtenen els temps de resposta per les transaccions. Es pot monitoritzar el comportament de la infraestructura. Per establir si els temps són acceptables és bo haver definit prèviament els ANS
Proves d’estrès Verificar el comportament de l’aplicació per sobre de les condicions normals o condicions de pics, o amb una disponibilitat reduïda de recursos, per detectar defectes que només tenen lloc en aquestes condicions Dóna informació de a partir quan l’aplicació començarà a fallar i donar errors, a més de la pròpia lentitud La càrrega realitzada pot provocar disrupcions en altres aplicacions, si l’entorn no està totalment aïllat (xarxa, …)
Proves d’estabilitat o resistència Determinar si l’aplicació pot aguantar una càrrega esperada continuada Determinar si hi ha alguna fuga de memòria de l’aplicació En alguns casos pot ser necessari executar-les en entorns productius. En aquest cas s’ha d’avaluar prèviament l’impacte i acordar finestres d’execució.

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ó:

  1. Maquinari (configuracions, volum de dades, processador, RAM, …)
  2. Xarxa:
    • Arquitectura i ubicació dels usuaris finals
    • Balanceig i configuracions de clúster
  3. 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ó
  4. Programari:
    • Nivells de logs
  5. 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/alm-loadrunner)

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:

  1. S’ha sel·leccionat un pacing aleatori entre un interval acordat
  2. 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”)
  3. S’ha marcat un percentatge aleatori entre 50% i 100% dels think times registrats amb VUGen
  4. S’ha establert un argument “ServerName” (dins “Additional attributes”) amb l’adreça del servidor per poder simular la mateixa prova en diferents entorns
  5. 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.

Com determinar si els resultats de 2 o més repeticions són similars?

S'usarà un marge del 98% de confiança, un concepte estadístic, i formularem llavors que:

Mitjana Exec 2 tx = Mitjana Exec 1 tx +/- ((desv. estàndard / arrel quadrada nºtransaccions passades) x 2.38)

On 'tx' correspon a la transacció que estem mesurant, i nºtransaccions passades és el nombre de vegades que la transacció tx ha estat executada en la prova.

Per exemple si hem provat 50 usuaris concurrents una primera vegada d'una transacció d'alta d'usuari, que s'ha passat 100 vegades durant 1 hora, amb un temps de resposta mig de 5 segons i desviació estàndard de 1 segon, tindrem:

  • Mitjana Exec 1 tx = 5 segons
  • Desv. estàndard = 1 segon
  • Nºtransaccions passades = 100 (l'arrel quadrada és 10)

Si tornem a repetir la prova, el temps mig de resposta haurà d'estar entre: 5 +/- (1 / 10) --> Entre 4,99 i 5,01

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.

llindar_usuaris_concurrents