
Consideraciones de rendimiento de adaptadores locales optimizados para Liberty
Las API de adaptadores locales optimizados WebSphere (WOLA) se han diseñado para proporcionar un rendimiento óptimo para las llamadas entre un espacio de direcciones externo y aplicaciones en Liberty for z/OS. Las API establecen nuevos tipos de patrones de aplicación dando soporte a interacciones de alta precisión entre aplicaciones y estos entornos. Si elige las mejores opciones de configuración para su sistema, puede maximizar las ventajas de rendimiento en cuanto al uso de adaptadores locales optimizados.
Selección de los valores de conexión mínimo y máximo para la llamada de API Register
Si selecciona un valor de conexiones mínimo para la llamada de API Register que es demasiado grande, puede degradarse el rendimiento. Puesto que cada conexión establecida se mantiene hasta que se llama a la API Unregister, si un valor de conexión mínimo es demasiado grande se consume más memoria y aumenta el tiempo que se necesita para completar cada llamada de API Register y Unregister. Seleccione el valor de conexiones mínimo más pequeño que se ajuste a sus necesidades; por ejemplo, si cientos de hebras simultáneas pueden compartir potencialmente un registro, puede que sea lógico dedicar más memoria y tiempo al registro con un valor de conexiones mínimo grande. Si espera pocas hebras simultáneas, defina un valor de conexiones mínimo más pequeño.
Si selecciona un valor que sea demasiado pequeño para el número máximo de conexiones, también se puede degradar el rendimiento si el cliente ha de esperar para obtener una conexión cuando la solicita. Cuando se supera el valor de conexiones máximo, la hebra de llamada espera el número de segundos especificado en el parámetro de tiempo de espera para las API Connection Get, Invoke, Receive Request Any u Host Service a que haya una conexión disponible. Cuando se supera este tiempo, se devuelven códigos de retorno y de razón que indican que no se ha podido establecer una gestión de la conexión para la solicitud antes de que caducara el tiempo de espera. Seleccione el valor de conexiones máximo que mejor se adecue a las necesidades anticipadas de su entorno.
Selección de los valores de conexión máximos cuando se inicia un servidor de enlace CICS
Cuando se inicia una tarea del servidor de enlace bajo Customer Information Control System (CICS) sin especificar los parámetros de conexiones mínimas (MNC) y conexiones máximas (MXC), MNC toma como valor predeterminado 1 y MXC toma como valor predeterminado 10. El valor del parámetro MXC especifica el número de tareas de invocación de enlaces (BBO#) que puede iniciar y ejecutar de forma simultánea la tarea del servidor de enlace (BBO$). Como resultado, el valor también limita el número de hebras simultáneas en el servidor Liberty que se pueden ejecutar e iniciar programas CICS de destino.
Seleccione un valor MXC que refleje la duración prevista de los programas CICS de destino típicos que se inician bajo esta instancia del servidor de enlace. Por ejemplo, si los programas CICS de destino son, en su mayoría, de larga ejecución, un valor MXC más grande es apropiado para mantener a las solicitudes fluyendo de forma eficiente desde el servidor Liberty en CICS. Si los programas de destino son de corta duración, un valor MXC más pequeño resultará más eficiente.
Memoria compartida de 64 bits
Cuando la característica de adaptadores locales optimizados está habilitada en un servidor Liberty, el servidor obtiene 32 MB de memoria compartida que se encuentra por encima de la barra de 2 GB en z/OS. Esta memoria es compartida por todos los servidores Liberty con el mismo nombre wolaGroup y almacena las estructuras de control compartidas del adaptador local optimizado.
La memoria compartida adicional que se encuentra por encima de la barra de 2 GB se asigna para almacenar mensajes pasados entre un cliente y un servidor Liberty. La cantidad de almacenamiento que se necesita para pasar mensajes depende del tamaño de promedio de los mensajes que se pasan, y debe haber suficiente memoria compartida para contener todos los datos de mensajes que existan en cualquier momento. Se asigna memoria adicional según sea necesario.
Si una aplicación continúa llamar a la API de registro y entra en un bucle sin llamar a la API de anulación de registro y sin terminar, que borra automáticamente estos registros, puede desbordar el almacenamiento intermedio de memoria compartida de los adaptadores locales optimizados para el grupo de WOLA. Si ocurre esto, se devuelven las llamadas de la API con códigos de razón fuera de memoria.
Puede calcular una estimación aproximada de la cantidad de memoria compartida WOLA que necesita su aplicación. Cada registro de cliente consume 384 bytes de memoria compartida más 192 bytes de memoria compartida para cada conexión. Un registro con un máximo de 100 conexiones consume cerca de 20 KB de memoria compartida. Cada hebra del cliente, que debe esperar a que haya disponible una conexión si todas las conexiones están en uso, consume unos 80 bytes adicionales. Cada servicio que aloja el registro consume unos 384 bytes adicionales.
200 registros x 384 bytes = 76.800 bytes 200 registros x 200 conexiones x 192 bytes = 7,680,000 bytes 200 registros x 1000 elementos en espera x 80 bytes = 16.000.000 bytes ----------------------------------------------------------------- 23.756.800 bytes 33.554.432 bytes – 23.756.800 bytes = 9.797.632 bytes restantes / 384 bytes por servicio ----------------------------------------------------------------- 25.514 servicios
Consideraciones de rendimiento del servidor de enlace CICS de adaptadores locales optimizados
Puede utilizar adaptadores locales optimizados para un servidor de enlace CICS como una forma sencilla para invocar programas de aplicaciones CICS existentes desde aplicaciones que se ejecutan en el servidor Liberty. Al iniciar el servidor de enlace, la tarea del servidor de enlace de adaptadores locales optimizados (BBO$) se inicia y recibe solicitudes de enlace de programa desde el servidor Liberty. Cuando se recibe una solicitud de enlace, la tarea del servidor de enlace (BBO$) inicia la tarea de enlace de programa (BBO#), que, a su vez, emite un mandato EXEC CICS LINK al programa de destino, recibe una respuesta y la envía al emisor del servidor Liberty. Para realizar estas acciones, la identidad de nivel de hebra de la aplicación en el servidor Liberty se propaga y se certifica en la tarea CICS de destino estableciendo el parámetro SEC=Y en el mandato BBOC START_SRVR.
Si ejecuta un servidor de enlace con REU=Y, las tareas de enlaces de programas (BBO#) permanecen activas hasta se especifica un mandato STOP_SRVR o UNREGISTER de BBOC para el registro. Si también está ejecutando con un valor de máximo de conexiones (MXC) grande y llega un gran número solicitudes a la vez, el número de tareas de enlace de programa (BBO#) activas podría alcanzar el umbral máximo de tareas simultáneas CICS. Para obtener más información sobre cómo establecer el umbral máximo de tareas simultáneas de CICS, consulte la documentación de su versión de CICS.
Para conseguir el rendimiento más rápido al llamar en una aplicación bajo CICS desde el servidor Liberty, codifique las API Servicio de host, Recibir cualquier solicitud o Recibir solicitud específica directamente en el programa de aplicaciones. Sin embargo, la codificación de las API directamente no proporciona el soporte incorporado para la propagación de identidad que proporciona el servidor de enlace.
Consideraciones para utilizar el adaptador de recursos JCA
Cuando se utiliza el adaptador de recursos JCA de adaptadores locales optimizados, cada conexión que se obtiene del objeto ConnectionFactory requiere una sobrecarga de memoria adicional. Si su aplicación realiza varias llamadas a un espacio de direcciones externo o a CICS en el mismo método de la aplicación, puede conseguir un mejor rendimiento utilizando la misma conexión para cada interacción y utilizando el mismo objeto de interacción JCA dentro de un método de aplicaciones.
Cuando cree el objeto ConnectionFactory de JCA para adaptadores locales optimizados, puede modificar el tamaño mínimo y máximo de la agrupación de conexiones JCA para ese ConnectionFactory. La agrupación de conexiones representa las conexiones lógicas que están vinculadas a las conexiones físicas que se especifican al invocar a la API Register durante una interacción. Para obtener un rendimiento óptimo, establezca el tamaño de la agrupación de conexiones JCA para que sea el mismo tamaño de la agrupación de conexiones físicas que ha establecido durante la invocación de la API Regiser. Si su agrupación de conexiones JCA es demasiado pequeña, puede que su aplicación tenga que esperar a un objeto de conexión JCA, aunque haya conexiones físicas disponibles.