![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Directrices de ajuste de Object Request Broker
Utilice las directrices que aparecen en este documento siempre que se utilice el ORB (Object Request Broker) en una carga de trabajo.
El ORB se utiliza siempre que se accede a los enterprise beans mediante una interfaz remota. Si experimenta un consumo de la CPU particularmente alto o bajo, es posible que tenga un problema con el valor de alguno de los siguientes parámetros. Examine estos parámetros de ajuste principales para todos los despliegues de aplicación.
Ajustes de agrupaciones de hebras
Tamaño
Ajuste el tamaño de la agrupación de hebras de ORB según la carga de trabajo. Evite la suspensión de las hebras porque no tengan trabajo listo para procesar. Si las hebras no tienen trabajo listo para procesar, el tiempo de CPU se consume llamando al método Object.wait y se realiza un cambio de contexto. Ajuste el tamaño de agrupación de hebras de modo que la longitud del período de tiempo que esperan las hebras sea lo suficientemente corto para impedir que se destruyen por haber estado desocupadas mucho tiempo.
El tamaño de agrupación de hebras depende de la carga de trabajo y del sistema. En las configuraciones típicas, las aplicaciones requieren 10 o menos hebras por procesador.
No obstante, si la aplicación está realizando una solicitud de programa de fondo muy lenta como, por ejemplo, una solicitud a un sistema de base de datos, una hebra de servidor bloquea la espera destinada a que se complete la solicitud de programa de fondo. Con las solicitudes de programa de fondo, la utilización de la CPU es bastante baja. En este caso, el aumento de la carga no aumenta la utilización o rendimiento de la CPU. Los vuelcos de hebra indican que el recurso de programa de fondo ha llamado a casi todas las hebras. En este caso, se recomienda que incremente el número de hebras por procesador hasta que el rendimiento mejore y los vuelcos de hebras muestren que éstas están en áreas del tiempo de tiempo de ejecución distintas de la llamada del programa de fondo. Debe ajustar el número de hebras sólo si el recurso de programa de fondo está ajustado correctamente.
El parámetro Permitir la asignación de hebras por encima del tamaño máximo de hebra también afecta al tamaño de agrupación de hebras, pero no lo utilice a menos que su programa de fondo se detenga durante largos periodos de tiempo, provocando el bloqueo de todas las hebras de tiempo de ejecución que están a la espera del sistema de programa de fondo en lugar de procesar otros trabajos ajenos a este sistema.
Puede ajustar los valores de tamaño de agrupación de hebras en la consola de administración. Pulse Servidores > Tipos de servidor > Servidores de aplicaciones > nombre_servidor > Servicios del contenedor > Servicio ORB > Agrupación de hebras. Puede ajustar el número máximo y mínimo de hebras.
Tiempo de espera excedido de la agrupación de hebras
Cada solicitud de entrada y salida a través del ORB requiere una hebra de la agrupación de hebras del ORB. En escenarios de mucha carga o en escenarios donde las solicitudes de ORB aniden profundamente, resulta posible para una máquina virtual Java™ (JVM) hacer que todas las hebras de la agrupación de hebras del ORB traten de enviar solicitudes. Por otra parte, el ORB de la JVM remota que procesa estas solicitudes tiene todas las hebras de la agrupación de hebras del ORB tratando de enviar solicitudes. Como resultado, el progreso nunca se realiza, las hebras no se liberan a la agrupación de hebras del ORB y éste no puede procesar las solicitudes. Como resultado, existe un punto muerto potencial. Mediante la consola de administración puede ajustar este comportamiento, a través de la propiedad personalizada com.ibm.websphere.orb.threadPoolTimeout del ORB. Para obtener más información, consulte la documentación acerca de las propiedades personalizadas del ORB (Object Request Broker).
Tamaño de fragmentos
El ORB divide los mensajes en fragmentos para enviarlos a través de la conexión de ORB. Puede configurar el tamaño de estos fragmentos con el parámetro com.ibm.CORBA.FragmentSize.
- En la consola de administración, habilite el rastreo de ORB en la página Propiedades de ORB.
- Habilite ORB como rastreo desde la página de registro cronológico y rastreo.
- Aumente los tamaños de archivo de rastreo, dado que el rastreo puede generar muchos datos.
- Reinicie el servidor y ejecute el menos una iteración (preferiblemente varias) del caso que desee medir.
- Busque el archivo rastreable y haga una búsqueda de Fragmento a seguir: Sí.
Este mensaje indica que el ORB ha transmitido un fragmento, pero sigue teniendo, como mínimo, un fragmento restante para enviar antes de que llegue todo el mensaje. El valor de Fragmento a seguir: No indica que el fragmento en particular es el último del mensaje completo. Este fragmento también puede ser el primero, si el mensaje cabe completamente en un fragmento.
Si va al lugar donde se encuentra Fragmento a seguir: Sí, encontrará un bloque parecido al ejemplo siguiente:
Fragmento a seguir: Sí Tamaño de mensaje: 4988 (0x137C) -- ID de solicitud: 1411
Este ejemplo indica que la cantidad de datos en el fragmento es de 4988 bytes y que el ID de solicitud es 1411. Si hace una búsqueda de todas las apariciones de ID de solicitud: 1411, verá el número de fragmentos utilizados para enviar ese mensaje en concreto. Si suma todos los tamaños de mensajes asociados, tendrá el tamaño total del mensaje que se envía a través del ORB.
- Puede configurar el tamaño de fragmentos estableciendo la propiedad personalizada ORB com.ibm.CORBA.FragmentSize.
Interceptores
Los interceptores son extensiones ORB que pueden configurar el contexto antes de que el ORB ejecute una solicitud. Por ejemplo, el contexto puede incluir transacciones o sesiones de actividad para que se importen. Si el cliente crea una transacción y, a continuación, hace fluir el contexto de transacción al servidor, el servidor importa el contexto de transacción a la solicitud de servidor mediante los interceptores.
La mayoría de los clientes no inician las transacciones o sesiones de actividad, así que casi todos los sistemas pueden beneficiarse de la eliminación de los interceptores que no sean necesarios.
Para eliminar los interceptores, edite manualmente el archivo server.xml y elimine de la sección de ORB las líneas de interceptor que no sean necesarias.
Ajustes de la memoria caché de conexión
Dependiendo de la carga de trabajo de un servidor de aplicaciones y de los requisitos de productividad o tiempo de respuesta, puede que tenga que ajustar el tamaño de la memoria caché de conexión de ORB. Cada entrada en la memoria caché de conexión es un objeto que representa un punto final de socket TCP/IP diferente, que se identifica mediante el nombre de host o la dirección TCP/IP, y el número de puerto utilizado por el ORB para enviar una solicitud de GIOP o una respuesta de GIOP al punto final de destino remoto. El objetivo de una memoria caché de conexión es minimizar el tiempo necesario para establecer una conexión mediante la reutilización de los objetos de conexión de ORB en las siguientes solicitudes o respuestas. (Se utiliza el mismo socket TCP/IP para la solicitud y la respuesta correspondiente).
Para cada servidor de aplicaciones, el número de entradas en la memoria caché de conexión se relaciona directamente con el número de conexiones de ORB simultáneas. Estas conexiones están formadas por las solicitudes de entrada realizadas desde los clientes remotos y las solicitudes de salida realizadas por el servidor de aplicaciones. Cuando el ORB del lado del servidor recibe una solicitud de conexión, utiliza una conexión existente de una entrada en la memoria caché, o establece una nueva conexión y añade una entrada para esa conexión en la memoria caché.
Las propiedades Memoria caché máxima de conexión y Memoria caché mínima de conexión de ORB se utilizan para controlar el número máximo y mínimo de entradas en la memoria caché de conexión en cualquier momento. Cuando el número de entradas alcanza el valor especificado por la propiedad Memoria caché máxima de conexión y se necesita una nueva conexión, el ORB crea la conexión solicitada, añade una entrada a la memoria caché y busca e intenta eliminar hasta cinco entradas de conexiones inactivas de la memoria caché. Puesto que la nueva conexión se añade antes de que se eliminen las entradas inactivas, es posible que el número de entradas de memoria caché excedan temporalmente el valor especificado para la propiedad Memoria caché máxima de conexión.
Una conexión de ORB se considera inactiva si la corriente del socket TCP/IP no está en uso y no hay respuestas de GIOP pendientes para ninguna solicitud realizada en esa conexión. A medida que disminuye la carga de trabajo de la aplicación, el ORB cierra las conexiones y elimina de la memoria caché las entradas de esas conexiones. El ORB siguen eliminando entradas de la memoria caché, hasta que el número de entradas restantes sea igual o menor que el valor especificado para la propiedad Memoria caché máxima de conexión. El número de entradas de memoria caché no es nunca menor que el valor especificado por la propiedad Memoria caché mínima de conexión, que debe ser como mínimo cinco conexiones menos que el valor especificado por la propiedad Memoria caché máxima de conexión.
Normalmente, no es necesario realizar ajustes de la memoria caché de conexión en el ORB del lado del cliente, ya que en este lado sólo se realiza un pequeño número de conexiones.
Hebras del lector JNI
De manera predeterminada, el ORB utiliza una hebra Java para procesar cada solicitud de conexión de entrada que recibe. A medida que aumenta el número de solicitudes simultáneas, aumenta el almacenamiento consumido por un número mayor de hebras del lector, que puede llegar a producir un cuello de botella en los entornos de recursos restringidos. Finalmente, el número de hebras Java creadas puede provocar excepciones de falta de memoria si el número de solicitudes simultáneas sobrepasa los recursos disponibles del sistema.
Para solucionar este problema, puede configurar el ORB para que utilice hebras del lector JNI allí donde se cree un número finito de hebras del lector, implementadas con hebras de OS nativo en lugar de con hebras Java, durante la inicialización del ORB. Las hebras del lector JNI se basan en el mecanismo asíncrono TCP/IP de OS nativo que permite a una única hebra de OS nativo manejar los sucesos de E/S desde varios sockets al mismo tiempo. El ORB gestiona el uso de las hebras del lector JNI y asigna una de las hebras disponibles para manejar la solicitud de conexión utilizando un algoritmo por turno rotativo. Normalmente, las hebras del lector JNI sólo se deben configurar cuando el uso de hebras Java necesite demasiada memoria para el entorno de aplicaciones.
- Como se asigna un número fijo de hebras, el uso de la memoria se reduce. Esta reducción supone una ventaja importante en aquellos entornos con cargas de trabajo excepcionalmente altas y solicitudes de cliente sostenidas.
- El tiempo necesario para crear y destruir hebras Java de forma dinámica se elimina, ya que durante la inicialización del ORB se crea y se asigna un número fijo de hebras de JNI.
- Cada hebra de JNI puede manejar hasta 1024 conexiones de socket e interactúa directamente con el mecanismo asíncrono de E/S de OS nativo, que puede aumentar el rendimiento del proceso de E/S de red.