IBM Optim pureQuery Runtime para la performance de z/OS

pureQuery mejora el rendimiento de las aplicaciones en DB2(R) para z/OS(R) facilitando el despliegue de SQL estático para Java(TM) en muchas aplicaciones nuevas o existentes. En las nuevas aplicaciones esto puede hacerse utilizando las interfaces pureQuery DAO y los métodos comentados. La característica de optimización de clientes permite capturar y enlazar SQL en cualquier aplicación Java, incluyendo aquellas que utilizan una estructura. Este artículo ha sido actualizado con las últimas cifras de la performance del release de la Versión 2.2 de Optim™ pureQuery Runtime for z/OS.

El contenido de este artículo forma parte de la IBM Data Management Magazine.

Simon Harris, Senior Software Engineer, EMC

Simon HarrisSimon Harris es Ingeniero de Performance en el equipo de desarrollo de WebSphere Federation Server en el Silicon Valley Laboratory. Simon ha estado trabajando con tecnología de base de datos federadas desde la aparición de la misma en IBM en 1995, brindando soporte a muchos clientes en lo relativo a la capacidad pre y post venta en Europa, Oriente Medio y África.



Rajesh Sambandhan, Advisory software engineer , IBM

Rajesh SambandhanRajesh Sambandhan es ingeniero asesor de software en el equipo IBM Information Management, India Software Lab. Ha estado en la industria por más de siete años, trabajando principalmente en J2EE y Test Driven Development.



15-07-2010 (Primera publicación 01-07-2008)

Nota:La información incluida en este documento no ha sido sometida a ninguna prueba formal por parte de IBM y es distribuida tal cual es. El uso de esta información o la implementación de cualquiera de estas técnicas es responsabilidad del cliente y depende de la habilidad del cliente para evaluarlas e integrarlas a su entorno operativo. Aunque IBM puede haber revisado alguno de los temas para comprobar su precisión en ocasiones específicas, no existe garantía de que se obtengan resultados iguales o similares en otras situaciones. Cualquiera que intente adaptar estas técnicas a su propio entorno lo hará bajo su propio riesgo.

Los datos de la performance incluidos en este documento fueron determinados en diversos entornos de laboratorio controlados y se han incluido sólo como referencia. Los clientes no deberían adaptar estas cifras de la performance a sus propios entornos como parámetros de la performance del sistema. Los resultados que pudieran obtenerse en sus sistemas operativos podrían diferir significativamente. Los usuarios de este documento deberían verificar los datos aplicables a sus entornos específicos.

En este artículo, suministraremos una breve visión general de la plataforma pureQuery, un resumen de las mejoras realizadas desde la primera publicación de este artículo, y los resultados actualizados de un estudio de la performance realizado para comparar los métodos de acceso de pureQuery con varias alternativas conocidas de acceso a datos Java (inclusive JDBC). Los resultados del estudio muestran la posibilidad de realizar mejoras importantes en el rendimiento y la reducción del consumo de la CPU usando la ejecución estática de pureQuery en comparación con las otras alternativas. Y, al utilizar la optimización de clientes, estos beneficios pueden obtenerse sin realizar cambios en la aplicación.

Este artículo contiene resultados de la performance obtenidos al utilizar la ejecución estática en una aplicación JDBC existente. Vea los Recursos de un artículo sobre los resultados de la performance del uso de pureQuery para aplicaciones .NET .

Presentación de pureQuery

pureQuery es una plataforma de acceso a datos Java de alta performance que simplifica las tareas de desarrollo y administración de aplicaciones que permiten el acceso a los datos. Esta está constituida por herramientas (IBM Optim Development Studio), APIs, y un tiempo de ejecución (IBM Optim pureQuery Runtime (para z/OS o para Linux, UNIX, y Windows)).

La sección Resources proporciona una lista de varios recursos que brindan información sobre la plataforma pureQuery . En pocas palabras, al utilizar pureQuery, es posible optimizar la performance del acceso a los datos y mejorar la seguridad y la administración de muchas aplicaciones Java o .NET nuevas o existentes. (Este artículo se centra en la performance de Java.)

Entre los conceptos claves que lo ayudarán a comprender la información presentada en este artículo se encuentran los siguientes:

Cada uno de estos conceptos se describen con más detalle en esta sección.

Si desea un resumen de las reflexiones sobre si pureQuery es bueno para su entorno, consulte el Apéndice.

API de pureQuery

pureQuery brinda soporte al acceso a los datos usando interfaces Data Access Objects (DAO) y métodos comentados, y métodos en línea integrados usando una interfaz de datos no incorporada. Es importante tener en cuenta que usted no necesita utilizar la API para sacar provecho de pureQuery. Sin embargo, si así lo hiciera, cualquiera de los enfoques ha sido diseñado para facilitar la comprensión por parte de los desarrolladores y para reducir la cantidad de código generada.

Mediante el uso de métodos en línea, el SQL se incluye directamente en el código Java y utiliza la interfaz de datos no incorporada. El uso de métodos en línea ofrece soporte directamente a la ejecución dinámica, pero usted puede usar la optimización de clientes con métodos en línea para dar soporte a la ejecución estática. Cuando la interfaz DAO utiliza métodos comentados, el SQL se mantiene dentro de la aplicación o en archivos de interfaz diferentes que usted puede definir. Los archivos de interfaz hacen posible que la aplicación Java actual permanezca independiente del enfoque de persistencia. La interfaz DAO que utiliza métodos comentados brinda soporte tanto a la ejecución dinámica como a la estática. En otras palabras, es necesario no intervenir en el procesamiento de la optimización de clientes para que este estilo use el SQL estático. Este artículo no incluye la medición de la performance del uso de DAOs para la implementación de la ejecución estática.

Optimización de clientes de pureQuery

La optimización de clientes, una mejora clave que fue incorporada en el release 1.2, hace posible aprovechar el SQL estático para las aplicaciones JDBC (o .NET) existentes, sin modificar — ni tampoco tener acceso a — el código fuente. Esta capacidad también funciona en aplicaciones Java que utilizan una estructura para persistencia, como por ejemplo Hibernate. Con la optimización de clientes, usted ejecuta la aplicación, y a la vez, el tiempo de ejecución de pureQuery se encuentra en modo “captura”, generalmente como parte de la validación de prueba de un caso de uso que utiliza varias rutas de ejecución de programa. El DBA puede entonces enlazar el SQL capturado en paquetes en el servidor de la base de datos. Las siguientes ejecuciones de la aplicación permiten que el tiempo de ejecución de pureQuery ejecute el SQL capturado estáticamente. De esta forma, la optimización de clientes le proporciona a las aplicaciones los beneficios de la performance y la seguridad del SQL estático, sin necesidad de modificar o recompilar la aplicación.

Optim Development Studio

En las aplicaciones Java, incluyendo aquellas que usan las interfaces pureQuery DAO o aquellas que en las que se ha optimizado a los clientes, Optim Development Studio permite a los desarrolladores o DBAs localizar fácilmente las sentencias SQL específicas en la fuente Java, directamente con el número de línea específico (vea la Figura 1). Esta habilidad para visualizar las relaciones entre la fuente Java y el SQL es conocida como la vista SQL Outline (previamente conocida como pureQuery outline).

La vista outline también proporciona la perspectiva del esquema de la base de datos lo cual puede ser útil al realizar el análisis de los impactos o el aislamiento de los problemas. Por ejemplo, si usted piensa suprimir una columna, puede descubrir en que parte del programa Java esa columna se está utilizando y modificar el SQL de la manera apropiada. Finalmente, la vista outline también suministra datos de performance sobre la ejecución de SQL, con lo cual usted puede identificar hotspots SQL rápidamente y de allí dirigirse directamente al Visual Explain o ejecutar Optim Query Tuner para ayudar a analizar y ajustar el SQL.

Figura 1. Vista Outline de Optim Development Studio
la captura de pantalla muestra la correlación entre una consulta en código de fuente java con tablas referenciadas en esquema (en la etiqueta de la base de datos ). Las métricas de la performance para la sentencia también pueden observarse en esa etiqueta de la base de datos.

¿Cuáles son las novedades de pureQuery?

Desde la primera publicación de este artículo en Julio de 2008, pureQuery ha avanzado muchísimo en relación con la colaboración y la productividad del desarrollador y la DBA, además de las mejoras para ayudarlo a tomar ventaja de la optimización de clientes. Aquí le ofrecemos un resumen de algunas, pero no todas, las mejoras. Si desea más información sobre estas mejoras, diríjase a la sección Recursos de este artículo. Le recomendamos especialmente el capítulo 5 del Meeting Service Level Objectives Redbook, el cual contiene un buen resumen de las mejoras realizadas a la Versión 2.2.

  • La capacidad para sustituir los marcadores de parámetros por literales al capturar SQL. Antes de esta mejora, para la optimización de clientes era necesario capturar y enlazar cada uno de los acontecimientos de una sentencia que podrían diferir sólo en los valores literales que se utilizaban. Ahora bien, con la sustitución de literales, estas sentencias pueden unificarse en una sola sentencia con el propósito de realizar enlaces y crear paquetes.
  • La capacidad para reemplazar los SQL de performance baja con SQL equivalente, que usted haya ajustado sin necesidad de modificar la aplicación. Además, para ajustar en contexto, usted tiene la capacidad de ejecutar Optim Query Tuner directamente desde Optim Development Studio.
  • La capacidad de visualizar, guardar y comparar las métricas de performance en Optim Development Studio.
  • La capacidad de unificar múltiples archivos de captura para el soporte de entornos de aplicación clusterizados.
  • Nueva desde la Versión 2.2 Fix Pack 3, la capacidad para utilizar un depósito seguro para centralizar la administración de los dispositivos pureQuery .

IBM Data Server Driver para JDBC y SQLJ (Tipo 2 y Tipo 4)

Tanto los drivers Tipo 2 como el Tipo 4 del JDBC se utilizan generalmente en las aplicaciones para acceder a los datos de DB2. Para usar el driver del Tipo 2 es necesario que el cliente de DB2 esté instalado en la misma máquina que la aplicación; mientras que el driver de Tipo 4 es 100 por ciento Java y no requiere que el cliente de DB2 esté instalado (este directamente implementa el protocolo de red para la fuente de datos). Este artículo presenta las cifras de la performance obtenidas al usar las conexiones de Tipo 2 y de Tipo 4.

En la Figura 2 se observa el tiempo de ejecución de pureQuery ejecutándose normalmente en z/OS usando las conexiones de Tipo 2 o de Tipo 4.

Figura 2. Ejecución normal de Optim pureQuery Runtime en z/OS
Figure 2. Ejecución normal del tiempo de ejecución de optim pureQuery en z/OS (nuevo en 1.2)

Carga de trabajo del Estudio de la Performance

El estudio de la performance utilizó la IBM Relational Warehouse Workload (IRWW) ejecutándose en WebSphere Application Server V6.1. La carga de trabajo se ejecutó en DB2 para z/OS V9 ejecutándose en un procesador Z9 de tres modos.

IRWW es una aplicación OLTP basada en un sistema de entrada y seguimiento de órdenes. IRWW crea un proveedor al por mayor que administra órdenes y consiste de siete tipos de transacciones. La frecuencia de las transacciones se establece para simular un escenario real; la mezcla utilizada en el entorno de comparación fue de 47 por ciento de transacciones de actualización, 53 por ciento de transacciones de solo lectura. La carga de trabajo es disparada por un programa de cliente que genera solicitudes HTTP para la mezcla de transacciones solicitada. La performance es informada de la siguiente forma: Promedio de rendimiento normalizado - Transacciones por segundo (ITR).

La Internal Throughput Rate (ITR) es la tasa de rendimiento nocional que supone que las CPUs están 100 por ciento ocupadas. Por ejemplo, piense en una aplicación con un promedio de 200 transacciones por segundo utilizando el 75 por ciento de la CPU. La ITR para esta aplicación debería ser 200 * 100/75 = 267 tps. Este es el promedio de transacciones nocionales que podría lograrse si la CPUs estuviera 100 por ciento ocupada.


Alcance del estudio de la performance

Para este estudio se utilizó IBM pureQuery Runtime para z/OS 2.2. El fin de este estudio de la performance fue comparar el rendimiento normalizado y el consumo de SQL de la CPU, comparando tanto las interfaces pureQuery DAO y JDBC con optimización de clientes con las alternativas de la tecnología. IRWW se modificó para incorporar cada una de estas tecnologías, y los números de la performance fueron extraídos ejecutando la carga de trabajo y monitoreando el sistema. El alcance de este artículo, se ve limitado a las siguientes tecnologías:

  • Interfaces pureQuery DAO usando métodos comentados (ejecución estática)
  • JDBC con optimización de clientes pureQuery (ejecución estática)
  • JDBC (ejecución dinámica) - este sirve para la medición de baseline con las que se comparan las alternativas
  • EJB2 (ejecución dinámica)
  • OpenJPA (ejecución dinámica).

Tenga en cuenta que IRWW y esta prueba no utilizan todas las características de pureQuery que pueden ayudar a mejorar la performance, como por ejemplo el agrupamiento heterogéneo y la sustitución de literales.


Resultados e interpretaciones de la Performance

El porcentaje de aciertos de caché de sentencia dinámica es un factor clave al momento de determinar cuánta mejoría puede lograrse en la aplicación si se pasa de la ejecución dinámica a la estática de SQL. Como se explica en el artículo "No Excuses", la mayor parte del trabajo en las sentencias dinámicas está representado por la preparación de la sentencia para la ejecución. Sin embargo, dado que las sentencias que ya han sido preparadas pueden permanecer en la caché de la sentencia dinámica, para la ejecución repetida de esa misma sentencia no sería necesario preparar otra operación. Por lo tanto, si cada sentencia SQL que ejecuta la aplicación se encuentra ya en la caché de la sentencia dinámica (osea, el porcentaje de aciertos en del 100 por ciento), el beneficio de la reducción del consumo de la CPU debido al cambio al SQL estático no será importante en comparación con la situación en la cual sólo la mitad de las sentencias SQL dinámicas se encontraban en la caché de la sentencia dinámica (porcentaje de aciertos del 50 por ciento). Durante nuestra prueba, la caché de la sentencia dinámica se midió para alcanzar un promedio de aciertos de aproximadamente 80 por ciento; lo cual es común en algunas aplicaciones del mundo real.

Las mediciones a la CPU durante la comparación son tomadas de z/OS LPAR — no hubo capacidad zIIP para descarga.

Mediciones con el driver de JDBC tipo 2

Al ejecutar IRWW con el driver de JDBC Tipo 2, los porcentajes de aciertos en la caché de la sentencia se detallaron en la Tabla 1:

Tabla 1. Promedio de aciertos de la caché de la sentencia observados en la ejecución de IRWW con el driver del Tipo 2 JDBC.
APIPromedio de aciertos de la caché de la sentencia dinámica
EJB281
JPA78
JDBC80

La Figura 3 utiliza JDBC dinámico como baseline y compara el rendimiento normalizado (ITR) de las diferentes APIs al ejecutar IRWW usando el driver de tipo 2 JDBC.

Figura 3. Resultados del rendimiento normalizado usando el driver de tipo 2.
en comparación con el JDBC dinámico, ITR para EJB 2 es -49%, JPA es -42$, CO es +42% y DAO es +60%.

Los resultados destacan el hecho de que la ejecución dinámica puede lograr mucho mayor rendimiento que el JDBC dinámico. La tabla que aparece en la Figura 3 muestra que pureQuery con Client Optimization Static logró un porcentaje de mejora del 42 por ciento en ITR (tasa de transacciones normalizadas sobre consumo de CPU ) en comparación con el JDBC dinámico normal solo. Las interfaces purequery DAO que usan ejecución estática lograron una mejora mucho mayor de ITR del 50% sobre el JDBC dinámico. En el sistema de prueba, la prueba estática de optimización de clientes de pureQuery dio como resultado una reducción promedio del consumo de la CPU en todo el sistema del 14%, y las interfaces pureQuery DAO que usaron ejecución estática alcanzaron una reducción del consumo de la CPU en todo el sistema de aproximadamente un 17%. Los resultados de la optimización de clientes son particularmente importantes dado que no se tuvo que modificar el código fuente.

Mediciones con el driver JDBC tipo 4

Con el driver JDBC tipo 4, los promedios de aciertos de la caché de la sentencia en la Tabla 2 fueron observados durante las pruebas:

Tabla 2. Promedio de aciertos de la caché de la sentencia observado en la ejecución de IRWW con el driver JDBC tipo 4.
APIPromedio de aciertos de la caché de la sentencia dinámica (%)
EJB281
JPA79
JDBC80

La Figura 4 muestra el rendimiento normalizado (ITR) de las diferentes APIs al ejecutar IRWW usando el driver JDBC tipo 4.

Figura 4. Resultados del rendimiento normalizado usando el driver JDBC tipo 4.
en comparación con el JDBC dinámico, ITR para EJB 2 es -49%, JPA es -32$, CO es +24% y DAO es +37%.

Los resultados obtenidos con el driver tipo 4 muestran que, al igual que con el driver tipo 2, la ejecución estática (ya sea con pureQuery DAO o con optimización de clientes) puede lograr mejoras importantes en la eficiencia del rendimiento en comparación con JDBC.

La tabla normalizada en la Figura 4 muestra que con IRWW, la optimización de clientes estática de pureQuery logró un 24 por ciento de mejora de ITR en comparación con el uso de JDBC dinámico normal solo. Las interfaces pureQuery DAO que usaron ejecución dinámica alcanzaron una mejora de ITR del 37% en comparación con el JDBC dinámico. En el sistema de prueba, la prueba estática de optimización de clientes pureQuery dio como resultado una reducción promedio del consumo de la CPU en todo el sistema del 4%, y las interfaces pureQuery (estáticas) alcanzaron una reducción del consumo de la CPU en todo el sistema del 13% aproximadamente.

Durante cada prueba, el consumo de la CPU de la aplicación de IRWW y de DB2 se monitorearon por separado. Con ambos drivers, tipo 2 y tipo 4, al cambiar de JDBC dinámico al estático pureQuery, la proporción de CPU consumida por DB2 disminuyó, mientras que la proporción de CPU consumida por la aplicación aumentó. El uso de la CPU por parte de la aplicación aumenta porque tiene la capacidad de procesar más transacciones en la misma unidad de tiempo, mientras que el uso de la CPU por parte de DB2 disminuye porque ya no tiene que preparar la sentencia SQL.


Resumen de los resultados

Los resultados del estudio de la performance muestran que la ejecución estática de SQL que utiliza Optim pureQuery Runtime para z/OS puede mejorar de manera significativa el rendimiento y reducir el costo de la CPU por transacción de la aplicación. En el entorno de comparación empleado en este estudio, este enfoque resultó en una reducción del 13 por ciento en el total del consumo de LPAR CPU al usar el driver tipo 4 y una reducción del 17 por ciento al usar el driver tipo 2, en comparación con el JDBC normal. Además, con la característica de la optimización de clientes no hay necesidad de cambiar ni una sola línea del código fuente en la aplicación, ni tampoco tener acceso al código fuente, un hecho que reduce ampliamente el costo del tiempo de ejecución de la implementación de pureQuery.

La reducción en el consumo de la CPU y el mayor rendimiento al usar interfaces pureQuery DAO junto con la ejecución estática y la optimización de clientes se produce porque las sentencias SQL ya no tienen que prepararse y ejecutarse dinámicamente. Si el promedio de aciertos de la caché de la sentencia dinámica JDBC para la carga de trabajo de IRWW se acercó más al 100 por ciento, entonces el beneficio de la performance obtenido por introducir la pureQuery DAOs (estática) o utilizar optimización de clientes (estática) se vería reducido. De modo similar, si el promedio de aciertos de la caché fuera menor que el indicado durante la comparación, el beneficio sería aún mayor.

Este estudio también demuestra la ventaja de la performance al utilizar JDBC y pureQuery en lugar de JPA o EJB2. Al utilizar los drivers tipo 2 y tipo 4, el JDBC normal muestra una mejora en la eficiencia del rendimiento en comparación con JPA y EJB2, y tanto la optimización de clientes pureQuery (que utiliza ejecución estática) como pureQuery DAOs (que utiliza ejecución estática) muestran una mejora importante.


Agradecimientos

A los autores les gustaría agradecer a Bill Bireley, Kevin Foster, Stephen Brodsky, y Kathy Zeidenstein por su resumen y sus sugerencias. Un agradecimiento especial a Soonnee Chang y Todd Munk por ejecutar los tests de performance.


Apéndice. ¿Debería utilizar pureQuery?

En nuestras recomendaciones, intentamos no sólo concentrarnos en uso de pureQuery, sino además indicar aquellos casos en los cuales la tecnología pureQuery (como por ejemplo la optimización de clientes) puede utilizarse para ayudar en los entornos del mundo real.

El desarrollo de nuevas aplicaciones de datos Java

Para las aplicaciones centradas en los datos, desde la perspectiva de la performance y la seguridad, el SQL estático proporciona importantes beneficios, incluyendo la posibilidad de obtener un mayor crecimiento de la aplicación sin tener que comprar hardware adicional. El estilo de pureQuery DAO (método comentado) proporciona facilidad de uso y beneficios en el diagnóstico a los desarrolladores, además de la capacidad de realizar despliegues estáticamente sin necesidad de modificar la aplicación.

Si sus desarrolladores requieren la administración de objetos o no desean moverse de su estructura actual, entonces usted puede utilizar la optimización de clientes para alcanzar los beneficios del SQL estático en esas aplicaciones.

Las aplicaciones y estructuras JDBC existentes

Si el entorno de sus aplicaciones JDBC existentes ya ha sido ajustado por un experto (es decir que usted se encuentra más cerca del promedio de aciertos del 100% en la caché de sentencia), entonces es improbable que usted desee convertir aquellas aplicaciones existentes en pureQuery por razones de performance solamente, pero se verá beneficiado igualmente de la administración mejorada y la resolución de problemas, la mejor estabilidad del plan, y la mejor seguridad y modelo de gobierno de SQL estático.

Considere usar la optimización de clientes para probar las ventajas del SQL estático y para proporcionar a los desarrolladores y DBAs la vista de outline, lo cual le permite señalar más detalladamente la ubicación de la declaración SQL problemática en la fuente Java y le ofrece además la capacidad de realizar el análisis de la performance del SQL en el entorno de prueba.

Aplicaciones SQLJ existentes

Si usted está utilizando SQLJ ya está accediendo a los beneficios del SQL estático, pero quizá desee usar la optimización de los clientes para sacar ventaja de las capacidades de determinación del problema y el análisis del impacto en pureQuery. Si le gustan los beneficios que obtiene de pureQuery desde la perspectiva del desarrollo y la administración, podría valer la pena considerar realizar nuevo desarrollo en pureQuery. Por ejemplo, además de las herramientas para el desarrollador y las mejores capacidades de diagnóstico de pureQuery, es más simple enlazar y desplegar con pureQuery que con SQLJ.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=549040
ArticleTitle=IBM Optim pureQuery Runtime para la performance de z/OS
publish-date=07152010