Testeando Oracle Forms 10G con Load Runner

1
49493

 Testeando
Aplicaciones Oracle Forms 10G con Load Runner
.



Introducción



Metodología



Degradación del Desempeño (Performance)



Número de Usuarios



Tiempo de Respuesta



Tipos de Test



Complejidad de la aplicación



Escenarios



Entorno de trabajo



Oracle Summit: la aplicación a testear



Arquitectura de la
aplicación a testear



Software de Testing



Configuración de la aplicación Summit con Forms 10G



Creación del usuario “summit” en la base Oracle
10G



Import del dmp de Summit



Cambios realizados a las formas de la aplicación Summit para emplearla con
Oracle Forms 10G



Compilación de las formas



Creación del archivo summit.env



Edición del archivo formsweb.cfg



Creación del war de la aplicación



Publicación de la aplicación Summit en Oracle
Application Server



Instalación y Configuración de Mercury LoadRunner



Introducción a LoadRunner



Esquema de Funcionamiento de LoadRunner



Ejecutar el instalador



Configuración del VUG (Virtual User Generator)



Edición de los scripts generados con el VUG



Parámetro jsessionid y variable NCAJSerSessionID



Creación de parámetros para
el script



Ejecución de un escenario con LoadRunner



Conclusiones



Bibliografía

 

 

 

 

 

 

 

 

 

 

 

 


Testeando Aplicaciones Oracle Forms 10G con Load
Runner

 


Introducción

 

Una de las mayores preocupaciones de los desarrolladores
es poder llegar a determinar los límites críticos en los cuales una aplicación
de software trabajará de modo eficaz. Para poder establecer hasta que parámetros
la aplicación puede crecer y ser escalable, esto significa que se pueda realizar
una “simple” adición de dispositivos de hardware con el objetivo de mejorar el
desempeño sin que sea necesario realizar cambios o modificaciones en el software
desarrollado.

 


Metodología

 

El objetivo de realizar test sobre una aplicación no es
“obtener números” sino determinar hasta que grado una aplicación es “escalable”.
Entendiendo por esto que se puede llegar a determinar el número de usuarios que
pueden ser soportados en una arquitectura determinada con un rendimiento
aceptable.

 

En este marco deben seguirse los siguientes pasos

§        
Establecer un escenario real

§        
Grabar el escenario.

§        
Replicar el escenario para simular usuarios concurrentes, con un
número incremental de usuarios en cada iteración.

§        
Cuando el rendimiento general se vea degradado se puede obtener el
máximo número de usuarios que podrán ser soportados.

§        
Repetir varias veces el proceso y hacer ajustes graduales a la
configuración de equipos y servidores en los casos en los que se considere
necesario

§        
Tabular la información obtenida para obtener promedios.

§        
Analizar los resultados.

 


Degradación del Desempeño (Performance)

A medida que agreguemos
usuarios el desempeño de la aplicación se empezará a ver comprometido, el
usuario notará que en general el comportamiento de la aplicación es más lento
para la “[1]sensibilidad
humana”. Una vez que se llegue al punto de saturación el desempeño de la
aplicación va a decaer drásticamente.


Número de Usuarios

Para una simulación de
usuarios concurrentes, Oracle recomienda que se adicionen usuarios en pasos de
50, incrementando el número de 50 en 50 cada vez.


Tiempo de Respuesta

El tiempo de respuesta se
define como el tiempo de envío de un “Mensaje de Forms” es decir el tiempo que
transcurre desde una petición del cliente Forms hacia el servidor y hasta
obtener la respuesta del mismo. Un ejemplo de un tiempo de respuesta aceptable
en una aplicación Forms está en el orden de 30 milisegundos para un usuario
conectado en un ambiente cliente – servidor.


Tipos de Test

Existen dos tipos básicos de
Test

 

§        
Saturación
de Memoria:
En
este tipo de test se somete a la aplicación a incrementos de carga variables
hasta forzar a la memoria a tener un cuello de botella. Esto es que el servidor
no pueda liberar memoria a tiempo para atender el número creciente de demanda de
recursos de los usuarios.

 

§        
Saturación
de CPU:
En este
tipo de test se obliga al servidor a usar el 100% de recursos de procesamiento
de CPU sin que se llegue a consumir toda la memoria RAM disponible para
procesamiento.


Complejidad de la aplicación

Para Oracle Forms se pueden
establecer los siguientes criterios para determinar el tamaño de las
aplicaciones

 


Aplicaciones Pequeñas:

se definen de la siguiente manera

§        
Menos de 1Mb
en el tamaño de los archivos abiertos concurrentemente (.plx, .fmx, etc)

§        
Menos de 10
bloques, 5 canvas (lienzos) y 3 windows (ventanas)

§        
Máximo de 2
formas abiertas concurrentemente

 


Aplicaciones Medianas:

se caracterizan por

§        
Entre 1 a 3 Mb
en el tamaño de los archivos abiertos concurrentemente (.plx, .fmx, etc)

§        
De 10 a 20
bloques, 5 a 15 canvas (lienzos) y 3 a 10 windows (ventanas)

§        
Máximo de 3 a
5 formas abiertas concurrentemente

 


Aplicaciones Grandes:

se caracterizan por

§        
Más de 3 Mb en
el tamaño de los archivos abiertos concurrentemente (.plx, .fmx, etc)

§        
Más de 20
bloques, más 15 canvas (lienzos) y más 10 windows (ventanas)

§        
Más de 5
formas abiertas concurrentemente

 


Nota:

Oracle no proporciona ejemplos de benchmarking para aplicaciones grandes, en
esos casos recomienda al usuario realizar su propio benchmarking, en función de
los criterios presentados en sus documentos de guía.


Escenarios

 

Los escenarios a ser
testeados deben incluir

·  
Consultas de
información

·  
Inserción,
Modificación, y Eliminación de Datos

·  
Navegación
entre campos, canvas, windows de una forma.

·  
Navegación
entre formas

·  
Carga de
formas pesadas y/o complejas


Entorno de trabajo

 

    
El siguiente es
el entorno de trabajo de nuestra aplicación de ejemplo.


 

 


Servidor
de Aplicaciones


Servidor
de Base de Datos

Hardware

Máquina
Clon

Pentium
IV  2.8 GHz

RAM 4GB

HD 40 GB

Máquina
Clon

Pentium
IV  2.8 GHz

RAM 1.5
GB

HD 70 GB

Software

Oracle
Application Server 10g

Release
2 (10.1.2)

Linux
Red Hat Advantage Server 4.0

Oracle
DataBase 10g

Release
2 (10.1.2)

Linux
Red Hat Advantage Server 4.0

 


Nota:

Web Server y Application Server son el mismo equipo en nuestro actual entorno de
trabajo, en una aplicación real es muy probable que se empleen equipos
diferentes


Oracle Summit: la aplicación a testear

 

Se ha seleccionado la aplicación de ejemplo Summit
de Oracle, la misma que representa una aplicación pequeña y puede ser descargada
desde el portal de Oracle

http://otn.oracle.com/products/forms/content.html

 


Arquitectura de la
aplicación a testear

 

La aplicación que se desea
testear, es una aplicación Oracle Forms migrada al web. 

Tenemos entonces las
siguientes capas

§        
Base de datos

§        
Formas (Forms)

§        
Forms Services y Servlet Listener

§        
Application Server y web client

     

 

 


Software de Testing

 

Para las pruebas se ha
preseleccionado la herramienta LoadRunner de Mercury la misma que nos permite
grabar de manera íntegra una transacción de la aplicación y luego replicarla
para la simulación de usuarios concurrentes.

 

Para verificar las
características de la herramienta ir a

http://www.mercury.com

 

 


Configuración de

la aplicación Summit con Forms 10G

 

La aplicación summit
debe descomprimirse y seguir los siguientes pasos  configurarla en el ambiente
de Oracle Forms 10G.

 

Creación del usuario
“summit” en
la base Oracle 10G

 

Primero usted debe
conectarse a la instancia de Oracle y crear el usuario summit como se indica a
continuación

 

 

Import del dmp de
Summit

 

El zip contiene un dmp de la
base que debe ser importado utilizando el comando

 


imp
userid=summit/summit@<connect_string> file=summit.dmp full=y

 

 

Cambios realizados a las
formas de
la aplicación Summit para emplearla con Oracle Forms 10G

 

La versión 10G de Oracle
Forms introduce muchos cambios en relación a las funciones built-in donde muchas
ya no son soportadas, por lo cual se debió modificar ligeramente a la aplicación
de ejemplo antes de poder ser empleada.

 

Los cambios realizados
fueron básicamente los siguientes

 

§        
Reemplazar la
llamada de formas, uso de call(“forma”) se actualiza por
call_form(“forma”)

§        
Reemplazar las funcionalidades del tipo
disable_item(‘Query’,’Enter’) por
SET_ITEM_PROPERTY(‘Enter’,ENABLED,PROPERTY_FALSE)

§        
Reemplazar las funcionalidades del tipo
enable_item(‘Query’,’Last_Criteria’)
por
SET_ITEM_PROPERTY(‘Last_Criteria’,ENABLED,PROPERTY_TRUE)

 

Compilación de las
formas

 

Usted deberá tener
adecuadamente configuradas las variables de ambiente ORACLE_HOME y JAVA_HOME,
las formas que se proporcionan con la aplicación deben ser físicamente copiadas
hasta un directorio en el servidor y luego deberán ser incluidas en el path de
Forms.

 

Por ejemplo usted puede
copiar sus formularios en la ubicación ORACLE_HOME/formas/fsummit

 

Una vez que lo ha realizado
procederá a compilarlas ejecutando

 


$ORACLE_HOME/bin/frmcmp module=customers.fmb module_type=FORM
userid=summit/summit@orcl batch=no

 

 

 

Adicionalmente el archive

RoundedButton.class

debe ser copiado a la ubicación ORACLE_HOME/forms/java

 

Creación del archivo
summit.env

 

Debe ubicarse en el
directorio ORACLE_HOME/forms/Server y copiar el archivo default.env
a la copia renómbrela como summit.env

 

Este archivo se utilizará
para la definición de los parámetros en tiempo de ejecución de Oracle Forms, si
un parámetro no está definido en este archivo, el valor por defecto se tomará de
la configuración general de Forms.

 

En la copia debe editar la
línea correspondiente a FORMS_PATH

 


FORMS_PATH=/home/oracle/OraHome_2/forms:/home/oracle/dirFormas/fsummit

 

Y la sección correspondiente
a CLASS_PATH

 
CLASSPATH=/home/oracle/OraHome_2/j2ee/OC4J_BI_Forms/applications/formsapp/formsweb/WEB-INF/lib/frmsrv.jar:/home/oracle/OraHome_2/jlib/repository.jar:/home/oracle/OraHome_2/jlib/ldapjclnt10.jar:/home/oracle/OraHome_2/jlib/debugger.jar:/home/oracle/OraHome_2/jlib/ewt3.jar:/home/oracle/OraHome_2/jlib/share.jar:/home/oracle/OraHome_2/jlib/utj.jar:/home/oracle/OraHome_2/jlib/zrclient.jar:/home/oracle/OraHome_2/reports/jlib/rwrun.jar:/home/oracle/OraHome_2/forms/java/frmwebutil.jar:/home/oracle/OraHome_2/jdk/jre/lib/rt.jar:/home/oracle/OraHome_2/forms/java/frmall.jar:/home/oracle/OraHome_2/forms/java/irmserver.jar:/home/oracle/OraHome_2/forms/java/frmall_jinit.jar:/home/oracle/OraHome_2/forms/java/RoundedButton.class

 

 

Edición del archivo
formsweb.cfg

 

Este archivo define los
parámetros utilizados por FormServlet, es necesario incluir una sección para
nuestra aplicación

 

[summit]

IE=JInitiator


archive_jini=irmserver.jar,frmall_jinit.jar,RoundedButton.class


userid=summit/summit@orcl

form=customers

ssoMode=false


pageTitle=Summit

splashScreen=no


lookAndFeel=oracle

separateFrame=false

width=994

height=582


serverapp=/summit/summit_reg


envFile=summit.env


serverURL=/forms/lservlet/debug

 

 

Creación del war de
la aplicación

                       

Crearemos un proyecto
utilizando la herramienta JDeveloper, básicamente necesitamos definir una página
jsp para configurar en ella la llamada al applet de Forms e incluir en el
proyecto las imágenes e iconos de la aplicación. Luego generaremos el war y lo
“deployaremos” (publicaremos) en nuestro Oracle Application Server.

 

 

 

Publicación de
la aplicación Summit en Oracle
Application Server

 

  • Primero crearemos la
    instancia OC4J Summit

 

 

  • Luego publicaremos el
    war “summit.war” en la instancia que creamos anteriormente.

 

 

 

 

 

 

 

 

  • Subimos la instancia

 

 

  • Nos conectamos a la
    aplicación

 

 


Instalación y Configuración de Mercury LoadRunner

 

El primer paso es descargar
la herramienta, para esto se puede obtener un trial de la versión 8 de
LoadRunner desde el sitio de Mercury

http://www.mercury.com

Introducción a
LoadRunner

 

LoadRunner es la herramienta desarrollada por Mercury
para ayudar a automatizar los procesos de testing y pruebas de simulación de
carga en aplicaciones cliente-servidor, web y n-capas.

 

Algunos términos empleados
cotidianamente en LoadRunner son:

 

·        
Escenarios
(Scenarios):
Un
escenario es un archivo que define los eventos que ocurren durante una sesión de
testing, basado en requerimientos de desempeño.

·        
Usuarios
Virtuales (Vuser):

Un usuario virtual emula la acción de un actor humano que trabaja con la
aplicación testeada. Durante la ejecución de un escenario LoadRunner reemplaza a
los usuarios humanos con usuarios virtuales. Un escenario puede contener 10, 100
o miles de usuarios virtuales.

·        
Scripts de
Usuarios Virtuales (Vuser scripts):

Un script es una grabación de los pasos ejecutados por un usuario durante su
interacción con la aplicación.

·        

Transacciones (Transactions):

Una transacción representa el proceso de negocio cuyo comportamiento se está
interesado en analizar


 

 

 

Ejecutar el
instalador

 

Instalar LoadRunner es
realmente muy sencillo, usted debe ejecutar el archivo y seguir los pasos como
se ve en las siguientes pantallas

 

 

 

 

 

 

 

Una vez que ha finalizado,
usted debe reiniciar su equipo

 

 

Configuración del
VUG (Virtual User Generator)

 

El VUG es la utilidad de
LoadRunner que nos permite realizar una grabación de una secuencia de
operaciones o pasos en nuestras aplicaciones, para luego poder reproducirlas en
diferentes escenarios de pruebas.

 

  • Como primer paso el
    usuario debe ingresar a “Archivos de programa
    à 
    Mercury…
    à
    Applications

    à
    Virtual User
    Generador (VUG)”

 

  • Una vez que ha accedido
    a la aplicación se presentará una pantalla de bienvenida. En ella debe
    seleccionar “New Multiple Protocol Script” como se muestra en la siguiente
    pantalla.

 

 


  • Del listado de protocolos disponibles seleccionar:

ü      
Oracle NCA

ü      
Web (http)

 

  • Ir al botón de opciones
    y seleccionar las siguientes cajas de texto en las opciones generales
    concernientes a scripts

 

 

  • Verificar que se
    encuentren seleccionados los protocolos NCA y HTPP / HTML

 

  • Verificar la
    configuración de puertos del servidor

 

 

 

  • En las opciones de
    Internet Protocol Recording seleccionar URL-base script

 

 

  • Las opciones avanzadas
    deben dejarse como sigue

 

 

  • La pantalla de
    correlaciones debería dejarse así:

 

 

  • A continuación se
    presentará la pantalla de “Star Recording”, en ella se tiene que seleccionar
    el tipo de acción y llenar la información

ü      
Tipo de
aplicación: Internet ó Cliente / Servidor

ü      

Program to record: Programa a monitorear

ü      
URL Address:
Dirección de la aplicación a monitorear

ü      
Working
directory: Directorio de trabajo

 

  • Al presionar ok se
    empezará con la grabación
  •  

 

  • Se presentará la
    pantalla inicial de nuestra aplicación

 

  • Realizamos varias
    acciones sobre la pantalla

 

 

 

  • Finalmente detenemos la
    grabación y empezará a generarse automáticamente el script

 

 

  • Finalmente podemos ver
    el resultado de la creación del script

 

Edición de los
scripts generados con el VUG

 

A continuación deberemos
realizar algunas ediciones al script que generamos en el paso anterior.

Parámetro jsessionid
y variable NCAJSerSessionID

 

Esta guarda el ID de la
sesión NCA/HTML con la que se conectó el usuario al momento de la grabación. Una
sesión HTML es única por tanto para reproducir posteriormente la grabación
debemos hacer que el parámetro jsessionid tome el valor de la variable
NCAJSerSessionID en cada iteración. Para esto debemos ubicar al parámetro dentro
del script y editarlo como se muestra en las siguientes pantallas.

 

 

 

 

 


Creación de parámetros para el script

 

La grabación generada nos
guarda todas las acciones y eventos que generamos sobre la aplicación. Suponga
que usted desea editar el valor de un usuario ó el valor de una cuenta ó una
cantidad cualquiera, entonces es necesario ubicar el valor en el texto del
script y convertirlo en un parámetro.

 

 

Nos posicionamos sobre el
valor y damos clic derecho

 

 

Se mostrará una pantalla emergente donde debemos
especificar el nombre del parámetro y su tipo, luego presionar el botón
“Properties”

 

 

 

Se muestra la pantalla de
configuración de propiedades del parámetro

 

 

Presionamos el botón de
“Create Table”

 

 

Se mostrará la pantalla
actualizada con el primer valor del parámetro que estamos definiendo

 

 

Presionando el botón “Edit with Notepad” podemos editar
la tabla de parámetros y sucesivamente añadirle nuevos valores.

 

 

 

Cerramos esta pantalla y
volveremos a la pantalla principal, notaremos como se muestra el parámetro en
nuestro script

 

 

Acto seguido podemos
almacenar a nuestro script con un nombre

 

 

 

Ejecución de un
escenario con LoadRunner

 

Es necesario iniciar el
LoadRunner Controller, para esto debe dirigirse a “Archivos de Programa\Mercury
LoadRunner\LoadRunner”

 

 

Se mostrará la pantalla de
inicio de la herramienta.

 

 

Para ejecutar un escenario
seleccionar “Run Load Tests”

 

 

Seleccionamos el script de
Summit

 

 

Luego presionamos “ok” y  se
mostrará la pantalla inicial de ejecución del escenario

 

 

Presionamos el botón “Star
Scenario”

 

 

Como nuestra licencia es temporal y hemos excedido el
número máximo de usuarios permitidos (10) se presentará una ventana con un
mensaje de advertencia.

 

 

A continuación la herramienta empezará a ejecutar el
escenario y a enviar información a los monitores configurados

 

 

 

Mostrando el comportamiento
y concurrencia de los usuarios virtuales así como estadísticas a nivel de hits
por segundo en la capa http

 

 

Finalmente podremos
visualizar un sumario con la información resumen de le ejecución del test

 

 

 

 

 


Conclusiones

 

·        
Este documento no es un sustituto para la realización de su propio
benchmarking pero constituye una guía inicial para ayudar a determinar la
escalabilidad de una aplicación.

 

  • Cada aplicación es
    diferente, los criterios proporcionados por Oracle permiten en cierta forma
    ubicar a las aplicaciones de Forms en una clasificación en función del
    tamaño de los archivos, número de canvas, windows y formas abiertas en forma
    simultánea.

 

  • Antes de la realización
    de una prueba se debe contar con un ambiente estable y se debe esquematizar
    previamente el respectivo plan de pruebas.

 

  • Ninguna prueba de stress
    está completa si paralelamente no se realizan esquemas de ajuste a la
    configuración de los servidores y servicios involucrados. Estas acciones no
    están contempladas en el presente documento.

 

  • Existen otros esquemas
    en Oracle Forms como la activación de trazas a nivel de servidor y la
    activación de las estadísticas del sistema que no se han mencionado pues el
    objetivo era realizar una inducción a la herramienta LoadRunner.


Bibliografía

 

  • Oracle
    Corporation, Oracle Forms Services Release 6i Capacity Planning Guide
  • Oracle
    Application Server (OAS) 10G, Online Documentation
  • Mercury,
    LoadRunner UserGuide

 


 




[1]

Sensación del usuario que le indicará que a su percepción la aplicación
empieza a hacerse más lenta

1 Comentario

Dejar respuesta

Please enter your comment!
Please enter your name here