Què és l'eina de proves HP LoadRunner? Arquitectura, components

Què és LoadRunner?

LoadRunner és una eina de proves de rendiment iniciada per Mercury el 1999. LoadRunner va ser adquirida posteriorment per HPE el 2006. El 2016, LoadRunner va ser adquirida per MicroFocus.

LoadRunner admet diversos eines de desenvolupament , tecnologies i protocols de comunicació. De fet, aquesta és l'única eina del mercat que admet un nombre tan gran de protocols per dur a terme proves de rendiment. Els resultats de les proves de rendiment produïts pel programari LoadRunner s’utilitzen com a punt de referència davant d’altres eines

En aquest tutorial, aprendreu

Per què LoadRunner?

LoadRunner no només és una eina pionera en les proves de rendiment, sinó que segueix sent líder del mercat en el paradigma de les proves de rendiment. En una avaluació recent, LoadRunner té aproximadament un 85% de quota de mercat a la indústria de les proves de rendiment.

A grans trets, l'eina LoadRunner admet RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex i Silverlight, etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail i sobretot, Windows Socket. Al mercat no hi ha cap eina de competència que pugui oferir una àmplia varietat de protocols dotats d’una única eina.

El que és més convincent per escollir LoadRunner en les proves de programari és la credibilitat d'aquesta eina. L'eina LoadRunner fa temps que s'ha establert una reputació amb la freqüència que trobareu els clients verificen creuadament els vostres paràmetres de rendiment mitjançant LoadRunner. Trobareu alleujament si ja utilitzeu LoadRunner per a les vostres necessitats de proves de rendiment.

El programari LoadRunner està estretament integrat amb altres eines d’HP, com ara la prova funcional unificada (QTP) i l’ALM (Application Lifecycle Management), que us permeten realitzar processos de prova d’extrem a extrem.

LoadRunner treballa en un principi de simulació d’usuaris virtuals a l’aplicació objecte. Aquests usuaris virtuals també es denominen VUsers, repliquen les sol·licituds del client i esperen una resposta corresponent en passar una transacció.

Per què necessiteu proves de rendiment?

Una estimació pèrdua de 4.400 milions d’ingressos es registra anualment a causa d’un rendiment web deficient.

A l’era actual del web 2.0, els usuaris fan clic si un lloc web no respon en 8 segons. Imagineu-vos esperant durant 5 segons quan cerqueu Google o feu una sol·licitud d’amistat a Facebook. Les repercussions del temps d'inactivitat del rendiment sovint són més devastadores del que mai s'havia imaginat. Tenim exemples com els que recentment han arribat a la banca en línia de Bank of America, Amazon Web Services, Intuit o Blackberry.

Segons Dunn & Bradstreet, el 59% de les empreses de Fortune 500 experimenten aproximadament 1,6 hores de parada cada setmana. Tenint en compte que l’empresa mitjana Fortune 500 amb un mínim de 10.000 empleats paga 56 dòlars per hora, la part laboral dels costos d’aturada d’aquesta organització seria de 896.000 dòlars setmanals, cosa que es traduiria en més de 46 milions de dòlars a l’any.

Es calcula que només un temps d'inactivitat de 5 minuts de Google.com (19-agost-13) costarà al gegant de la cerca fins a 545.000 dòlars.

Es calcula que les empreses van perdre vendes per valor de 1100 dòlars per segon a causa d’un recent tall de serveis web d’Amazon.

Quan una organització desplega un sistema de programari, pot trobar-se amb molts escenaris que poden provocar una latència de rendiment. Hi ha diversos factors que provoquen un desacceleració del rendiment, alguns exemples poden incloure:

  • Increment del nombre de registres presents a la base de dades
  • Increment del nombre de sol·licituds simultànies realitzades al sistema
  • un nombre més gran d’usuaris que accedeixen al sistema alhora comparat amb el passat

Què és LoadRunner Architecture?

A grans trets, l’arquitectura d’HP LoadRunner és complexa, però fàcil d’entendre.

Diagrama d’Arquitectura LoadRunner



Suposem que esteu assignat per comprovar el rendiment d’Amazon.com per a 5000 usuaris

En una situació de la vida real, tots aquests 5.000 usuaris no estaran a la pàgina d'inici, sinó a una secció diferent dels llocs web. Com podem simular de manera diferent

VUGen:

VUGen o Virtual User Generator és un IDE (entorn de desenvolupament integrat) o un editor de codificació ric. VUGen s'utilitza per replicar el comportament del sistema sota càrrega (SUL). VUGen proporciona una funció de 'gravació' que registra la comunicació des de i cap al client i el servidor en forma d'un script codificat, també anomenat script VUser.

Per tant, tenint en compte l’exemple anterior, VUGen pot gravar per simular els processos de negoci següents:

  1. Navegant per la pàgina de productes d’Amazon.com
  2. Comanda
  3. Processament de pagaments
  4. Comprovació de la pàgina El meu compte

Controlador

Un cop finalitzat un script VUser, Controller és un dels components principals de LoadRunner que controla la simulació de càrrega gestionant, per exemple:

  • Quants VUsers per simular contra cada procés empresarial o grup VUser
  • Comportament dels usuaris (pujada, baixada, naturalesa simultània o simultània, etc.)
  • Escenari de la naturalesa de la càrrega, p. Orientació a la vida real o objectiu o verificació de l'SLA
  • Quins injectors utilitzar, quants VUsers contra cada injector
  • Compileu els resultats periòdicament
  • Spoofing IP
  • Informe d'errors
  • Informes de transaccions, etc.

Si prenem una analogia del nostre controlador d’exemple, s’afegirà el següent paràmetre a l’escriptura VUGen

1) Hi ha 3.500 usuaris Navegant per la pàgina de productes d’Amazon.com

2) Hi ha 750 usuaris Comanda

3) 500 usuaris ho són realitzant el processament de pagaments

4) 250 usuaris ho són Comprovació de la pàgina MyAccount NOMÉS després que 500 usuaris hagin processat el pagament

Fins i tot són possibles escenaris més complexos

  1. Inicieu 5 VUsers cada 2 segons fins que s'aconsegueixi una càrrega de 3500 VUsers (navegar per la pàgina del producte d'Amazon).
  2. Iterar durant 30 minuts
  3. Suspendre la iteració per a 25 usuaris de VU
  4. Reinicieu 20 VUSers
  5. Inicieu 2 usuaris (a Pagament, Processament de pagaments, Pàgina Els meus comptes) cada segon.
  6. Es generaran 2.500 VUsers a la màquina A.
  7. Es generaran 2.500 VUsers a la màquina B.

Agents Generadors de màquines / càrrega / injectors

HP LoadRunner Controller és responsable de simular milers de VUsers (aquests VUsers consumeixen recursos de maquinari, per exemple, processador i memòria), posant així un límit a la màquina que els està simulant. A més, Controller simula aquests VUsers des de la mateixa màquina (on resideix Controller) i, per tant, els resultats poden no ser precisos. Per solucionar aquesta preocupació, tots els VUsers estan repartits per diverses màquines, anomenades Generadors de càrrega o injectors de càrrega.

Com a pràctica general, el controlador resideix en una màquina diferent i es simula la càrrega des d'altres màquines. Depenent del protocol dels scripts de VUser i de les especificacions de la màquina, és possible que siguin necessaris diversos injectors de càrrega per a la simulació completa. Per exemple, els VUsers per a un script HTTP requeriran 2-4 MB per VUser per a la simulació, per tant, es requeriran 4 màquines amb 4 GB de RAM cadascuna per simular una càrrega de 10.000 VUsers.

Prenent analogia del nostre exemple d’Amazon, la sortida d’aquest component serà

Anàlisi:

Un cop executats els escenaris de càrrega, el paper de ' Anàlisi 'Components de LoadRunner.

Durant l'execució, el controlador crea un buidatge de resultats en format brut i conté informació com, quina versió de LoadRunner va crear aquest buidatge de resultats i quines eren les configuracions.

Tots els errors i excepcions es registren en una base de dades d'accés de Microsoft, anomenada output.mdb. El component 'Anàlisi' llegeix aquest fitxer de base de dades per realitzar diversos tipus d'anàlisi i genera gràfics.

Aquests gràfics mostren diverses tendències per entendre el raonament darrere dels errors i fallades sota càrrega; per tant, ajudeu a esbrinar si cal optimització a SUL, Server (per exemple, JBoss, Oracle) o infraestructura.

A continuació es mostra un exemple en què l’amplada de banda podria crear un coll d’ampolla. Posem per cas que el servidor web té 1 GBps de capacitat, mentre que el trànsit de dades supera aquesta capacitat i provoca que els usuaris posteriors pateixin. Per determinar que el sistema satisfà aquestes necessitats, Performance Engineer ha d’analitzar el comportament de l’aplicació amb una càrrega anormal. A continuació es mostra un gràfic que genera LoadRunner per obtenir amplada de banda.

Full de ruta de proves de rendiment: passos detallats

El full de ruta de proves de rendiment es pot dividir en cinc passos:

  • Planificació de la prova de càrrega
  • Creeu scripts VUGen
  • Creació d’escenaris
  • Execució d’escenaris
  • Anàlisi de resultats (seguit de modificacions del sistema)

Ara que ja teniu instal·lat LoadRunner, comprenem els passos del procés un per un.

Passos del procés de proves de rendiment

Planificació de la prova de càrrega

La planificació de les proves de rendiment és diferent de la planificació de SIT (proves d’integració de sistemes) o bé UAT (Proves d’acceptació d’usuaris) . La planificació es pot dividir en petites etapes, tal com es descriu a continuació:

Reuneix el teu equip

En començar amb LoadRunner Testing, és millor documentar qui participarà a l'activitat de cada equip implicat durant el procés.

Cap de projecte:

Nomineu el director de projecte que serà propietari d’aquesta activitat i servirà com a persona puntual per a l’escalada.

Expert en funcions / analista de negocis:

Proporcioneu una anàlisi d’ús de SUL i oferiu experiència en la funcionalitat comercial del lloc web / SUL

Expert en proves de rendiment:

Crea les proves de rendiment automatitzades i executa escenaris de càrrega

Arquitecte de sistemes:

Ofereix un pla del SUL

Desenvolupador web i pimes:

  • Manté el lloc web i proporciona aspectes de control
  • Desenvolupa el lloc web i corregeix els errors

Administrador de sistemes:

  • Manté els servidors involucrats durant tot un projecte de prova

Esquema d'aplicacions i processos empresarials implicats:

Amb èxit Prova de càrrega requereix que tingueu previst dur a terme determinats processos comercials. Un procés empresarial consisteix en passos clarament definits en compliment de les transaccions comercials desitjades, per tal d’aconseguir els vostres objectius de proves de càrrega.

Es pot preparar una mètrica de requisits per provocar la càrrega de l'usuari al sistema. A continuació es mostra un exemple d’un sistema d’assistència a una empresa:

A l'exemple anterior, les xifres mencionen el nombre d'usuaris connectats a l'aplicació (SUL) a una hora determinada. Podem extreure el nombre màxim d’usuaris connectats a un procés empresarial a qualsevol hora del dia que es calcula a les columnes més a la dreta.

De la mateixa manera, podem concloure el nombre total d’usuaris connectats a l’aplicació (SUL) a qualsevol hora del dia. Això es calcula a la darrera fila.

Els dos fets anteriors combinats ens proporcionen el nombre total d’usuaris amb els quals hem de provar el rendiment del sistema.

Definiu els procediments de gestió de dades de prova

Les estadístiques i observacions extretes de les proves de rendiment estan molt influenciades per nombrosos factors, tal com es va informar anteriorment. És de gran importància preparar dades de prova per a proves de rendiment. De vegades, un procés empresarial concret consumeix un conjunt de dades i produeix un conjunt de dades diferent. Prenguem l'exemple següent:

  • Un usuari 'A' crea un contracte financer i el sotmet a revisió.
  • Un altre usuari 'B' aprova 200 contractes diaris creats per l'usuari 'A'
  • Un altre usuari 'C' paga uns 150 contractes diaris aprovats per l'usuari 'B'

En aquesta situació, l'usuari B ha de tenir 200 contractes 'creats' al sistema. A més, l'usuari C necessita 150 contractes com a 'aprovats' per simular una càrrega de 150 usuaris.

Això significa implícitament que heu de crear com a mínim 200 + 150 = 350 contractes.

Després, aproveu 150 contractes perquè serveixin com a dades de prova per a l’usuari C; els 200 contractes restants serviran com a dades de prova per a l’usuari B.

Monitors d’esquema

Especifiqueu tots i cadascun dels factors que poden afectar el rendiment d'un sistema. Per exemple, tenir un maquinari reduït tindrà un impacte potencial sobre el rendiment de SUL (System Under Load).

Inscriviu tots els factors i configureu monitors perquè pugueu mesurar-los. Aquí en teniu alguns exemples:

  • Processador (per a servidor web, servidor d'aplicacions, servidor de bases de dades i injectors)
  • RAM (per a servidor web, servidor d'aplicacions, servidor de bases de dades i injectors)
  • Servidor web / d'aplicacions (per exemple, IIS, JBoss, Jaguar Server, Tomcat, etc.)
  • Servidor de base de dades (mida PGA i SGA en cas de servidor Oracle i MSSQL, SP, etc.)
  • Utilització de l’amplada de banda de la xarxa
  • NIC interna i externa en cas de clusterització
  • Load Balancer (i que distribueix la càrrega de manera uniforme a tots els nodes dels clústers)
  • Flux de dades (calculeu quantes dades es mouen des del client i el servidor i calculeu si una capacitat de NIC és suficient per simular el nombre X d’usuaris)

Creeu scripts VUGen

El següent pas després de la planificació és crear Scripts d'usuari.

Creació d’escenaris

El següent pas és crear el vostre escenari de càrrega

Execució d’escenaris

L’execució de l’escenari és on emuleu la càrrega de l’usuari al servidor donant instruccions a diversos usuaris virtuals perquè realitzin tasques simultàniament.

Podeu definir el nivell d’una càrrega augmentant i disminuint el nombre d’usuaris que realitzen tasques alhora.

Aquesta execució pot provocar que el servidor estigui estressat i es comporti de manera anormal. Aquest és el propòsit mateix de les proves de rendiment. Els resultats obtinguts s’utilitzen per fer anàlisis detallades i identificar la causa arrel.

Anàlisi de resultats (seguit de modificacions del sistema)

Durant l'execució de l'escenari, LoadRunner registra el rendiment de l'aplicació sota diferents càrregues. Es guarden les estadístiques extretes de l'execució de la prova i es realitza l'anàlisi de detalls. L'eina 'HP Analysis' genera diversos gràfics que ajuden a identificar les causes fonamentals del desfasament del rendiment del sistema, així com un error del sistema.

Alguns dels gràfics obtinguts inclouen:

  • Temps del primer buffer
  • Temps de resposta de transaccions
  • Temps mitjà de resposta a les transaccions
  • Visites per segon
  • Recursos de Windows
  • Estadístiques d’errors
  • Resum de transaccions

Preguntes freqüents

Quines aplicacions hem de provar de rendiment?

Proves de rendiment sempre es fa només per a sistemes basats en client-servidor. Això vol dir que qualsevol aplicació que no sigui una arquitectura basada en client-servidor no ha de requerir proves de rendiment.

Per exemple, Microsoft Calculator no està basat en servidor-client ni executa diversos usuaris; per tant, no és candidat a les proves de rendiment.

Quina diferència hi ha entre proves de rendiment i enginyeria de rendiment

És important entendre la diferència entre les proves de rendiment i l'enginyeria de rendiment. A continuació es comparteix una comprensió:

Proves de rendiment és una disciplina preocupada proves i informes el rendiment actual d'una aplicació de programari sota diversos paràmetres.

Enginyeria de rendiment és el procés mitjançant el qual es prova i s’ajusta el programari amb la intenció d’aconseguir el rendiment requerit. Aquest procés té com a objectiu optimitzar el tret de rendiment de l'aplicació més important, és a dir, l'experiència de l'usuari.

Històricament, les proves i la posada a punt han estat àmbits clarament separats i sovint competidors. En els darrers anys, però, diverses butxaques de provadors i desenvolupadors han col·laborat independentment per crear equips de sintonització. Com que aquests equips han tingut un èxit significatiu, el concepte d’acoblament de les proves de rendiment amb l’ajust de rendiment ha agafat força i ara en diem enginyeria de rendiment.