![[z/OS]](../images/ngzos.gif)
Consideraciones acerca del rendimiento de los adaptadores locales optimizados
Cuando se utiliza las API de adaptadores locales optimizados de WebSphere Application Server para z/OS, hay varias áreas que deben tenerse en cuenta en relación al rendimiento.
Las API de adaptadores locales optimizados están diseñadas para proporcionar el rendimiento óptimo para las llamadas entre un espacio de direcciones externo y las aplicaciones en WebSphere Application Server para z/OS y se espera que establezcan nuevas clases de patrones de aplicación que admita interacciones más precisas entre las aplicaciones de estos entornos. La información siguiente describe cuestiones que hay que tener en cuenta respecto a los adaptadores locales optimizados y el rendimiento. Este contenido está diseñado para ayudarle a conocer las opciones de configuración para utilizar los adaptadores locales optimizados a fin de obtener el mejor rendimiento. Aquí no se describen los resultados de pruebas comparativas que comparan las llamadas síncronas de los adaptadores locales optimizados con las de otras tecnologías entre WebSphere Application Server y los espacios de direcciones externos del mismo sistema, como SOAP sobre HTTP. Para esta información, consulte el informe de rendimiento de WebSphere Application Server para z/OS.
Selección de valores de conexión mínima y conexión máxima para la llamada API de registro
No se recomienda seleccionar un valor que sea demasiado alto para el parámetro de número mínimo de conexiones en la llamada API de registro ya que ello puede reducir el rendimiento. Esto produce una llamada del espacio de direcciones externo a la región de control de WebSphere Application Server para establecer cada conexión y añadirla a la agrupación de conexiones de adaptadores locales optimizados durante la llamada API de registro. Cuando se establecen estas conexiones con un servidor, las conexiones se conservan hasta que se recibe una llamada de la API Anular registro, momento en que WOLA desconecta las conexiones del servidor y las elimina de la agrupación de conexiones disponible. Si se establece un valor mínimo demasiado alto, se consume más memoria y se añade coste de longitud de vía de acceso a las API de registro y de anulación de registro. Seleccione un valor de conexiones mínimo que sea el más adecuado para sus necesidades. Si se espera que haya potencial para cientos de hebras simultáneas que compartan un registro, se aconseja pagar por el coste de las conexiones durante el registro. Si el número esperado de hebras simultáneas que comparten un registro es menor, se recomienda que el valor mínimo de conexiones se establezca en un valor inferior.
El parámetro de API de registro de conexiones máximas proporciona un límite para el número de conexiones de la agrupación de conexiones de adaptadores locales optimizados para un registro. Esto no es ampliable a todo el tiempo que dura el registro. Una vez que el número de solicitudes de obtención de conexión simultánea excede este valor, la hebra que efectúa la llamada espera a que quede disponible una conexión, durante el número especificado de segundos establecidos en el parámetro de tiempo de espera para las API de Obtención de conexión, Invocación, Recepción de solicitud cualquiera o Servicio de host. Una vez que ha transcurrido este tiempo, se devuelven un código de retorno y un código de razón que indican que no se puede adquirir un manejador de conexiones para la solicitud antes de que haya caducado el tiempo de espera. Hay un tamaño máximo para la agrupación de conexiones para cualquier registro individual que se pueda establecer. Este valor se obtiene de la variable de entorno de toda la célula, WAS_DAEMON_ONLY_adapter_max_conn. El valor predeterminado de fábrica para esta variable es 100. Puede cambiarse el valor utilizando la consola administrativa. Debe reiniciar el daemon después de cambiar el valor.
Efecto de los valores máximo y mínimo de conexiones en el servidor de enlace CICS de adaptadores locales optimizados
Cuando se inicia una tarea de servidor de enlace bajo el Sistema de control de información del cliente (CICS) (utilizando BBOC START_SRVR), si no se pasan los parámetros de conexiones mínimas (MNC) y conexiones máximas (MXC), el valor de registro MNC toma de manera predeterminada 1 y el valor de MXC toma de manera predeterminada 10. Esto significa que el número de tareas de invocación de enlace (tareas BBO#) que la tarea de inicio de servidor de enlace (BBO$) puede iniciar y ejecutar simultáneamente es de 10. Esto se convierte en el número de hebras simultáneas de WebSphere Application Server que pueden ejecutarse e iniciar programas de destino CICS. El valor para el parámetro de servidor de Enlace MXC necesita reflejar la duración esperada de los programas CICS de destino típicos que se espera invocar bajo esta instancia del servidor de enlace. Si los programas de destino CICS son mayoritariamente de larga duración, será apropiado un valor de MXC más alto para que las solicitudes continúen fluyendo de manera eficiente de WebSphere Application Server a CICS. Si los programas de destino son corta duración, será más eficiente un valor de MXC más bajo.
Al determinar el valor de MXC correcto también se deberá tener en cuenta el número de regiones de servant de WebSphere Application Server que se están comunicando con un servidor de enlace bajo un nombre de registro específico. Si hay una sola región de sirviente y se está ejecutando con la opción de hebras establecida en ISOLATE, sólo una hebra individual puede estar enviando a CICS en ese sirviente a la vez, de modo que el valor de MXC se debe establecer en el número de sirvientes multiplicado por 1 para asegurarse de que no se produzcan cuellos de botella. Si se está ejecutando con las hebras establecidas en LONGWAIT, donde hasta un máximo de 40 hebras pueden estar activas por sirviente, en función del número esperado de solicitudes y de tipos de programas CICS que se llamen, de larga duración o de corta duración, se deberá establecer MXC de acuerdo con el número esperado de solicitudes simultáneas a través de los sirvientes al servidor de enlace que se ejecutan para un nombre de registro específico. Es posible que se deban realizar varias pruebas para determinar el valor óptimo de MXC. Empiece con un número más bajo, auméntelo gradualmente y establézcalo donde se determine que el rendimiento es el mejor.
Memoria compartida de 64 bits
El soporte de adaptadores locales optimizados necesita que el servidor deWebSphere Application Server para z/OS se ejecute en la modalidad de 64 bits. Cuando se inicia por primera vez el grupo de daemons con el valor de WAS_DAEMON_ONLY_enable_adapter establecido en true o 1, WebSphere Application Server asigna un almacenamiento intermedio de memoria compartido en el almacenamiento de 64 bits por encima de la barra y lo inicializa. El tamaño predeterminada de esta área es 32 MB. Es aquí donde residen todas las estructuras de control compartidas de los adaptadores locales optimizados. No es el lugar donde se almacenan en caché los datos de mensaje. Los datos de mensaje y de contexto fluyen entre los espacios de direcciones externos y las regiones de servant de WebSphere Application Server utilizando la tecnología de espacio entre direcciones de comunicaciones locales de WebSphere Application Server para z/OS, que presenta los datos de mensaje en el espacio de direcciones de servidor. Para mensajes más grandes, está en el almacenamiento de 64 bits por encima de la barra. Actualmente, las comunicaciones locales de WebSphere Application Server soportan un tamaño de mensaje máximo de 2 GB y en el soporte inicial de adaptadores locales optimizados, es el mayor tamaño de soporte para el mensaje individual.
F <nombre_servidor>,DISPLAY,ADAPTER,REGISTRATIONS
Desde
la salida de visualización deberá poder determinar qué trabajo está consumiendo
y no liberando los registros y rectificar el problema reiniciándolo.Si, después del análisis, se determina que el valor predeterminado de 32 MB es demasiado pequeño para satisfacer las necesidades del grupo de daemons, se puede cambiar el este valor utilizando la variable de entorno para toda la célula WAS_DAEMON_ONLY_adapter_max_shrmem. El cambio de este valor sólo se deberá realizar después haber estudiado detenidamente la situación. Este cambio requiere que se vuelvan a crear los adaptadores locales optimizados compartidos por encima del almacenamiento intermedio de memoria de barra, lo cual sólo se puede realizar con una IPL del sistema.
Puede obtener una estimación aproximada de la cantidad de memoria necesaria. Cada registro de cliente consume 392 bytes de memoria compartida, más 112 bytes de memoria compartida para cada conexión. Un registro con un máximo de 100 conexiones consume 12 KB de memoria compartida aproximadamente. Cada hebra de cliente, que debe esperar a que quede disponible una conexión (todas las conexiones se están utilizando) consume 80 bytes adicionales. Cada servicio incluido en el registro consume 336 bytes adicionales.
200 registros x 392 bytes=78.400 bytes
200 registros x 200 conexiones x 112 bytes=4.480.000 bytes
200 registros x 1000 elementos en espera 80 bytes= + 16.000.000 bytes
--------------------------------
20.558.400 bytes
33,554,432 bytes – 20,558,400 bytes=12,996,032 bytes restantes
/ 336 bytes por servicio
----------------------------------
38.678 servicios
Al aumentar o reducir el tamaño de la memoria compartida,
recuerde que la memoria compartida por encima de la barra se asigna en secciones
de 1 MB. WebSphere Application Server redondea al alza el valor que especifique al MB más próximo. Control del número máximo de llamadas de salida simultáneas de WebSphere Application Server
Hay un valor predeterminado para todo el daemon que controla el número máximo de llamadas de salida simultáneas de WebSphere Application Server para un registro individual soportado con adaptadores locales optimizados. La variable para controlar esto es WAS_DAEMON_ONLY_adapter_max_serv. El valor predeterminado es 100.Esto significa que no puede haber más de 100 servicios de destino diferentes en ejecución bajo un registro individual (llamadas de API simultáneas Servicio de host, Recepción de solicitud cualquiera o Recepción de solicitud específica). Si cambia este valor, es necesario reiniciar el daemon.
Con el valor predeterminado de 100, los intentos de configuración de una hebra como un servidor número 101 para un nombre de registro específico utilizando una de las tres API para este fin producen en un código de razón y de retorno distinto de cero que indican que se ha alcanzado el valor de adapter_max_serv. Si una aplicación de WebSphere Application Server busca este servicio y éste no está disponible inmediatamente, la aplicación espera durante un periodo predeterminado de 30 segundos antes de recibir una excepción que indica que se ha excedido el tiempo de espera para el servicio solicitado. En el registro cronológico de sirviente de WebSphere Application Server esto aparece como un código secundario C9C24C15. La aplicación puede modificar los 30 segundos predeterminados para este tiempo de espera utilizando el método setConnectionWaitTimeout() en la ConnectionSpecImpl de JCA (Java™ EE Connector Architecture).
Consideraciones acerca del rendimiento de servidor de enlace CICS de los adaptadores locales optimizados
Se puede utilizar el soporte de adaptadores locales optimizados para el servidor de enlaces CICS para proporcionar un medio simple de invocar programas de aplicación CICS existentes para aplicaciones que se ejecutan en WebSphere Application Server para z/OS. Al iniciar el servidor de enlace utilizando la transacción BBOC o el programa de PLTPI de CICS BBOACPL2, la tarea de servidor de enlace (BBO$) de adaptadores locales optimizados se inicia y recibe solicitudes de enlace de programa de WebSphere Application Server. A continuación, se inicia la tarea de enlace de programa (BBO#), que a su vez emite un EXEC CICS LINK para el programa de destino, recibe la respuesta y la devuelve al emisor de WebSphere Application Server. Parte de este soporte incluye la propagación y la aserción de identidad a nivel de hebra de la aplicación de WebSphere Application Server en el tarea CICS de destino. La propagación y la aserción de la identidad se solicita utilizando el parámetro SEC=Y en el mandato BBOC START_SRVR.
La ejecución de un servidor de enlaces con SEC=N y la utilización de la identidad del ID de usuario que ha iniciado el servidor de enlaces produce el mejor rendimiento, pero es posible que no esté a la altura de los requisitos de seguridad y auditoría de la organización.
La ejecución con la opción REU=Y significa que las tareas de enlace de programa (BBO#) permanecen activas, una vez que se han iniciado, hasta que se entra un BBOC STOP_SRVR o BBOC UNREGISTER para el registro. Si ejecuta con un valor MXC alto en BBOC START_SRVR y llegan simultáneamente un gran número de solicitudes, el número de tareas BBO# puede llegar a ser muy alto y éstas no terminarán hasta que se detenga el servidor de enlaces. Éste es otro problema a tener en cuenta al determinar si se debe utilizar REU=Y y cuál es el valor de MXC apropiado.
Si el objetivo es lograr el rendimiento más rápido para llamar a una aplicación bajo CICS desde WebSphere Application Server, tenga en cuenta la posibilidad de codificar las API de servicio de host (BBOA1SRV), Recepción de solicitud cualquiera (BBOA1RCA) o Recepción de solicitud específica (BBOA1RCS) directamente en el programa de aplicación. Con esto no existe soporte incorporado para la propagación de identidad como el que proporciona el servidor de enlace, pero si no es necesario y el rendimiento es una prioridad suficientemente alta, es posible que la mejor opción sea el uso directo de las API.
Consideraciones acerca de JCA
Cuando utilice el adaptador de recursos JCA de los adaptadores locales optimizados, tenga presente que hay una sobrecarga adicional con cada conexión que se obtiene del objeto ConnectionFactory. Si la aplicación necesita realizar varias llamadas a un espacio de direcciones externo o CICS en el mismo método de aplicación, la utilización de la misma conexión para cada interacción funciona mejor que la obtención de una conexión diferente para cada interacción. Además se puede utilizar un objeto de interacción JCA repetidamente dentro del mismo método de aplicación.
Al crear una fábrica de conexiones JCA para adaptadores locales optimizados, es posible modificar el tamaño mínimo y máximo de la agrupación de conexiones JCA para esa fábrica de conexiones. Esta agrupación de conexiones representa las conexiones lógicas, que están enlazadas a las conexiones físicas (las especificadas en la llamada de registro BBOA1REG) durante una interacción. Para obtener un rendimiento óptimo, el tamaño de la agrupación de conexiones JCA debe ser el mismo que el de la agrupación de conexiones físicas establecida durante el proceso de BBOA1REG. Si la agrupación de conexiones JCA se ha establecido en un tamaño demasiado pequeño, es posible que la aplicación tenga que esperar a un objeto de conexión JCA, aunque haya conexiones físicas disponibles. Dado que todas las regiones de sirviente comparten la agrupación de conexiones físicas, si tiene varias regiones de sirviente, es aconsejable que reduzca el tamaño de la agrupación de conexiones JCA para que cada región de sirviente conserve el número total de conexiones JCA en todas las regiones de sirviente de acuerdo con el tamaño de la agrupación de conexiones físicas.