El model de càrrega defineix com és la distribució de càrrega esperada en l’entorn de producció pels diferents escenaris.
L’esforç dedicat a la definició del model ha de ser proporcional al risc del projecte. Si en un projecte el rendiment és crític, s’haurà de dedicar més esforç per desenvolupar el model. Si el rendiment és poc rellevant, es poden fer escenaris més simples.
Per determinar el model de càrrega usarem els següents passos:
- Identificar els escenaris clau
- Identificar el nombre màxim d’usuaris concurrents que estan connectats a l’aplicació i fent-la servir a la vegada
- Identificar quines accions pot realitzar un usuari (connectar-se a la pàgina principal, login, navegar pels tràmits, cercar un tràmit específic, validar un tràmit, log out, …)
- Identificar els perfils d’usuari de l’aplicació. Agrupar el diferents tipus d’usuaris i accions que realitzen. Per exemple hi haurà usuaris que naveguen, altres que cerquen i altres que validen els tràmits.
- Identificar per cada perfil, el nombre mig d’operacions que es realitzen
Identificar els escenaris clau
Per escollir quins són els escenaris clau a escollir tenir en compte:
- Transaccions crítiques del negoci. Per aquestes ha d’existir
- Transaccions usades freqüentment
- Transaccions que és molt probable que afectin al rendiment (transaccions llargues, bloquejos, processos batch, realitzar una cerca amb pocs filtres que comporta un gran volum gran de dades, …)
- Transaccions amb problemes de rendiment identificats en la monitorització
- Incloure almenys 1 transacció de lectura i 1 d’escriptura per poder diferenciar el seu impacte
Identificar el nombre màxim d’usuaris concurrents
IMPORTANT - Definir el nombre d'usuaris concurrents a provar
No podem definir les proves partint únicament del nombre d’usuaris potencials que poden accedir a l'aplicació. Habitualment aquest és el nombre plantejat de forma equivocada per al nombre d'usuaris concurrents que s'han de verificar
Identificar les hores pic en les que hi haurà una major càrrega per establir quins són els usuaris que poden estar connectats a l’aplicació.
Usar la guia Càlcul de nombre d’usuaris concurrents a simular en unes Proves de Rendiment
Identificar els camins de navegació dels escenaris clau
Per a cada escenari identificar els camins de navegació que pot realitzar un usuari i establir quina és la seva freqüència (per acordar si s’ha d’incloure o no en les proves).
Identificar les dades úniques de les proves
Per simular de forma correcta els camins es requereix determinar:
- Temps que un usuari passa en una pàgina en un dels camins
- Quines dades es requereixen per un camí
Escenari |
Acció |
Dades entrada |
Usuaris (100) |
Usuaris (200) |
Home |
40% |
40 |
80 |
120 |
Login_Browse |
15% |
15 |
30 |
45 |
S’ha d’evitar usar les mateixes dades per múltiples usuaris, ja que això generarà resultats invàlids.
Establir la distribució relativa de la càrrega
En aquest pas hem de determinar en quin moment s’executarà cada escenari, i quin serà el percentatge d’execució respecte el total de la càrrega. Per establir-ho podem usar:
- Fitxers de traces del servidor
- Consultar eines analítiques de les visites realitzades
Escenari |
Percentatge distribució càrrega |
Navegar tràmits |
40% |
Cercar un tràmit |
20% |
Realitzar un tràmit |
40% |
Identificar rampes d’entrada i sortida de cada escenari
Quan fem proves de rendiment hem de determinar com entren els diferents usuaris virtuals per simular les transaccions. Una opció és que entrin tots de cop a l’iniciar les proves però no és un comportament habitual.
Si pensem en un entrada a un sistema de tramitació sabem quin serà el punt de pic, però els usuaris no entren tots de cop. Segurament podem dir que entren 25 els primers 5 minuts, 50 els següents 10 minuts, …
Identificar durada de cada escenari de prova
La durada de cada escenari depèn de com és el funcionament real de l’aplicació:
- Si tenim una web/aplicació que té un accés mig comú durant tot el dia i que no variarà durant l’horari de treball (8 hores, p.ex.) una durada de 30 minuts a 1 hora és suficient.
- Si existeix una variació en el perfil dels usuaris (p.ex. es realitzen més tràmits des de les 8 fins les 12h i molts menys a partir d’aquesta hora), la durada hauria de considerar el temps de major càrrega (a l’exemple 4 hores)
- Si volem identificar possibles fugues de memòria la durada haurà de ser de almenys 2 dies
Identificar els objectius llindar de càrrega
L’últim pas en la definició del model és identificar quins són els nivells de càrrega habitual i els pics de cadascun dels escenaris.