Contenido


Prácticas Probadas de IBM Business Analytics

IBM Cognos BI JMeter Stability Package

Producto(s): IBM Cognos BI 10.2; Área de Interés: Rendimiento

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Prácticas Probadas de IBM Business Analytics

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Prácticas Probadas de IBM Business Analytics

Manténgase en contacto por contenidos adicionales de esta serie.

Propósito del documento

Este documento acompaña a un archivo que representa un plan de prueba de Apache JMeter para analizar una instalación de IBM Cognos BI Server para estabilidad bajo una carga dada. Después de brindar algunos antecedentes de la herramienta y presentar suficiente conocimiento sobre la ejecución de informes de IBM Cognos BI de forma que se pueda comprender el ámbito de la prueba y sus funciones, este documento brindará detalles sobre cómo utilizar Apache JMeter para ejecutar el plan de prueba suministrado y configurarlo para un entorno dado. Con base en recomendaciones de buenas prácticas con relación a la ejecución de la prueba, se suministran guías para la interpretación de resultados junto con consejos para la resolución de problemas.

El plan de prueba y el proceso descrito en este documento se ha utilizado con éxito en una cantidad de fidelizaciones de clientes y en instancias de pruebas de escalabilidad dirigidas por IBM Cognos y, por lo tanto, se considera una Buena Práctica.

Este plan de prueba de estabilidad es un buen comienzo siempre que la respuesta a cualquiera de las siguientes preguntas sea "sí",

  • No hay disponible otro software de pruebas de carga y estabilidad como Rational Performance Tester o Mercury LoadRunner.
  • El sistema muestra un comportamiento inestable bajo carga, las solicitudes fallan, los tiempos de respuesta son lentos, ocurren mensajes de error inesperados y/o se necesita un mecanismo para forzar que los errores ocurran y poder así solucionar los problemas.
  • Se necesita verificar la estabilidad y carga de la instalación de IBM Cognos BI antes de moverla a la siguiente fase de release como Pruebas o Preproducción.
  • Se desea probar la escalabilidad y se necesitan respuestas rápidas sobre el impacto de rendimiento de los cambios de configuración o de la arquitectura (como añadir otra instancia de Servicio de Informes).

Aplicabilidad

El plan de prueba debe ser ejecutado por JMeter versión 2.7 o superior, pero se recomienda JMeter 2.9. El plan no es compatible con versiones anteriores de JMeter.

JMeter está disponible en casi todas las plataformas, ya que es una herramienta basada en Java y, por lo tanto, el plan puede ser ejecutado también en todas las plataformas de JMeter admitidas.

El plan de prueba se ha probado recientemente en diversos sistemas operativos y configuraciones y está diseñado para IBM Cognos BI 10.2.0 únicamente. Es adecuado para pruebas sin importar la topología de configuración, la mezcla de sistemas operativos o los bits en uso. El uso de Cognos Application Firewall (CAF) es completamente compatible, ya que es una buena práctica y se recomienda ampliamente dejar CAF habilitado en todo momento.

Exclusiones y Excepciones

El plan de prueba presentado como parte de este paquete se diseñó para releases de servidor de IBM Cognos BI específicos. Ejecutarlo en otras versiones de IBM Cognos BI no necesariamente funcionará, debido a cambios más o menos sutiles para las solicitudes, su sintaxis de carga útil y sus características específicas, las cuales pueden cambiar de versión a versión. Utilice el plan para versiones explícitamente listadas en este documento únicamente. Existen versiones previas de este paquete de estabilidad para versiones anteriores de IBM Cognos BI.

El plan de prueba actualmente ejecuta informes de los paquetes de muestra suministrados con el producto en IBM Cognos Viewer. Este incluye

  • informes de Compatible Query Mode (CQM)
  • informes de Dynamic Query Mode (DQM)
  • informes de Dynamic Cube (DYNC)
  • Cognos Workspaces (consulte el plan para obtener más detalles)

Este no admite lo siguiente

  • Ejecutar cualquiera de los Studios
  • Active Reports
  • Gateways habilitados de SSL
  • Inicio de Sesión Único para autenticación

El plan de prueba se suministra "tal como está" y su único propósito es brindar un medio rápido, versátil, flexible y gratuito para verificar la estabilidad de una instalación posiblemente compleja de IBM Cognos BI Server y su estabilidad en situaciones de carga. No hay soporte formal para este plan. Si está interesado en ejercicios de ajustes detallados de rendimiento y pruebas de carga individuales, contacte a su representante de IBM Cognos.

El plan de prueba se considera como un punto de partida para observar la estabilidad y la operación del sistema en entornos complejos. Cualquier análisis más serio, en particular con relación al rendimiento, debe ser parte de un compromiso de IBM Services y debe realizarse mediante una herramienta de pruebas de carga comercial como IBM Rational Performance Tester. Aunque los resultados de ejecutar el plan de prueba suministrado pueden brindar indicadores valiosos sobre los problemas de configuración de IBM Cognos BI, la configuración y ajustes de terceros necesarios y los posibles problemas de estabilidad, siempre debe llevar esos indicadores a IBM para interpretarlos y para solucionar cualquier problema. IBM Cognos BI es un producto complejo, y los resultados o los problemas que puedan surgir por ejecutar el plan de prueba pueden no siempre estar relacionados con una sola razón específica y frecuentemente requieren de un extenso conocimiento de la arquitectura y el flujo del proceso de IBM Cognos BI para interpretar los resultados correctamente. Se recomienda buscar los mensajes de error encontrados en los sitios web de IBM Information Center y de IBM Cognos Support.

Suposiciones

Se asume que el lector está familiarizado con los conceptos descritos en IBM Cognos BI Architecture and Security Guide, en particular con los componentes y servicios de IBM Cognos BI.

Antecedentes

Esta sección brinda algunos antecedentes sobre la herramienta JMeter y el proceso de ejecución de informes de IBM Cognos BI, los cuales son necesarios para comprender las implicaciones que pueden descubrir la ejecución de este plan y sus resultados.

Apache JMeter

JMeter es una herramienta basada en Java, desarrollada en un proyecto de software de código abierto de la organización Apache. Su propósito es emitir solicitudes para un servidor y recolectar y registrar la respuesta. JMeter admite HTML, XML, SOAP, JDBC y otros tipos de solicitudes. Puede ejecutar múltiples hebras paralelas y, por lo tanto, simular múltiples clientes en un sistema. Permite crear planes de prueba manualmente o mediante el registro de solicitudes de una sola sesión de cliente a través de algún proxy. Los planes pueden enriquecerse con lógica programática como ejecución condicional, análisis de respuesta mediante expresiones regulares y mucho más.

El inicio de la herramienta JMeter puede encontrarse en la sección Resources en el fondo de este documento. JMeter se está desarrollando activamente, lo que significa que aparecen nuevas versiones disponibles de vez en cuando. Aunque las nuevas versiones aseguran ser compatibles con las anteriores, se recomienda utilizar la versión más reciente para beneficiarse de las correcciones de errores y las mejoras de rendimiento, así como de las funcionalidades añadidas. Para obtener más detalles sobre el uso de JMeter y lo que hace cada uno de los elementos en un plan, consulte la documentación de JMeter (vea la sección Resources).

JMeter utiliza un concepto conocido como un Grupo de Hebras para simular un conjunto de clientes que se ejecutan a través de una secuencia determinada de pasos. Un cliente individual es representado por una hebra individual, lo que se repite de forma secuencial a través de pasos definidos. Un Grupo de Hebras mantiene una cantidad configurable de estas hebras de cliente. Un plan de prueba individual puede definir múltiples Grupos de Hebras que después pueden ejecutarse en distintas instalaciones de JMeter en hosts separados. Sin embargo, actualmente no es posible bifurcar múltiples hebras desde una etapa de un plan, funcionalidad que sería necesaria para, por ejemplo, simular solicitudes de tipo AJAX en páginas de HTML.

IBM Cognos BI Report Execution

IBM Cognos BI utiliza el concepto de conversaciones al ejecutar informes de cualquier tipo. Una conversación es una operación que consiste en múltiples pasos, y cada paso es técnicamente una solicitud individual. Ejecutar así un informe se convierte en una serie de solicitudes y respuestas, en lugar de una sola solicitud con una sola respuesta.

Las conversaciones inician con una solicitud primaria y pueden tener varias solicitudes secundarias que pertenezcan a la misma conversación. Cada conversación comienza en modo de sincronía , lo que significa que el remitente (el cliente) de la solicitud espera a que el destinatario (el servicio al que se dirige) responda.Durante ese tiempo, el cliente se bloquea. Como esto es ineficiente si se mantiene por más de unos segundos, existe un tiempo de espera configurable conocido como el Umbral de Espera Primario (PWT), después del cual una conversación entrará en modo asíncrono . En ese momento, la secuencia de solicitudes cambia.

Cuando la conversación entra en modo asíncrono, el cliente tendrá que enviar solicitudes secundarias con intervalos específicos para mantener activa la conversación. Si esas solicitudes secundarias cesan, el servicio receptor dejará de procesar la solicitud actual y la conversación finalizará con un error en lugar de un resultado. De forma predeterminada, la solicitud secundaria tiene un tiempo de espera excedido de 30 segundos. Este tiempo de espera excedido se conoce como el Umbral de Espera Secundario (SWT). Cada 30 segundos el cliente necesita enviar una solicitud de espera para el mismo servicio a fin de mantener la conversación viva e indicar que sigue esperando el resultado. El servicio de destino continúa procesando y señaliza cuando ha completado el procesamiento de la solicitud actual y el resultado puede ser recuperado por el cliente. La cantidad de repeticiones de las solicitudes de espera que serán necesarias dependerá completamente de los recursos del sistema. Si la carga del sistema es alta, es decir, si hay muchos usuarios concurrentes, el sistema podría requerir más tiempo para procesar una sola conversación del que requeriría si solo hubiera un usuario utilizando el sistema. Es decir que cada conversación se verá potencialmente distinta al nivel de HTML en cada ejecución según la carga real del sistema.

Esta es la principal razón por la que no se puede simplemente registrar una ejecución de informe de IBM Cognos BI con alguna herramienta como JMeter o Rational Performance Tester y volverla a reproducir para una prueba. Si una solicitud primaria no se responde dentro del límite de tiempo de PWT, la conversación tendrá que entrar en modo asíncrono, pero si esto no se registra, la solicitud fallará. Cada conversación puede ser distinta en la cantidad de solicitudes necesarias cada vez que se ejecute.

Todo esto se refleja en las solicitudes que conforman una conversación. Si el cliente es un navegador que ejecuta la herramienta de IBM Cognos Viewer, el manejo de la conversación es realizado por JavaScript intercalado en las páginas de HTML que conforman la herramienta de IBM Cognos Viewer. Si el cliente es un programa del SDK de IBM Cognos, el manejo de la conversación tiene que ser implementado por el cliente mismo. Esto se aplica también para el plan de JMeter. Hasta este punto, el plan de JMeter tiene que imitar la funcionalidad de JavaScript mediante la realización de variables específicas de formulario de HTML y de reaccionar dinámicamente a su contenido junto con las respuestas del servidor.

Las conversaciones se utilizan siempre que algo se ejecuta , por ejemplo, informes, agentes, análisis y espacios de trabajo. Cuando los servicios de IBM Cognos interactúan entre ellos, las conversaciones también suceden y cada uno de los servicios implementa el lado del cliente del manejo de la conversación.

Los detalles del procesamiento de conversaciones en una aplicación de cliente son cubiertos en IBM Cognos SDK Developer Guide, que es parte del SDK de IBM Cognos. Sin embargo, para el propósito de este documento, la información anterior es suficiente.

Preparación del entorno

Consideraciones de configuración del entorno de prueba

La ejecución de una prueba de JMeter tiene algunas implicaciones con relación a la herramienta misma y a la configuración de IBM Cognos BI.

Dónde instalar JMeter

Durante la prueba, la aplicación de JMeter simulará a clientes concurrentes mediante la conexión a IBM Cognos BI con un cliente de HTTP. JMeter genera una hebra para cada sesión de cliente simulada (usuario concurrente) de forma que sean necesarios recursos suficientes con relación al CPU y a la RAM para evitar cuellos de botella en el lado de JMeter. Las plataformas que brindan soporte rápido de hebras, como Linux, normalmente tendrán un mejor rendimiento para esta tarea y mayores cantidades de RAM impactarán aún más de forma positiva el rendimiento de JMeter debido a los conmutadores de contexto que se están atendiendo desde la memoria. Como regla general, las velocidades de CPU de 1,5 GHz y superiores, así como los tamaños de RAM de al menos 2GB son adecuados para ejecutar JMeter en un escenario que simule unos 30 clientes, aunque los requisitos reales dependen de la cantidad de clientes que deberán simularse. Estas son recomendaciones basadas en la experiencia y no a través de pruebas formales a gran escala.

Para obtener el máximo de la prueba, la aplicación de JMeter debe ejecutarse en una máquina separada donde no haya componentes de IBM Cognos BI o bases de datos instalados. Como se mencionó anteriormente, según la cantidad de usuarios que desee simular, puede haber una gran cantidad de hebras y sockets en uso, lo cual puede impactar significativamente en el rendimiento de la máquina y, si la caja también está ocupada ejecutando componentes de IBM Cognos BI, añadir la demanda adicional de recursos de JMeter no es una buena idea.

Implementación de IBM Cognos BI Gateway

Al simular muchos clientes que acceden a IBM Cognos BI a través de un gateway, hay que estar conscientes de una cosa. Si se utiliza un gateway de CGI, el servidor web generará una instancia de CGI ejecutable por cada sesión de cliente, y cada instancia será un proceso separado con su propia memoria y sus propios recursos. Por lo tanto, se recomienda seguir la buena práctica de aprovechar las implementaciones de IBM Cognos BI Gateway que no son de CGI (MOD, MOD2 o MOD2_2 para servidores web de Apache o ISAPI para Microsoft IIS), ya que proporcionan un uso más óptimo de recursos y están específicamente codificadas para el rendimiento. Los gateways de CGI son genéricos y compatibles con todos los servidores web, pero no son adecuados para sistemas de producción y aún menos para sistemas expuestos a cargas pesadas. El plan de prueba funcionará con cualquier IBM Cognos BI Gateway así como directamente en un IBM Cognos Dispatcher, pero simular muchas (> 30) sesiones de cliente concurrentes puede sobrecargar todo su punto de entrada.

Utilizar herramientas de supervisión

Al probar con el plan suministrado, se recomienda observar cuidadosamente los recursos consumidos en el nivel del sistema operativo y en la consulta y/o en la base de datos de Content Manager. Imponer una carga más alta en el sistema puede identificar cuellos de botella o retos que no había visto antes. Debe tener suficiente acceso y privilegios para ejecutar herramientas de administración tales como IBM DB2 Control Center, IBM Data Studio, Oracle Enterprise Manager, Microsoft SQL Enterprise Console y diversos comandos de supervisión del sistema operativo.

Inicie un navegador en una máquina separada y utilice la herramienta de IBM Cognos Administration para supervisar cosas tales como:

  • cantidad de procesos de Servicio de Informes generados
  • cantidad de hebras abiertas para cada proceso de Servicio de Informes
  • cantidad de hebras abiertas para IBM Cognos BI Services
  • cantidad de conexiones a la BD de consultas y de depósito de contenido
  • consumo de memoria en el Gestor de Contenido y en los Asignadores
  • cantidad de tareas interactivas
  • consumo de memoria del proceso de Servicio de Consultas
  • Relación de aciertos/desaciertos del caché de Dynamic Cubes

Esta no es una lista completa, pero proporciona un inicio razonable. Para una supervisión más detallada de IBM Cognos BI con Java Monitoring Extensions (JMX), consulte el enlace System Management Methodology proporcionado en la sección Resources.

Implementación de los Requisitos Previos

Instalar JMeter

JMeter es una herramienta basada en Java y necesita tener un Java Runtime Environment (JRE) funcional para ejecutar JMeter. JMeter 2.7 en adelante requiere al menos JRE 1.6. Después de que se instale JMeter, necesita configurarlo para utilizarlo con el JRE adecuado. Se pueden encontrar más detalles sobre los requisitos previos de JMeter y una guía de inicio sobre su instalación y uso en el JMeter User Manual (vea la sección Resources).

El desarrollo de esta versión del plan se realizó con JMeter 2.7 y 2.9 mediante IBM JRE 1.6.0 64-bit en Red Hat Enterprise Linux y Microsoft Windows 2008-64.

Instalar los paquetes de muestra de IBM Cognos BI necesarios

El plan de prueba proporcionado con este documento ejecuta informes de los siguientes despliegues de muestra suministrados con IBM Cognos BI.

  • IBM_Cognos_Samples
    Paquetes de Go Data Warehouse (consulta), GO Data Warehouse (análisis) y Go Sales Query
  • IBM_Cognos_Samples_DQ
    Paquetes de GO Data Warehouse (análisis) y Go Sales Query
  • IBM_Cognos_Power_Cube
    Paquete de Sales and Marketing (cubo)
  • IBM_Cognos_DynamicCube
    Paquete de Go Data Warehouse Sales

Si un cierto tipo de informe no debe probarse, las muestras del despliegue de muestra correspondiente pueden ser omitidas.

Aunque los paquetes de GO Data Warehouse y el paquete de GO Sales utilizan orígenes de datos relacionales que pueden requerir algo de configuración adicional, el paquete de Sales and Marketing se basa en un IBM Cognos PowerCube y no se necesita configuración adicional.

Las instrucciones de instalación para los paquetes de muestra relacionales y de PowerCube pueden encontrarse en el Apéndice D de IBM Cognos 10.2 Installation and Configuration Guide o en línea en el Information Center para IBM Cognos 10.2 en
http://pic.dhe.ibm.com/infocenter/cbi/v10r2m0/topic/com.ibm.swg.ba.cognos.inst_cr_winux.10.2.0.doc/c_settingupsamplesbi.html?path=0_16_23_2#SettingUpSamples

Las instrucciones de instalación para configurar las muestras de cubo dinámicas pueden encontrarse en el Capítulo 3 de Dynamic Query Guide o en línea en el Information Center para IBM Cognos 10.2 en
http://pic.dhe.ibm.com/infocenter/cbi/v10r2m0/topic/com.ibm.swg.ba.cognos.ig_rolap.10.2.0.doc/C_ig_rolap_sample_setup.html

Configuración del plan de prueba

Después de que haya iniciado JMeter y cargado el plan de prueba, se le presentará la interfaz de usuario de JMeter. Como se muestra en la Ilustración 1, el panel izquierdo le permite explorar el plan de prueba en una estructura de árbol jerárquica. Las propiedades y los valores del elemento seleccionado en el panel izquierdo se presentarán en el panel derecho.

Ilustración 1: Árbol expandido de JMeter de los elementos del plan de prueba
Illustration 1: JMeter expanded tree of test plan elements
Illustration 1: JMeter expanded tree of test plan elements

JMeter expande todos los elementos en el panel de árbol de forma predeterminada a partir de la versión de 2.1.2. Este comportamiento predeterminado hace que obtener una visión general del plan de prueba sea más difícil, así que se recomienda decirle a JMeter que no expanda todos los elementos en el inicio. Para hacer esto, inicie JMeter con el conmutador de línea de comandos -Jonload.expandtree=false o edite el archivo jmeter.properties y añada la línea onload.expandtree=false.

Una vez que se abre JMeter, expanda el nodo del nivel superior IBM Cognos 10.2.0 – Paquete de BI Stability el cual mostrará otro nodo con el mismo nombre. Expanda este también. Ahora, expanda el elemento Overall Tests y tendrá una buena visión general del plan, como se muestra en la Ilustración 2.

Ilustración 2: Árbol colapsado de JMeter de los elementos del plan de prueba con las solicitudes de inicio de sesión/cierre de sesión, las solicitudes que se ejecutarán y las propiedades de configuración resaltadas por marcos de colores
Illustration 2: JMeter collapsed tree of test plan elements with the logon/logoff requests, the requests to be executed and configuration properties highlighted by colored borders
Illustration 2: JMeter collapsed tree of test plan elements with the logon/logoff requests, the requests to be executed and configuration properties highlighted by colored borders

Una vez que todos los elementos del segundo nivel se hayan colapsado, esto brindará una buena visión general de la estructura del plan de prueba. Existen cuatro elementos generales de configuración, un elemento superior que contiene todos los pasos del plan de prueba y dos elementos involucrados con la visualización de los resultados de la prueba.

En la Ilustración 2, el elemento de configuración principal Test configuration Parameters (resaltado en rojo) se involucra cuando se ajusta el plan a un entorno específico mediante la edición de sus propiedades (resaltadas en amarillo). Se brindarán más detalles sobre estas propiedades de configuración en la sección Configurar Parámetros . La prueba misma presenta dos elementos que manejan las solicitudes de inicio de sesión y de cierre de sesión (resaltados en verde), que serán explicados en la sección Configurar Parámetros , y quince elementos que ejecutan un informe (resaltado en azul claro), que serán discutidos en la siguiente sección.

Entender la estructura del plan e inhabilitar pruebas específicas

El plan de prueba ejecuta quince informes distintos con distintos formatos de salida. Algunos de los informes incluyen las solicitudes. A continuación se muestra la lista de ejecución de informes junto con algunos detalles sobre cada ejecución de informes con relación al formato de salida y a los pasos realizados. Tenga en cuenta que las gráficas y la salida binaria como Excel, CSV o PDF son representadas por el Servidor de Informes y secuenciadas al cliente como un archivo binario en respuesta a una solicitud de GET explícita. En un navegador esto sería realizado por iframe(s) o JavaScript, y emitiría esas solicitudes de GET para un servicio particular que proporciona esos elementos desde cachés internos en los que han sido creados.

Los informes que usan Dynamic Query Mode (DQM) comienzan en el elemento 10, los informes que se hacen en Dynamic Cubes (DYNC) comienzan en el elemento 20 y los informes de Workspace comienzan en el elemento 30.

  1. Budget contra Actual, GO Data Warehouse (análisis)
    • Se ejecuta en formato HTML.
    • No involucra solicitudes.
    • Operación de One Next Page, una vez que la primera página es atendida.
    • Un informe muy simple de todas las tablas.
  2. Order Invoices - Donald Chow, Sales Person, GO Sales (consulta)
    • Se ejecuta en formato PDF.
    • No involucra solicitudes.
    • El PDF (257 páginas) se recupera del Content Store.
    • Un informe básico de lista que es algo grande con un poco de diseño y personalización de marca.
  3. Planned Headcount, GO Data Warehouse (análisis)
    • Se ejecuta en formato HTML.
    • No involucra solicitudes.
    • Un informe que contiene 5 gráficas será representado. El plan descargará las representaciones de GIF individuales de las gráficas para simular la visualización de la salida del informe de HTML.
  4. Global Bonus Report, Go Data Warehouse (análisis)
    • Se ejecuta en formato HTML.
    • Tiene una página de solicitud con dos parámetros, Year y Region. Los valores utilizados son 2005 para Year y Americas para Region.
    • Un informe de lista.
  5. Pension Plan, GO Data Warehouse (consulta)
    • Se ejecuta en formato CSV.
    • Sin solicitudes.
    • Un informe de lista con bastantes datos.
  6. Recruitment Report, GO Data Warehouse (análisis)
    • Se ejecuta en formato XLWA.
    • Tiene una página de solicitud con un parámetro, Year. El valor utilizado para Year es 2006.
    • Un informe que contiene varias gráficas y una tabla.
  7. Historical Revenue, Sales and Marketing (cubo)
    • Se ejecuta en formato HTML.
    • Tiene dos páginas de solicitud con un parámetro cada una. La primera página de solicitud toma el año para ejecutar el informe y la segunda página de solicitud es para proporcionar el mes del año seleccionado en la primera página de solicitud. Los valores utilizados son 2006 para el año y June para el mes.
    • Un informe de gráfica individual donde la gráfica es recuperada explícitamente por una solicitud de GET separada.
  8. Customer Returns and Satisfaction, GO Data Warehouse (análisis)
    • Este es un informe de Dynamic Query Mode.
    • Se ejecuta en formato HTML.
    • No tiene página de solicitud, pero una operación de Next Page se realiza una vez que la primera página de resultados está disponible.
    • Un informe que contiene dos gráficas y dos listas, las gráficas se recuperan explícitamente por una solicitud de GET separada.
  9. Return Quantity by Order Method, GO Data Warehouse (análisis)
    • Este es un informe de Dynamic Query Mode.
    • Se ejecuta en formato XLWA.
    • Contiene una tabla cruzada individual.
  10. Employee Training by Year, GO Data Warehouse (análisis)
    • Este es un informe de Dynamic Query Mode.
    • Se ejecuta en formato HTML.
    • Tiene dos páginas de solicitud, la primera página solicita un año y la segunda página solicita un trimestre de ese año. Los valores utilizados son 2012 para el año y 3 para el trimestre.
    • Un informe que contiene una gráfica y una tabla cruzada. La gráfica se recupera con una solicitud de GET separada.
  11. Order Invoices – Donald Chow, GO Sales (consulta)
    • Este es un informe de Dynamic Query Mode.
    • Se ejecuta en formato PDF.
    • No tiene página de solicitud.
    • Un informe que contiene una lista más grande y, ya que es un PDF, todos los datos de resultados deben ser cargados.
  12. Ingresos por método de pedido y región, GO Data Warehouse Sales
    • Utiliza un Dynamic Cube.
    • Se ejecuta en formato PDF.
    • No tiene página de solicitud.
    • Un informe pequeño que contiene una sola tabla cruzada. Ideal para incrementarse proporcionalmente.
  13. Ingresos por minorista y línea de productos, GO Data Warehouse Sales
    • Utiliza un Dynamic Cube.
    • Se ejecuta en formato HTML.
    • No tiene página de solicitud, pero una operación de Next Page se realiza una vez que la primera página de resultados está disponible.
    • Un informe que contiene una lista más grande.
  14. Carpeta Sales by Year Workspace, Cognos Workspace Samples
    • Este es un informe de Workspace.
    • Contiene 9 Widgets de los cuales 6 producen gráficas.
    • Los Widgets se ejecutan de forma secuencial, las gráficas se recuperan explícitamente con una solicitud de GET separada.
  15. Carpeta Marketing Workspace, Cognos Workspace Samples
    • Este es un informe de Workspace.
    • Contiene 6 Widgets, de los cuales 3 producen gráficas más una tabla cruzada.
    • Los Widgets se ejecutan de forma secuencial, las gráficas y la tabla cruzada se recuperan explícitamente con una solicitud de GET separada.

El plan de prueba se muestra en una estructura de árbol jerárquica. El elemento superior es Overall Test el cual contiene todos los subelementos. Los subelementos están numerados y los elementos 00 y 99 se utilizan para autenticación únicamente (consulte la sección Configurar la Autenticación para obtener más detalles). El resto de los elementos ejecuta un informe específico o Workspace. Si desea excluir un informe de la prueba, esto se puede hacer fácilmente mediante un clic con el botón derecho en el elemento para seleccionar Disable en el menú contextual (consulte la Ilustración 3). Esos informes se saltarán al ejecutar la prueba.

Ilustración 3: Menú contextual del clic con el botón derecho de JMeter mostrando la opción Disable para el elemento seleccionado
Illustration 3: JMeter's right-click context menu showing the Disable option for the selected element
Illustration 3: JMeter's right-click context menu showing the Disable option for the selected element

Verá el elemento inhabilitado en color gris en el panel de árbol izquierdo. Puede volver a habilitar este elemento si accede al mismo menú contextual nuevamente mediante un clic con el botón derecho en él para seleccionar Enable. Versiones recientes de JMeter introdujeron la acción Toggle , la cual tiene un cómodo atajo (CTRL + T) para conmutar un elemento entre habilitado e inhabilitado.

Ya que el plan de prueba puede percibirse como un árbol jerárquico, un elemento o nodo puede contener otros nodos que se vuelven elementos hijos en ese contexto. La parte del plan de prueba que ejecuta informes es un elemento individual etiquetado como “Overall Tests” del tipo controlador de transacción. Esto básicamente significa que todos sus elementos hijos se tratan como una sola transacción con relación a medir el tiempo de ejecución y el resultado. Este elemento superior tiene un subelemento numerado por informe ejecutado durante la prueba, y todos estos subelementos por cada informe son del tipo controlador de transacción. Esto permite obtener un tiempo total general para todos los pasos de la conversación con la ejecución del informe específico, sin importar los detalles y pasos del informe. Como un ejemplo, considere un plan que se ha configurado solo para ejecutar los subelementos 01 y 02. En este caso, los controladores de transacción proporcionarían un tiempo total para la ejecución de todos los pasos requeridos para ejecutar Report_1, un tiempo total para la ejecución de todos los pasos requeridos para ejecutar Report_2 y un tiempo total general para la prueba completa.

Al final del plan de prueba, encontrará dos elementos Listener . Estos elementos registrarán todas las solicitudes, la respuesta y presentarán los datos en una forma familiar para el usuario. El elemento View Result Tree presentará una vista de árbol de las solicitudes del plan que se están emitiendo y el elemento Aggregate Report mostrará una vista similar a un informe de lista. La sección titulada Interpretación de Resultados tiene más detalles sobre estos elementos Listener. Elementos Listener adicionales pueden añadirse con un clic con el botón derecho desde la categoría Listener. Las opciones incluyen gráficos y vistas estadísticas. Consulte la documentación de JMeter para obtener más detalles.

Configurar Parámetros

El elemento etiquetado Test configuration Parameters es uno de los dos lugares que necesitarán editarse para configurar el plan para un entorno dado. Normalmente, hay cinco parámetros que necesitan especificarse y adaptarse para ajustarse a un entorno dado.

  • Nombre del servidor
    Especifique el NetBIOS o el nombre de servidor completamente calificado para su punto de entrada para IBM Cognos BI. Este puede ser cualquier Gateway o un URI de Asignador externo.
  • Puerto
    El puerto de red para el punto de entrada.
  • url
    El URL para el punto de entrada de IBM Cognos BI. Esto normalmente es todo lo que sigue al nombre del servidor e incluye un carácter “/” principal. Para un Gateway de IBM Cognos, la forma es /<alias>/cgi-bin/<gateway_executable>. Por ejemplo, /ibmcognos/cgi-bin/mod2_2_cognos.so. Para un Asignador de IBM Cognos BI, la forma es /<context_root>/servlet/dispatch/ext. Por ejemplo, /p2pd/servlet/dispatch/ext
  • Espacio de nombres
    Esta es la propiedad de ID del espacio de nombres utilizado para autenticación, si existe, para el producto de IBM Cognos BI. Si hay múltiples espacios de nombres configurados, solo uno puede ser elegido, ya que la autenticación para múltiples espacios de nombres no es admitida por el plan. El ID del espacio de nombres puede obtenerse de la Configuración de IBM Cognos. Si desea ejecutar sin autenticación, deje esto en blanco. Consulte la sección Configurar la Autenticación para obtener más detalles.
  • Templocation
    A partir de IBM Cognos BI versión 10.1, los objetos temporales para la ejecución de informes se almacenan en el sistema de archivos local en lugar de en el Almacén de Contenido. Esto significa que de forma predeterminada las gráficas, los gráficos y otras salidas binarias que sean parte del informe se almacenan en la carpeta temporal de Cognos configurada localmente mediante la Configuración de IBM Cognos en lugar de almacenarlas en el Almacén de Contenido, como era el caso en IBM Cognos 8 BI. Esto afecta los URL utilizados para recuperar esas partes al mostrar el informe. El plan de prueba tiene que utilizar los valores que coincidan con la configuración de IBM Cognos 10 BI para poder recuperar las gráficas y las salidas binarias. Si esta propiedad no se establece correctamente, no habrá ninguna muestra etiquetada “Retrieve graph output” en el visor de árbol de resultados. Aunque esto no hace que el plan de prueba falle, puede desviar los resultados o evitar la detección de fallas del Servicio de Gráficas para representar la gráfica, ya que las gráficas faltantes no serán anticipadas. Siempre establezca Templocation con un valor de FS a menos que IBM Cognos 10 BI se haya configurado para utilizar el Almacén de Contenido para estos objetos temporales, en cuyo caso Templocation debe establecerse con un valor de CM. La Ilustración 4 muestra el valor de la propiedad Temporary objects location en la herramienta IBM Cognos Administration.
    Ilustración 4: IBM Cognos Administration muestra Temporary object location establecida con el valor predeterminado de Server File System
    Illustration 4: IBM Cognos Administration showing for the Temporary object location being set to the default value of Server File System
    Illustration 4: IBM Cognos Administration showing for the Temporary object location being set to the default value of Server File System

Existen parámetros adicionales que se utilizan para algunos dispositivos más avanzados. Normalmente no necesitaría cambiar estos parámetros, pero pueden ajustarse si entiende el impacto del cambio.

  • Outputlocale
    Con estos valores, puede especificar la salida local para las salidas de informes, alterando temporalmente la salida local especificada en el perfil de la cuenta de usuario de IBM Cognos 10 BI utilizada por el plan de prueba para iniciar sesión.
  • pwt
    Esto especifica el Umbral de Espera Primario (PWT) para la conversación de ejecución de informes. IBM Cognos Viewer utiliza un valor de 3 segundos, mientras que otros clientes normalmente utilizan 7 segundos. Si se establece en 0 (cero), esto evitará que la conversación se vuelva asíncrona y bloquee así recursos en el sistema y haga que cada hebra de usuario espere el resultado de solicitud. Esto provocará un rendimiento menor, pero algunas veces se utiliza para solucionar problemas.
  • swt
    Esto especifica el Umbral de Espera Secundario (SWT) para la conversación de ejecución de informes. El valor predeterminado es 30 segundos y no debe cambiarse. Reducir el valor no ayuda a recuperar los resultados más rápido o con anterioridad, ya que cualquier servicio puede enviar una señal al cliente que está esperando diciéndole que ha terminado de trabajar en la solicitud independientemente del SWT. Aumentar el valor no necesariamente ahorra recursos por recargas menos frecuentes o solicitudes de latido enviadas. Esta propiedad está ahí principalmente para propósitos de resolución de problemas.

Configurar la Autenticación

Si la prueba no involucra la autenticación, es decir, si IBM Cognos 10 BI permite el acceso anónimo, el parámetro de espacio de nombres del plan debe dejarse en blanco en el elemento Test configuration Parameters . El plan de prueba reaccionará en consecuencia y se saltará el paso de autenticación, lo cual automáticamente hace que la sesión sea autenticada como anónima.

Si la prueba involucra la autenticación, se debe proporcionar el ID de espacio de nombres del espacio de nombres para autenticar en el parámetro de espacio de nombres del plan en el elemento Test configuration Parameters como se describió anteriormente en la sección Configurar Parámetros .

Además, se necesita proporcionar nombres de usuario y contraseñas al plan para que se utilicen para establecer sesiones autenticadas para IBM Cognos BI. Tenga en cuenta que el Inicio de Sesión Único para IBM Cognos BI no es admitido por el plan y, por lo tanto, se requieren credenciales explícitas tales como el nombre de usuario y la contraseña.

Cuando el plan se ejecuta, cada hebra simulará una sesión de usuario individual. Para autenticar esa sesión, se necesita un inicio de sesión de usuario válido de IBM Cognos BI. Ya que IBM Cognos BI admite que un usuario individual tenga múltiples sesiones concurrentes activas a la vez, en teoría todo el plan de prueba puede ejecutarse mediante una sola cuenta de usuario. Sin embargo, es una buena práctica no utilizar una sola cuenta de usuario más de cinco veces de forma concurrente. Idealmente, para mejorar la resolución de problemas y la calidad de la prueba en relación con la auditoría de resultados y para que sea más parecida a un caso de uso verdadero de usuarios múltiples, cada sesión de cliente simulada por JMeter debe utilizar un conjunto separado de credenciales de usuario. Esto es particularmente verdadero si se consideran los efectos del caché específico del usuario que puede ocurrir en el producto.

Existen dos posibilidades para suministrar credenciales de usuario para el plan. La elección depende de la cantidad de hebras de usuario que serán simuladas durante la prueba y de la cantidad de conjuntos de credenciales disponibles para ser utilizadas.

Para solo algunos conjuntos de credenciales de usuario, se puede utilizar convenientemente un elemento User Parameters en JMeter. Este elemento permite especificar un conjunto definido de variables por usuario en una tabla simple. Una columna inicial etiquetada Name define el conjunto de parámetros, uno por fila, y cada columna adicional define un usuario separado.

Para este plan, se deben definir dos variables, user y pass, para alojar el nombre de usuario y la contraseña correspondiente. Como un ejemplo, una prueba con cinco conjuntos de credenciales de usuario requeriría que este elemento definiera una tabla con dos filas y cinco columnas, sin la columna Name inicial. Mediante un clic en el botón Add User , se pueden añadir columnas adicionales que automáticamente serán etiquetadas por JMeter. Esto se demuestra en la Ilustración 5. User_1 tiene un atributo “user” cuyo valor es “some_user” y un atributo “pass” que tiene un valor de “some_password”.

Ilustración 5: el elemento User Parameters del plan contiene una tabla que define las credenciales de un solo usuario
Illustration 5: The User Parameters element of the plan containing a table defining a single user's  credentials
Illustration 5: The User Parameters element of the plan containing a table defining a single user's credentials

Si se van a utilizar más de algunos conjuntos de credenciales de usuario, es mejor especificar nombres de usuario y contraseñas en un archivo de CSV separado. Para esto, se debe crear un archivo de texto simple, el cual deberá guardarse en la misma carpeta como el plan de prueba mismo. En el archivo de CSV se añaden los nombres de usuario y contraseñas, un conjunto de credenciales por línea que debe ser determinado por un par de CF/LF. En JMeter, desactive el elemento User Parameters mediante un clic con el botón derecho en él y seleccione Disable y después habilite el elemento CSV Data Set Config etiquetado como User Credentials File mediante un clic con el botón derecho en él y seleccione Enable. Como se muestra en la Ilustración 6, en el elemento CSV Data Set Config, especifique el nombre del archivo de CSV que contiene las credenciales de usuario en la propiedad Filename . Si el archivo de CSV se guardó en la misma carpeta que el archivo del plan de prueba, solo especificar el nombre del archivo es suficiente, ya que los nombres de archivos relacionados se resuelven con base en la ruta del sistema de archivos del plan. Para la propiedad Variable Names , se debe especificar user,pass lo que significa que se espera que cada línea leída desde el archivo contenga dos cadenas separadas por una coma. La primera cadena será utilizada para nombre de usuario y, la segunda, para contraseña. Es importante saber que las contraseñas serán almacenadas en texto claro y que no hay compatibilidad para cifrar este archivo, así que será necesario asegurar el archivo de CSV adecuadamente mediante la seguridad del sistema de archivos.

Ilustración 6: el elemento CSV Data Set Config etiquetado como User Credentials File muestra las propiedades del elemento
Illustration 6: The CSV Data Set Config element labelled User Credentials File showing the element's properties
Illustration 6: The CSV Data Set Config element labelled User Credentials File showing the element's properties

El archivo de CSV utilizado en este ejemplo, 102users.txt, contendría algo parecido a esto:

user1,password1 user2,password2 … user99,password99

Tenga en cuenta que los espacios no son ignorados con los valores predeterminados, así que los espacios accidentales detrás de la coma separadora pueden causar que falle el inicio de sesión. Si se requieren comas o espacios en las cadenas, póngalos entre comillas y habilite la propiedad Allow quoted data? en el elemento CSV Data Set Config al cambiarlo a True.

Durante la ejecución del plan, cada hebra leerá una sola línea del archivo. Si utiliza la opción Recycle on EOF , se puede aplazar el archivo hasta alcanzar su fin o hacer que el plan deje de leer valores del archivo de CSV. Se recomienda ampliamente habilitar la opción Recycle on EOF para evitar fallas en la autenticación provocadas por credenciales faltantes.

Sin importar el método que se utilice para proporcionar las credenciales de usuario al plan, asegúrese de que todas las credenciales hayan sido verificadas antes de comenzar el plan para ahorrar tiempo de resolución de problemas.

Configurar el número de hebras y el periodo de arranque

De forma predeterminada, el plan de prueba ejecuta una sola hebra y se ejecuta a través de todos los elementos habilitados del plan una vez. Es muy probable que múltiples usuarios necesiten simularse, de forma que la cantidad de hebras y posiblemente la cantidad de repeticiones necesitarán incrementarse. Esto puede lograrse mediante un clic en el segundo elemento del paquete IBM Cognos 10.2.0 - BI Stability en el árbol. Este es el elemento Thread Group, un tipo de elemento discutido al principio de este documento.

Ilustración 7: las propiedades del elemento Thread Group, incluida la cantidad de hebras, el periodo de arranque y el conteo de bucle
Illustration 7: The properties of the Thread Group element including number of threads, ramp-up period and loop count
Illustration 7: The properties of the Thread Group element including number of threads, ramp-up period and loop count

Las propiedades del elemento Thread Group se mostrarán en el panel derecho de JMeter y la cantidad de hebras, el periodo de arranque y un conteo de bucle pueden especificarse (Ilustración 7). JMeter distribuirá la creación de nuevas hebras equitativamente en el tiempo de arranque especificado. Así que si hay cinco hebras y se ha definido un periodo de arranque de 60 segundos, se iniciará una nueva hebra cada 12 segundos hasta que la cantidad configurada de hebras se haya alcanzado.

Además de estos parámetros, existe el valor Action to be taken after a Sampler error , el cual especifica qué acción tomar si una hebra sufre un error. Esto está establecido como Stop Thread y no debe cambiarlo, ya que le permite identificar fácilmente los errores que ocurrieron durante la ejecución de la prueba. El plan se ha creado para verificar la ejecución exitosa de una solicitud. Si el resultado es algo inesperado, la hebra fallará y puede identificar la posición exacta en el plan donde esto ha ocurrido.

La cantidad máxima posible de hebras depende de los recursos disponibles del sistema que está alojando a JMeter. Por supuesto, aún si JMeter pudiera iniciar cientos de hebras, esto no significa que el sistema de IBM Cognos BI al que se dirige la prueba puede manejarlas, así que la buena práctica es incrementar la cantidad de hebras en pasos con cada ejecución del plan de prueba. El periodo de arranque influenciará en gran medida el nivel de concurrencia, y reducir este periodo podría sobrecargar fácilmente la máquina de JMeter y el sistema de destino, así que nuevamente se recomienda un enfoque de aumento paulatino.

Una buena práctica al utilizar/desarrollar un plan es comenzar con un solo usuario y una iteración. Si funciona bien, utilice más, pruebe con 10 usuarios y 60 segundos de arranque. Al menos un solo sistema de BI de servidor debe poder autenticar sin problemas todas las sesiones; el resto depende de los informes que se estén ejecutando.

Ejecución de la prueba

El plan de prueba puede iniciarse y detenerse mediante el menú Run .

Toda la actividad (es decir, el resultado de cada solicitud individual) será registrada por los dos elementos Listener en el plan. Es una buena práctica aclarar los datos registrados antes de cada ejecución de prueba. Esto puede hacerse desde el menú Run de JMeter seleccionando Clear All. Los atajos del teclado son CTRL+E para aclarar y CTRL+S para iniciar la prueba. La prueba puede detenerse en cualquier momento si emplea el comando Stop desde el menú Run o si presiona CTRL+. (punto). Si hay una alta cantidad de hebras ejecutándose, puede tomar un momento para que la prueba se detenga.

Después del inicio habrá un indicador verde claro en la parte superior derecha junto a dos números que indican cuántas hebras del máximo configurado están realmente en ejecución.

Ilustración 8: la barra de JMeter Status muestra el indicador de actividad y los contadores de hebras en el extremo derecho
Illustration 8: JMeter Status bar showing the activity indicator and thread counters to the farmost right
Illustration 8: JMeter Status bar showing the activity indicator and thread counters to the farmost right

Como se muestra en la Ilustración 8, los números 11/30 significan que 11 hebras se están ejecutando y que habrá un máximo de 30 hebras. Si la cantidad de hebras que se están ejecutando cae debajo de la cantidad máxima de hebras después de que pase el periodo inicial de arranque, debe verificar si una hebra se completó o se detuvo debido a un error. Esto puede hacerse en los elementos Listener.

Normalmente, antes de iniciar la prueba usted hace clic en uno de los elementos Listener para supervisar el progreso. Aunque el elemento Aggregate Report proporciona una visión general, el View Result Tree representa una vista de árbol de todas las solicitudes que se están emitiendo y de las respuestas recibidas para ellas. Este árbol se actualiza sobre la marcha, de forma que crece mientras la prueba se está ejecutando.

Un punto importante a tener en cuenta es que un elemento aparecerá en el árbol de resultados solo después de que la solicitud se haya enviado y 1) una respuesta ha sido recibida o 2) la solicitud falló. Por ejemplo, si no ve que aparece el elemento Login inicial, puede ser debido a que está intentando conectarse a un URL equivocado y el tiempo de espera excedido del servidor web es de 30 segundos.

Se puede hacer clic en cada elemento en ese árbol de resultados y el panel derecho mostrará información sobre el resultado Sampler (información técnica tal como cabeceras y bytes transmitidos), la solicitud enviada (el URL de solicitud exacto y la información transmitida) y los datos de respuesta recibidos en tabulares individuales. Esto se muestra en la Ilustración 9. La investigación de los datos de respuesta ayudará a determinar por qué un cierto elemento pudo haber fallado o qué datos se han retornado. JMeter puede representar los datos de respuesta en distintos formatos para incrementar la legibilidad, así como proporcionar la posibilidad de buscar en los datos de respuesta mediante expresiones regulares.

Muchos elementos no tendrán una respuesta debido a que no presentan solicitudes reales sino que solo estructuran solicitudes del plan de prueba. Un ejemplo son los elementos del tipo controlador de transacciones. Aunque aparecen en el plan, no tendrán un resultado en términos de una solicitud y respuesta de HTTP. Solo estructuran el plan y calculan los totales de tiempo.

Si una solicitud en el receptor del árbol de resultados se muestra en rojo, esto indica que la solicitud no fue exitosa y que la hebra que emitió la solicitud fue detenida. La observación del tabulador de los datos de respuesta de esa solicitud generará información sobre lo que no ha funcionado correctamente.

Tal vez note que los elementos parecen estar fuera de secuencia al listarse en el Receptor del árbol de resultados. Esto se debe a que cuando la estructura de árbol jerárquico del plan se procesa, primero se ejecutan elementos hijos. Solo después de que todos los elementos hijos de un elemento se han procesado, el padre es considerado. Por lo tanto, un elemento padre se mostrará después de todos sus elementos hijos. La Ilustración 9 describe esta forma de leer el árbol de resultados.

Ilustración 9: la salida del Receptor del árbol de resultados muestra respuestas en una lista con sangría de elementos numerados
Illustration 9: The result tree Listener output showing responses in an indented list of numbered elements
Illustration 9: The result tree Listener output showing responses in an indented list of numbered elements

Mediante el uso de las sangrías y el numerado, el plan se diseñó para ayudar a leer el árbol de resultados más fácilmente. Cada elemento tiene un número, a cada elemento hijo se le ha asignado el mismo número y un número adicional de segundo nivel, separado por un punto. Además, los elementos hijos tienen una sangría a la derecha por muchos espacios por nivel en la jerarquía. Por ejemplo, x.1 significa que es el primer subelemento del elemento x, se muestra con sangría de tres espacios a la derecha. Este esquema se aplica para todos los elementos y hasta cinco niveles de sangría y numerado.

Considere el elemento Logon con el número 00 (cero cero) del plan. Este elemento tiene dos elementos hijos: 0.1 y 0.2. El primer elemento hijo está anidado en una condición, lo que significa que solo se ejecutará si la condición es verdadera. En la vista del árbol de resultados este elemento Logon aparece como una de las dos entradas para los subelementos, según la autenticación anónima se utiliza o no, en cuyo caso 0.1 no se ejecutará. En la vista del árbol de resultados, el elemento Logon real solo aparecerá después de esos elementos hijos si el Logon es realmente exitoso. Al leerse de arriba a abajo, la ocurrencia del elemento 00, por lo tanto, implica que el elemento Logon completo fue procesado con éxito. Si en cualquier punto la autenticación hubiera fallado, el elemento 00 padre para Logon se perdería y uno de los elementos hijos se imprimiría en rojo con un símbolo de advertencia al frente. Elementos de resumen tales como 00 - Logon se muestran sin sangría y mediante la anticipación de la sangría los bloques o grupos formados para cada elemento del plan se vuelven claros. La Ilustración 10 muestra rectángulos rojos alrededor de los bloques para los elementos 00 a 03.

El Aggregate Report Listener tiene una salida de tipo tabla, muestra una sola fila por cada elemento de prueba distinto con las columnas que contienen varios valores de temporización, tales como tiempos mínimos, máximos, medianos y promedio (medios). Esto permite leer la información de temporización para la ejecución general de un informe desde él mismo así como información detallada para elementos específicos o incluso algunas partes más grandes de la ejecución. Esto se muestra en la Ilustración 10. Además, se puede aprender con qué frecuencia fue ejecutado un elemento y determinar si todas las hebras configuradas ya han pasado por un cierto elemento.

Ilustración 10: el Aggregate Result Listener muestra la salida de tipo tabla
Illustration 10: The Aggregate Result Listener displaying the table like output
Illustration 10: The Aggregate Result Listener displaying the table like output

Finalmente, una aclaración más con relación a la salida proporcionada por los Receptores. Al ejecutar las pruebas con una sola hebra (usuario), el orden de las entradas que aparece en el Aggregate Result Listener o en el View Result Tree Listener refleja la estructura del plan de prueba en la forma en que se describió anteriormente. Si una prueba está utilizando múltiples hebras, la secuencia de las entradas en el receptor puede aparecer mezclada. Esto no es un problema con el plan, sino que ocurre por las muchas hebras que se están ejecutando de forma concurrente. Archivarán sus actualizaciones de resultados en el Receptor de forma independiente y, por lo tanto, una entrada con un número más alto puede aparecer con un número más bajo simplemente porque cada hebra está ejecutando un elemento distinto del plan. Este es un comportamiento esperado y se aplica en particular para los elementos que ejecutan la Conversación Asíncrona. Esos elementos pueden aparecer más tarde en la ejecución del plan, ya que cuando se introduce más carga en el sistema, las solicitudes que se utilizaron para completarse más o menos instantáneamente ahora pueden necesitar varios segundos para completarse. Existe una forma de etiquetar las salidas del elemento por su número de hebras, pero eso hubiera desordenado el plan y el autor no quiso que fuera así. Si es necesario, se le puede poner un prefijo a cada etiqueta de elemento con [{$__threadNum}] para añadir el número de la hebra en ejecución de un grupo de hebras a la salida

Interpretación de resultados

Después de que la prueba se haya completado, el mejor lugar para comenzar a recolectar la información de resultados es el Aggregate Report Listener. Este tendrá información sobre cuánto tiempo necesitó cada solicitud, cada operación y la prueba en general para ejecutarse así como agregados estadísticos tales como medianos y promedios. Estas medidas de temporización serán los principales indicadores de rendimiento.

Como lo que estamos buscando aquí es la estabilidad, la columna de errores debe mostrar entradas de 0 % únicamente. Si hay errores para una fila en particular, la columna de errores mostrará algo distinto a 0 %. Vaya al View Result Tree Listener y busque entradas en rojo. Investigue las respuestas y reaccione a los mensajes de error visibles ahí mediante el ajuste de la configuración de IBM Cognos 10 BI o los parámetros del sistema.

Para obtener valor adicional de los resultados, puede comparar la temporización entre distintas configuraciones, como cambiar el tipo de Gateway o añadir otro Servidor de Informes. Esto demostrará cómo se influencia el rendimiento. Siempre se debe iniciar con una línea de base y un conjunto de resultados. Una forma simple de establecer una línea de base es realizar tres ejecuciones de la misma prueba y anotar los resultados. Cada conjunto de resultados debe ser similar. Después de eso, se puede comenzar a cambiar el sistema o la configuración para observar el impacto, positivo o negativo, de los cambios.

Estabilizar bien la prueba siempre debe completarse sin ningún error. Si los informes específicos fallan repetidamente, todo excepto los elementos que fallan debe inhabilitarse para acotar el problema.

Si una prueba muestra algunos errores, no necesariamente significa que el sistema de destino de IBM Cognos BI es inestable. Simplemente indica que se necesita más investigación. La mayoría de los errores pueden corregirse mediante el ajuste de la configuración de IBM Cognos BI, ya que algunos de ellos pueden ser el resultado de cuellos de botella del sistema en general. En todos los casos consulte la sección titulada Resolución de Problemas y las Notas Técnicas relacionadas de IBM Cognos antes de realizar cualquier acción. Busque los códigos de error que se encuentran en el tabulador de los datos de respuesta en el árbol de resultados de las solicitudes que fallaron. Si no está seguro, registre un PMR con IBM Cognos Support.

En los casos en que los procesos de BiBusTkServerMain se cuelguen y dejen un minivolcado (Windows) o un núcleo (UNIX/Linux), debe contactar a IBM Cognos Support inmediatamente para registrar un PMR. Necesitará proporcionar el plan de prueba junto con información completa sobre la configuración del sistema.

En resumen, los resultados de la prueba proporcionarán un entendimiento de la estabilidad de un sistema dado de IBM Cognos BI bajo ciertas circunstancias. Tiene que enfatizarse que este plan de prueba es solo una muestra y nunca podrá sustituir una contratación on-site de personal capacitado de IBM Cognos o de socios para ejecutar pruebas complejas de rendimiento y escalabilidad. Contacte a su representante de IBM Cognos para concertar una visita on-site si necesita sentencias sólidas y confirmadas con relación a la estabilidad y el rendimiento.

Resolución de problemas

Esta sección contiene algunos de los mensajes de error más comunes y consejos para solucionar la causa del error. No puede considerarse una guía completa, sino solo una referencia rápida. Para obtener más detalles, busque cualquier error retornado por IBM Cognos BI en las Notas Técnicas o contacte a IBM Support. Nuevamente, este plan en sí NO se admite.

Errores de JMeter

  • La GUI de JMeter no es completamente funcional; algunas opciones de menú, como Open, aparecen en color gris. La consola muestra una excepción de Java.
    Acción: este es un problema con el script de inicio (jmeter.bat/.sh), el cual debe corregirse en el script. Si la máquina en la que JMeter se está ejecutando tiene más de un JRE, es posible que el JRE equivocado esté anteponiéndose a PATH. Este fue el caso para el autor, y fue corregido al poner el comando set JM_LAUNCH=%JAVA_HOME%\bin\%JM_LAUNCH% en el script antes de que llame al JRE y establecer JAVA_HOME al principio del script.
  • JMeter no inicia.
    Acción: asegúrese de estar utilizando JRE versión 1.6. o superior.
  • La IU es lenta para responder o no responde.
    Acción: considere ejecutar JMeter desde una computadora más eficiente o limite la cantidad de hebras (usuarios) a entre 20 y 30.
  • En el Result Tree Listener, los elementos del plan de prueba carecen de solicitudes para captar gráficas o salidas binarias.
    Acción: verifique que el valor de templocation en el plan coincida con la configuración de IBM Cognos 10 para la propiedad Temporary object location .

Errores de IBM Cognos vistos como páginas de errores en el tabulador de datos de resultados de una solicitud cuando se muestra como HTML:

  • Error: DPR-ERR-2002 Unable to execute the request because there was no process available within the configured time limit. El servidor podría estar ocupado.
    Acción: incremente el tiempo excedido en espera de Dispatcher Queue.
  • Error: RSV-ERR-0021 "The server cannot find a primary request with ID <someID>."
    Acción: verifique que su límite de hebras del servidor de aplicaciones no se haya excedido.

Errores del plan, elementos fallas indicados por el color rojo en los resultados del receptor:

  • Lo primero que hay que hacer es probar si el informe realmente funciona mediante un navegador y las mismas credenciales de inicio de sesión. Solo si esto funciona a la perfección tres veces seguidas con una nueva sesión de navegador cada vez, se debe asumir que no ocurre por el informe real en el sistema de BI.
  • Si el informe funciona con un navegador, inhabilite todos los elementos excepto aquel que contiene el elemento fallido. Esto ayudará a cortar la causa de raíz.
  • Si el elemento falla repetidamente y contiene solicitudes, utilice Report Studio o Query Studio para volver a verificar los valores de la solicitud pasados por el plan. Encuentre el elemento de datos utilizado para el filtro de solicitud. Después, identifique el Nombre Exclusivo de Miembro (MUN) para el valor de solicitud deseado y péguelo en el plan. Como alternativa, intente ejecutar el informe a través de un URL pasando los valores de solicitud como parámetros en el URL. Si eso falla, corrija el URL y pegue el MUN correcto en el plan.

Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=960995
ArticleTitle=Prácticas Probadas de IBM Business Analytics: IBM Cognos BI JMeter Stability Package
publish-date=10082013