Testeando
Aplicaciones Oracle Forms 10G con Load Runner.
Degradación del Desempeño (Performance)
Oracle Summit: la aplicación a testear
Arquitectura de la
aplicación a testear
Configuración de la aplicación Summit con Forms 10G
Creación del usuario “summit” en la base Oracle
10G
Cambios realizados a las formas de la aplicación Summit para emplearla con
Oracle Forms 10G
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
Esquema de Funcionamiento de LoadRunner
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
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.
|
|
|
|
|
Hardware |
Máquina
Pentium RAM 4GB HD 40 GB |
Máquina
Pentium
RAM 1.5 HD 70 GB |
|
Software |
Oracle
Release
Linux |
Oracle
Release
Linux |
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
Me parece excelente elaporte solo que no veo la mayoria de las imagenes por que se ven negras