IBM WebSphere Application Server, Advanced Edition
Guía de ajuste
IBM WebSphere Application Server, Advanced EditionGuía de ajuste |
|
Asistente de ajustador de rendimiento
Antememoria de fragmentos dinámica
Para invocarlo desde la consola de administración seleccione Consola > Asistentes > Ajustador de rendimiento.
Consulte el artículo 6.6.21 de InfoCenter para obtener más información.
La antememoria de fragmentos dinámica permite almacenar en la antememoria el resultado de los archivos JSP y los servlets dinámicos y resulta una tecnología que mejora drásticamente el rendimiento de las aplicaciones. Esta antememoria, que trabaja dentro de la JVM de un servidor de aplicaciones, intercepta las llamadas al método service() de un servlet y comprueba si se puede dar servicio a la invocación desde la antememoria en lugar de volver a ejecutar el servlet. Dado que las aplicaciones J2EE presentan un índice de lectura/grabación elevado y pueden tolerar un grado de latencia menor en la actualización de sus datos, la antememoria de fragmentos permite mejorar de modo espectacular el tiempo de respuesta del servidor, su productividad y la escalabilidad.
Después de que se haya ejecutado un servlet (y se haya generado la salida que se almacenará en la antememoria), se generará una entrada en la antememoria con dicha salida. También se producirán los efectos colaterales de la ejecución, esto es, se invocarán otros archivos JSP o servlets, además de metadatos sobre la entrada que incluyen información sobre el tiempo de espera y la prioridad de la entrada. Las entradas únicas se diferencian por una cadena de identificación que se genera desde el objeto HttpServletRequest cada vez que se invoca el servlet. Como resultado, el servlet se almacena en la antememoria en función de los parámetros de petición que ha utilizado el URI para invocar el servlet o de la información sobre la sesión. Dado que WebSphere Application Server compila los archivos JSP en servlets, los JSP y los servlets se utilizan de manera indistinta, excepto cuando se declaran elementos en un archivo XML.
Para establecer esto:
Consulte el artículo 4.5: Antememoria de fragmentos dinámica de InfoCenter para obtener más información.
| Síntoma | Información adicional |
| El rendimiento y el tiempo de respuesta no son los deseados. | Velocidad del procesador |
|
AIX: error de asignación de memoria Solaris: demasiados archivos abiertos | Descriptores de archivos AIX (ulimit) o Descriptores de archivos Solaris (ulimit) |
| Solaris: el servidor se atasca durante períodos de mucho trabajo, las respuestas tardan más tiempo, el uso del procesador continúa siendo elevado con toda la actividad de los procesos del sistema y netstat muestra que hay varios sockets abiertos en el puerto 80 cuyo estado es CLOSE_WAIT o FIN_WAIT_2. | tcp_close_wait_interval/tcp_time_wait_interval de Solaris y tcp_fin_wait_2_flush_interval de Solaris |
| Windows NT/2000: netstat muestra que hay demasiados sockets cuyo estado es TIME_WAIT. | TcpTimedWaitDelay de Windows NT/2000 |
| HP-UX 11: el rendimiento no es el deseado y la prioridad del servidor de aplicaciones no se ha ajustado. | Ajuste de la prioridad del sistema operativo del proceso de WebSphere Application Server |
| Cuando hay carga de trabajo, las peticiones de los clientes no llegan al servidor Web porque sobrepasan el tiempo de espera o porque se rechazan. |
Para HP-UX 11 consulte tcp_conn_request_max de HP-UX 11 Para IIS en Windows NT/2000 consulte el Parámetro ListenBackLog Para IBM HTTP Server en NT, consulte ListenBackLog |
| Windows NT/2000: el rendimiento de WebSphere Application Server ha disminuido después de que se instalara un servidor de aplicaciones de otro proveedor. | Propiedades de los permisos de IIS |
| Los valores de porcentaje de número máximo que utiliza Resource Analyzer indican que la agrupación de hebras del contenedor Web es demasiado pequeña. | Número máximo de conexiones ThreadsMax del contenedor Web |
| Netstat indica que hay demasiados sockets cuyo estado es TIME_WAIT en el puerto 9080. | Número máximo de conexiones activas del transporte del contenedor Web |
| Hay demasiada actividad de entrada/salida de disco debido a la paginación. | Valores del tamaño del almacenamiento dinámico |
| Los valores de porcentaje de uso que utiliza Resource Analyzer en una agrupación de conexiones de origen de datos indican que el tamaño de la agrupación es demasiado grande. | Tamaño de la agrupación de conexiones de origen de datos de WebSphere |
| Los valores para descartar la antememoria de sentencias preparadas que utiliza Resource Analyzer indican que el tamaño de la antememoria de sentencias preparadas del origen de datos es demasiado pequeña. | Tamaño de la antememoria de sentencias preparadas |
| Hay demasiada actividad de entrada/salida de disco debido a que DB2 está grabando registros cronológicos. | MinCommit de DB2 |
| Los valores de porcentaje de número máximo que utilizar Resource Analyzer indican que la agrupación de hebras de Object Request Broker es demasiado pequeña. | Colocación en cola y enterprise beans |
| La JVMPI (Java Virtual Machine Profiler Interface) de Resource Analyzer indica que existe una sobreutilización de objetos cuando se dedica mucho tiempo a la recogida de basura. | Detección de la sobreutilización de objetos |
| Los valores de utilización de memoria de Resource Analyzer indican que falta memoria y Java muestra una excepción de tipo Se ha agotado la memoria. | Detección de falta de memoria |
| El rendimiento, el tiempo de respuesta y la escalabilidad no son los deseados. | Si la aplicación lo permite, utilice la antememoria de fragmentos dinámica |
Se puede realizar una amplia gama de mejoras en WebSphere Application
Server si se utilizan los procedimientos que hay disponibles para el ajuste. Esta guía de ajuste le muestra cómo funciona el ajuste, le ofrece
las recomendaciones generales y describe los métodos de ajuste
específicos. También contiene ideas y sugerencias sobre los diferentes
factores y variables que pueden mejorar el ajuste del rendimiento.
Utilice la guía para el ajuste, junto con sus ejemplos y recursos
para llevar a cabo fácilmente las tareas de ajuste. El ajuste implica un proceso
de aprendizaje continuo. Los resultados pueden ser diferentes de los que
se presentan en esta guía.
Para su comodidad, se describen algunos procedimientos para establecer parámetros en otros productos. Dado que estos productos pueden cambiar, considere estos procedimientos como sugerencias.
Existen dos tipos de ajuste: el ajuste de aplicaciones y el ajuste de parámetros.
Aunque, en ocasiones, el ajuste de aplicaciones ofrece las mayores mejoras de ajuste, este documento se centra en los parámetros de rendimiento individuales y la sinergia existente entre ellos.
El libro blanco WebSphere Application Server Development Best Practices for Performance and Scalability, trata los temas de ajuste de aplicaciones describiendo los mejores métodos de desarrollo de aplicaciones Web que contengan archivos JSP (Java Server Page) y servlets y de aplicaciones de empresa que contengan componentes enterprise beans.
La tabla siguiente lista los diferentes ajustes de parámetros que pueden generar un alto rendimiento:
Los parámetros siguientes ayudan a evitar problemas funcionales:
| Parámetro ListenBackLog: se aplica si se ejecuta Windows NT/2000 con IIS y la carga de trabajo de clientes elevada |
| Tipo de transporte: utilice INET Sockets en Solaris, que es el valor por omisión de WebSphere Application Server |
| Número de conexiones con DB2: si establece más conexiones de las que DB2 tiene configuradas por omisión |
| Se ha seleccionado Permitir asignaciones de hebras por encima del número máximo y el sistema tiene una sobrecarga debido a que se han asignado demasiadas hebras |
| Utilización de sockets TCP para DB2 en Linux: para bases de datos locales |
| Tamaño de la agrupación de conexiones de origen de datos de WebSphere: compruebe que tiene las conexiones suficientes para manejar las conexiones adicionales que se necesitan para procesar transacciones con los EJB de entidad y para evitar puntos muertos |
WebSphere Application Server tiene una serie de componentes interrelacionados que deben ajustarse de forma equilibrada para dar soporte a los requisitos personalizados de la aplicación e-business completa. Estos ajustes ayudan al sistema a conseguir la máxima productividad mientras se mantiene la estabilidad general del sistema.
WebSphere Application Server establece una red de colocación en cola, que es una red de colas interconectadas que representan los diversos componentes de la plataforma que da servicio a las aplicaciones. Estas colas incluyen la red, el servidor Web, el contenedor Web, el contenedor EJB, el origen de datos y posiblemente un gestor de conexiones de un sistema de fondo personalizado. Cada uno de estos recursos representa una cola de peticiones que están a la espera de utilizar dicho recurso.
Las colas de WebSphere son recursos que dependen de la carga. El tiempo promedio que se tarda en dar servicio a una petición depende del número de clientes simultáneos.
La mayoría de las colas que componen la red de colocación en cola son colas cerradas. A diferencia de una cola abierta, una cola cerrada limita el número máximo de peticiones que puede haber en la cola.
Una cola cerrada permite una gestión estricta de los recursos del sistema. Por ejemplo, el valor de número máximo de conexiones del contenedor Web controla el tamaño de la cola del contenedor Web. Si un servlet promedio que se ejecute en un contenedor Web crea 10 MB de objetos en cada petición, si se establece el valor de número máximo de conexiones en 100 se limitará el consumo de memoria del contenedor Web a 1 GB.
En una cola cerrada, una petición puede estar en uno de estos dos estados: activa o en espera. Una petición activa está trabajando o está a la espera de una respuesta procedente de una cola que se encuentra en sentido descendente. Por ejemplo, una petición activa en el servidor Web está ejecutando un trabajo (como, por ejemplo, recuperando HTML estático) o se encuentra a la espera de que termine una petición en el contenedor Web. Si está en estado de espera, la petición está a la espera de activarse. La petición permanecerá en estado de espera hasta que una de las peticiones activas abandone la cola.
Todos los servidores Web soportados por WebSphere son colas cerradas, al igual que lo son los orígenes de datos de WebSphere Application Server. Los contenedores Web pueden configurarse como colas abiertas o cerradas. En general, es mejor configurarlos como colas cerradas. Los contenedores EJB son colas abiertas; si no se encuentra ninguna hebra disponible en la agrupación, se creará una nueva que se utilizará mientras dure la petición.
Si los servlets llaman a los enterprise beans, el contenedor Web limitará el número de peticiones simultáneas totales de un contenedor EJB porque el contenedor Web también tiene un límite. Esto solamente es cierto si se llama a los enterprise beans desde la hebra del servlet de ejecución. No existe nada que le impida crear hebras y bombardear el contenedor EJB con sus peticiones. Este es uno de los motivos por el que no resulta una buena idea que un servlet cree sus propias hebras de trabajo.
A continuación se mencionan los diferentes valores de cola:
El apartado siguiente describe un método para configurar las colas de WebSphere Application Server. Siempre puede cambiar la dinámica del sistema, y, por lo tanto, los parámetros de ajuste se pueden modificar eliminando los recursos que le rodean como, por ejemplo, moviendo el servidor de base de datos a otra máquina, o proporcionando recursos más potentes como, por ejemplo, un grupo más rápido de CPU con más memoria. De este modo, se ajustan los parámetros a una configuración específica del entorno de producción.
La primera regla del ajuste consiste en minimizar el número de peticiones que hay en las colas de WebSphere Application Server. En general, es mejor que las peticiones esperen en la red, frente al servidor Web, y no que esperen en WebSphere Application Server. Esta configuración permitirá que se pasen a la red de colocación en cola únicamente las peticiones que están listas para ser procesadas. Para llevar a cabo esta configuración, especifique que se amplíe ligeramente el límite ascendente de las colas (el más cercano al cliente) y que el límite descendente de las colas (el más lejano al cliente) vaya disminuyendo progresivamente.
Las colas de esta red de colocación en cola son progresivamente menores a medida que el trabajo fluye en sentido descendente. Cuando llegan 200 clientes al servidor Web, 125 peticiones permanecen en la cola de la red ya que el servidor Web tiene establecido manejar 75 clientes simultáneos. Cuando las 75 peticiones pasan del servidor Web al contenedor Web, 25 permanecerán en cola en el servidor Web y el contenedor Web manejará las 50 restantes. Este proceso seguirá por el origen de datos hasta que 25 usuarios lleguen al destino final, el servidor de base de datos. Ningún componente de este sistema tendrá que esperar a que llegue trabajo porque, en cada punto del flujo en sentido ascendente, hay trabajo en espera de entrar en dicho componente. La mayor parte de las peticiones esperan en la red, fuera de WebSphere Application Server. Esto mejorará la estabilidad porque no habrá ningún componente sobrecargado. Se puede utilizar software de direccionamiento, como IBM Network Dispatcher para direccionar a los usuarios que se encuentran en espera a otros servidores del clúster de WebSphere Application Server.
Utilizando un caso de prueba que represente todo el espíritu de la aplicación de producción (por ejemplo, ejercita todas las rutas significativas del código) o utilizando la propia aplicación, ejecute un conjunto de experimentos para determinar cuándo se maximizan las funciones del sistema (el punto de saturación). Lleve a cabo esas pruebas después de eliminar de la aplicación la mayoría de los cuellos de botella. El objetivo de estas pruebas suele ser conseguir que las CPU alcancen una utilización cercana al 100%.
Inicie el experimento inicial básico con colas largas. Esto permitirá una concurrencia máxima en todo el sistema. Por ejemplo, inicie el primer experimento con un tamaño de cola de 100 en cada uno de los servidores de la red de colocación en cola: el servidor Web, el contenedor Web y el origen de datos.
A continuación, empiece con una serie de experimentos para trazar una curva de productividad y aumente la carga de usuarios simultáneos tras cada experimento. Por ejemplo, realice experimentos con 1 usuario, 2 usuarios, 5, 10, 25, 50, 100, 150 y 200 usuarios. Tras cada ejecución, registre la productividad (peticiones por segundo) y los tiempos de respuesta (segundos por petición)
La curva resultante de los experimentos básicos debe parecerse a la típica curva de productividad que se muestra en la figura siguiente:
El rendimiento de WebSphere Application Server depende del número de peticiones simultáneas que hay en todo el sistema. La sección A, la zona de carga ligera, muestra que a medida que aumenta el número de peticiones de usuarios simultáneas, aumenta la productividad casi de forma paralela al número de peticiones. Esto demuestra que, con cargas ligeras, las peticiones simultáneas se enfrentan a una congestión muy pequeña en las colas del sistema WebSphere Application Server. En un momento determinado, la congestión empieza a aumentar y la productividad aumenta a una velocidad mucho menor hasta alcanzar el punto de saturación que representa el valor máximo de productividad, determinado por algunos cuellos de botella en el sistema WebSphere Application Server. El tipo de cuello de botella más manejable se produce cuando las CPU de las máquinas de WebSphere Application Server se saturan. Esto es lo ideal porque un cuello de botella de CPU es fácil de remediar, simplemente hay que añadir CPU adicionales o más potentes.
En la zona de carga elevada o sección B, a medida que la carga de clientes simultáneos aumenta, la productividad continúa siendo relativamente constante. Sin embargo, el tiempo de respuesta aumenta proporcionalmente con la carga de usuarios. Es decir, si se dobla la carga de usuarios en la zona de carga elevada, se dobla el tiempo de respuesta. En un punto determinado, representado por la sección C, la zona de caída, uno de los componentes del sistema se agota. En este punto, la productividad empieza a disminuir. Por ejemplo, puede que el sistema entre en la zona de caída cuando las conexiones de red del servidor Web agoten los límites del adaptador de red o si se superan los límites del sistema operativo para manejadores de archivos.
Si el punto de saturación se alcanza cuando la actividad de las CPU del sistema está cercana al 100%, vaya al paso siguiente. Si la CPU no ha alcanzado una actividad del 100%, es probable que exista un cuello de botella agravado por la aplicación. Por ejemplo, es posible que la aplicación esté creando demasiados objetos Java lo que generará cuellos de botella de recogida de basura en Java.
Hay dos formas de gestionar los cuellos de botella de las aplicaciones: suprimir el cuello de botella o clonar el cuello de botella. El mejor modo de gestionar un cuello de botella es suprimirlo. Utilice un perfilador de aplicaciones Java para examinar la utilización general de objetos. Se pueden utilizar perfiladores como, por ejemplo, Performance Trace Data Visualizer (PTDV), JProbe y Jinsight.
El número de usuarios simultáneos que hay en el punto de saturación representa la concurrencia máxima de la aplicación. Por ejemplo, si la aplicación ha saturado WebSphere Application Server con 50 usuarios, puede que 48 usuarios le ofrezca la mejor combinación de productividad y de tiempo de respuesta. Este valor se denomina valor de Concurrencia de aplicaciones máxima. La concurrencia de aplicaciones máxima pasa a ser el valor que se debe utilizar como base para ajustar las colas del sistema WebSphere Application Server. Recuerde que lo ideal es que la mayor parte de los usuarios esperen en la red, por lo tanto, disminuya los tamaños de las colas a la vez que aleja el flujo en sentido descendente con respecto al cliente. Por ejemplo, si el valor de Concurrencia de aplicaciones máxima es 48, comience por colas de sistema con los valores siguientes: servidor Web 75, contenedor Web 50 y origen de datos 45. Lleve a cabo una serie de experimentos adicionales ajustando estos valores elevándolos o bajándolos ligeramente para encontrar aquéllos que sean mejores.
Se puede utilizar Resource Analyzer para determinar el número de usuarios simultáneos mediante los valores de hebras activas simultáneas de la agrupación de hebras del motor de servlets.
En experimentos de rendimiento realizados, la productividad aumentó en un 10-15% cuando se ajustó el número máximo de conexiones activas del transporte del contenedor Web de modo que coincidiera con el número máximo de hebras del contenedor Web.
En muchos casos, sólo una parte de las peticiones que pasan por una cola entra en la siguiente cola de sentido descendente. En un sitio con muchas páginas estáticas, el servidor Web da servicio a muchas peticiones y éstas no se pasan al contenedor Web. En estas circunstancias, el tamaño de la cola del servidor Web puede ser bastante mayor que el de la cola del contenedor Web. En el apartado anterior, la cola del servidor Web se había establecido en 75 en lugar de estar algo más cerca del valor de Concurrencia de aplicaciones máxima. Se deben realizar ajustes similares cuando los componentes diferentes presentan tiempos de ejecución diferentes.
Por ejemplo, en una aplicación que emplea el 90% de su tiempo en un servlet complejo y sólo el 10% en realizar una consulta JDBC breve, como promedio, sólo el 10% de los servlets estarán utilizando las conexiones de base de datos en un momento determinado, de modo que el tamaño de la cola de conexiones de base de datos puede ser bastante menor que el de la cola del contenedor Web. Por el contrario, si la mayor parte del tiempo de ejecución del servlet se emplea en realizar una consulta compleja a una base de datos, puede aumentar los valores de cola tanto del contenedor Web como del origen de datos. Supervise siempre la utilización de la CPU y de la memoria tanto para WebSphere Application Server como para los servidores de base de datos para asegurarse de que no está saturando ni la CPU ni la memoria.
Las invocaciones de métodos de enterprise beans se colocan en cola únicamente si el cliente que está llamando al método es remoto. Por ejemplo, si el cliente EJB está ejecutándose en una Máquina Virtual Java distinta (que está en otro espacio de dirección) de la del enterprise bean. Por otro lado, si el cliente EJB (ya sea un servlet u otro enterprise bean) está instalado en la misma JVM, el método EJB se ejecutará en la misma hebra de ejecución que el cliente EJB y no se colocará en cola.
Los enterprise beans remotos se comunican a través del protocolo RMI/IIOP. Un ORB de servidor procesa las invocaciones de métodos que se inician mediante RMI/IIOP. La agrupación de hebras actúa como una cola para las peticiones de entrada. Sin embargo, si se emite una petición de método remota y no hay más hebras disponibles en la agrupación de hebras, se creará una hebra nueva. Una vez finalizada la petición de método, la hebra se destruye. Por lo tanto, cuando se utiliza el ORB para procesar las peticiones de método remotas, el contenedor EJB es una cola abierta, puesto que su uso de hebras es ilimitado. La siguiente ilustración muestra las dos opciones de colocación en cola de enterprise beans.
Cuando se configura la agrupación de hebras, es importante comprender los patrones de llamada del cliente EJB. Si un servlet realiza un pequeño número de llamadas a enterprise beans remotos y cada llamada a método es relativamente rápida, puede establecer el número de hebras de la agrupación de hebras de ORB en un valor menor que el del tamaño de la agrupación de hebras del contenedor Web.
Resource Analyzer muestra un valor que se denomina porcentaje de número máximo, que se utiliza para determinar durante cuánto tiempo se han estado utilizando todas las hebras configuradas. Si este valor se muestra constantemente con dos dígitos, entonces probablemente ORB sea la causa del cuello de botella y deberá aumentarse el número de hebras.
El grado en que debe aumentar el valor de la agrupación de hebras de ORB estará en función del número de servlets simultáneos (es decir, de clientes) que llaman a los enterprise beans y de la duración de cada llamada a método. Si las llamadas a métodos son más largas, puede establecer el tamaño de la agrupación de hebras de ORB en el mismo valor que el tamaño del contenedor Web ya que de este modo, las llamadas a métodos remotas no se intercalarán tanto. Si el servlet sólo realiza llamadas breves o rápidas al ORB, el tamaño de la agrupación de hebras de ORB puede ser pequeño. Potencialmente, varios servlets pueden reutilizar la misma hebra de ORB. En este caso, la agrupación de hebras de ORB puede ser pequeña, incluso la mitad que el valor del tamaño de la agrupación de hebras del contenedor Web. Si la aplicación pasa mucho tiempo en ORB, configure otra relación más igualada entre el contenedor Web y ORB.
Las funciones de clonación de servidores de aplicaciones pueden ser de gran ayuda para configurar entornos de producción altamente escalables. Esto resulta especialmente cierto cuando la aplicación sufre cuellos de botella que impiden que se utilice toda la CPU de los SMP (Servidores de multiprocesos simétricos). Cuando se ajustan las colas del sistema WebSphere Application Server en configuraciones de clúster, recuerde que cuando se añade un servidor a un clúster, el flujo en sentido descendente del servidor recibe el doble de carga.
Existen dos clones del contenedor Web entre un servidor Web y un origen de datos. Se presupone que el servidor Web, los motores de servlets y el origen de datos (pero no la base de datos) se están ejecutando en un solo servidor SMP. Dadas estas restricciones, se deben tener en cuenta las siguientes consideraciones sobre la cola:
Cuando se establece una conexión SSL, se produce un inicio de comunicación SSL. Una vez realizada la conexión, SSL realiza un cifrado y descifrado masivo de cada lectura y grabación. El inicio de comunicación SSL tiene un coste de rendimiento mucho mayor que el cifrado y descifrado masivo.
Para mejorar el rendimiento de SSL, debe disminuirse el número de conexiones SSL individuales y de inicios de comunicación.
Si se disminuye el número de conexiones se aumenta el rendimiento de las comunicaciones protegidas mediante conexiones SSL y también de las comunicaciones no protegidas mediante conexiones TCP sencillas. Un modo de disminuir el número de conexiones SSL individuales es utilizar un navegador que dé soporte a HTTP 1.1. Si no se actualizan a HTTP 1.1, los usuarios no podrán disminuir el número de conexiones SSL individuales.
Es más común disminuir el número de conexiones (tanto TCP como SSL) entre dos componentes de WebSphere Application Server. Las directrices siguientes le ayudarán a asegurarse de que el transporte HTTP del servidor de aplicaciones se ha configurado de modo que el plug-in del servidor Web no vuelva a abrir reiteradamente conexiones nuevas con el servidor de aplicaciones:
Los aceleradores de hardware a los que WebSphere Application Server da soporte actualmente solamente aumentan el rendimiento de los inicios de comunicación SSL, no el proceso de cifrado/descifrado masivo. Generalmente, un acelerador sólo beneficia al servidor Web porque las conexiones con el servidor Web están activas durante un breve espacio de tiempo. Todas las demás conexiones SSL de WebSphere Application Server están activas durante más tiempo y, por lo tanto, no se benefician de un dispositivo de hardware que únicamente acelera los inicios de comunicación SSL.
El rendimiento de una suite de cifrado es diferente con el software que con el hardware. Simplemente porque una suite de cifrado tiene un mejor rendimiento con el software, no significa que su rendimiento vaya a ser mejor con el hardware. Algunos algoritmos suelen ser ineficaces en el hardware (por ejemplo, DES y 3DES), sin embargo, el hardware especializado puede proporcionar implementaciones eficaces de estos mismos algoritmos.
El rendimiento del cifrado y descifrado masivo se ve afectado por la suite de cifrado que utilice una conexión SSL individual. El software de prueba con el que se han calculado los datos utilizaba JSSE de IBM para el software del cliente y del servidor y no utilizaba ningún soporte de hardware de criptográfico. La prueba no incluía el tiempo necesario para establecer una conexión pero sí el tiempo necesario para transmitir los datos a través de una conexión establecida. Por lo tanto, los datos revelan el rendimiento SSL relativo de las diferentes suites de cifrado para conexiones de larga duración.
Antes de establecer una conexión, el cliente había habilitado una suite de cifrado individual para cada uno de los casos de prueba. Una vez establecida la conexión, el cliente calculó el tiempo que tardaba en escribir un entero en el servidor y el tiempo que tardaba el servidor en devolver al cliente el número de bytes especificado. Si se variaba la cantidad de datos el rendimiento relativo de las suites de cifrado no sufría efectos significativos. El diagrama siguiente muestra el rendimiento de cada suite de cifrado.
Un análisis de los datos anteriores, revela lo siguiente:
La lista de comprobación incluye estos valores:
La opción A para comprometer proporciona un rendimiento máximo del enterprise bean ya que los datos de la base de datos los guarda en antememoria fuera del ámbito de la transacción. Generalmente, la opción A para comprometer solamente está disponible cuando el contenedor EJB tiene acceso exclusivo a la base de datos concreta. De lo contrario, la integridad de los datos puede estar en peligro. La opción B para comprometer almacena las instancias de objetos EJB de entidad en antememoria de un modo más agresivo, lo cual puede mejorar el rendimiento en comparación con la opción C para comprometer, pero también utiliza más memoria. La opción C para comprometer es la configuración más común en el mundo real para los EJB de entidad.
Los valores de las propiedades Activar en y Cargar en rigen las opciones de comprometer que se utilizan.
El nivel de aislamiento también juega un papel importante en el rendimiento. Los niveles de aislamiento más altos disminuyen el rendimiento ya que aumentan el bloqueo de filas y la actividad general de la base de datos y al mismo tiempo disminuyen los accesos simultáneos a los datos. Las diferentes bases de datos proporcionan un comportamiento distinto respecto a los niveles de aislamiento. En general, el valor Lectura repetible es correcto para las bases de datos DB2. El valor Lectura comprometida suele utilizarse para Oracle. Oracle no da soporte al valor Lectura repetible y convertirá este valor al nivel de aislamiento más alto, serializable.
Se puede especificar el nivel de aislamiento en el nivel de bean o en el nivel de método. Por lo tanto, se pueden configurar diferentes valores de aislamiento para los diferentes métodos. Esto supone una ventaja cuando algunos métodos requieren niveles de aislamiento superiores a otros y se puede utilizar para obtener un rendimiento máximo mientras se mantienen los requisitos de integridad. Sin embargo, no se puede cambiar el nivel de aislamiento entre llamadas a método dentro de una sola transacción de enterprise bean. En este caso se generará una excepción de tiempo de ejecución.
Lectura repetible
Este nivel prohíbe las lecturas incorrectas y las lecturas
no repetibles, pero permite las lecturas fantasma.
Lectura comprometida
Este nivel prohíbe las lecturas incorrectas, pero permite
las lecturas no repetibles y las lecturas fantasma.
Lectura no comprometida
Este nivel permite las lecturas incorrectas, las lecturas no repetibles y las lecturas fantasma.
El contenedor utiliza el atributo de nivel de aislamiento de transacción como se indica a continuación:
Si el cliente invoca un método de bean desde fuera de un contexto de transacción, el contenedor se comporta del mismo modo que si se establece el atributo de transacción No soportado. El cliente debe llamar al método sin un contexto de transacción.
Obligatorio
Este valor válido indica al contenedor que invoque siempre el método de bean dentro del
contexto de transacción asociado con el cliente. Si el
cliente intenta invocar el método de bean sin un contexto de transacción,
el contenedor genera la excepción
javax.jts.TransactionRequiredException en el cliente. El contexto
de transacción se pasa a cualquier objeto o recurso del enterprise bean al
que acceda un método de enterprise bean.
Los clientes de enterprise beans que accedan a estos beans de entidad lo deben hacer dentro de una transacción existente. Para otros enterprise beans, el método de enterprise bean o de bean debe implementar el valor Gestionado por bean, o bien utilizar el valor Necesario o Requiere nuevo. En caso de clientes de EJB que no sean enterprise beans, el cliente debe invocar una transacción utilizando la interfaz javax.transaction.UserTransaction.
Requiere nuevo
Este valor válido indica al contenedor que invoque siempre el método de bean dentro de un contexto de transacción nuevo, independientemente de si el cliente invoca el método dentro o fuera de un contexto de transacción. El contexto de transacción se pasa a los objetos o recursos de
enterprise bean que utilice este método de bean.
Necesario
Este valor válido indica al contenedor que invoque el método de bean dentro de un
contexto de transacción. Si un cliente invoca un método de bean dentro de un contexto de transacción, el contenedor invoca el método de bean dentro del contexto de transacción del cliente. Si un cliente invoca un método de bean fuera de un contexto de transacción, el contenedor crea un contexto de transacción nuevo e invoca el método de bean desde dentro de dicho contexto. El contexto de transacción se pasa a los objetos o recursos de
enterprise bean que utilice este método de bean.
Ofrece soporte
Este valor válido indica al contenedor que invoque el método de bean dentro de un
contexto de transacción si el cliente invoca el método de bean dentro de una transacción. Si el cliente invoca el método de bean sin un contexto de transacción, el contenedor invoca el método de bean sin un contexto de transacción. El contexto de transacción se pasa a los objetos o recursos de
enterprise bean que utilice este método de bean.
No soportado
Este valor válido indica al contenedor que invoque los métodos de los beans sin un contexto de transacción. Si un cliente invoca un método de bean desde dentro de un
contexto de transacción, el contenedor suspende la asociación entre la transacción
y la hebra actual antes de invocar el método en la instancia de enterprise bean. Después,
el contenedor reanudará la asociación que se ha suspendido cuando regrese la invocación
del método. El contexto de transacción suspendida no se pasa a
ninguno de los objetos o recursos de enterprise bean que utilice este método de
bean.
Gestionado por bean
Este valor notifica al contenedor que la clase de bean gestiona
directamente la demarcación de la transacción. Esta propiedad se puede especificar sólo para beans de sesión y no se puede especificar para métodos de bean individuales.
Si se analiza la recogida de basura de Java se puede percibir de qué modo está utilizando la aplicación la memoria. La recogida de basura es uno de los pilares de Java. Dado que el que escribe la aplicación no tiene que preocuparse de gestionar la memoria, las aplicaciones Java resultan más robustas que las aplicaciones que se escriben en lenguajes que no ofrecen la recogida de basura. Esto es así siempre y cuando la aplicación no esté haciendo un uso abusivo de objetos. Es normal que la recogida de basura consuma entre el cinco y el veinte por ciento del tiempo de ejecución total de una aplicación que funcione correctamente. Si no se gestiona, la recogida de basura se puede convertir en el mayor cuello de botella de la aplicación, especialmente cuando se ejecuta en máquinas de servidor SMP.
Utilice la recogida de basura para evaluar el estado del rendimiento de la aplicación. Al supervisar la recogida de basura durante la ejecución de una carga de trabajo fija, los usuarios pueden saber si la aplicación está sobreutilizando objetos. También se puede utilizar la recogida de basura para detectar si falta memoria.
Utilice la recogida de basura y las estadísticas del almacenamiento dinámico de Resource Analyzer para evaluar el estado del rendimiento de la aplicación. Si se supervisa la recogida de basura, se puede detectar si falta memoria y si se están sobreutilizando objetos.
Para este tipo de investigación, establezca el mismo valor tanto para el tamaño mínimo como para el tamaño máximo del almacenamiento dinámico. Elija a un valor representativo y repetitivo de carga de trabajo que corresponda lo máximo posible con el uso en producción (errores de usuario y demás). También es importante permitir que la aplicación se ejecute durante varios minutos hasta que su estado se estabilice.
Para asegurarse de que las estadísticas sean representativas, ejecute la carga de trabajo fija hasta que la aplicación esté estable. Este proceso puede tardar varios minutos.Para ver si la aplicación está sobreutilizando objetos, consulte en Resource Analyzer los contadores del perfilador JVMPI. El tiempo medio entre las llamadas de recogida de basura debería ser cinco o seis veces la duración media de una sola recogida de basura. De lo contrario, la aplicación estaría dedicando más de un 15% de su tiempo en la recogida de basura. También, observe los números de los objetos liberados, asignados y movidos.
Si la información indica que existe un cuello de botella de la recogida de basura, existen dos modos de eliminarlo. La solución más asequible consiste en optimizar la aplicación implementando agrupaciones y antememorias de objetos. Utilice un perfilador de Java para determinar los objetos que deben examinarse. Si no es posible optimizar la aplicación, puede resultar útil añadir memoria, procesadores y clones. La memoria adicional permitirá que cada clon mantenga un tamaño de almacenamiento dinámico razonable. Los procesadores adicionales permitirán la ejecución simultánea de clones.
La falta de memoria en Java contribuye peligrosamente a que se produzcan cuellos de botella de recogida de basura. Resulta más dañina que la sobreutilización de memoria porque una falta de memoria en última instancia puede crear inestabilidad en el sistema. Con el tiempo, la recogida de basura se produce con mayor frecuencia hasta que finalmente se agota el almacenamiento dinámico y Java da un error con una excepción grave de Falta de memoria. La falta de memoria se produce cuando un objeto innecesario tiene referencias que nunca se suprimen. Esto se produce principalmente en las clases de colecciones, como Hashtable, porque la propia tabla siempre tendrá una referencia a un objeto, incluso cuando todas las referencias reales se han suprimido.
Una queja común es que las aplicaciones dejan de funcionar inmediatamente después de su despliegue en el entorno de producción. La causa suele ser que hay una carga de trabajo muy elevada. Esto es especialmente cierto en aplicaciones en las que falta memoria y donde la elevada carga de trabajo hace que la falta de memoria rápidamente sea mucho mayor y que se produzca una anomalía de asignación de memoria.
Las pruebas de falta de memoria están relacionadas con un aumento de los números. Las faltas de memoria se miden en términos de la cantidad de bytes o kilobytes que no pueden recogerse en la recogida de basura. Esta delicada tarea consiste en diferenciar estas cantidades de los tamaños de memoria útil y no utilizable que se esperan. El modo más fácil de realizar esta tarea es aumentar los números, con lo cual las diferencias serán más notables y resultará más fácil identificar las incoherencias. La siguiente es una lista de las conclusiones más importantes relacionadas con la falta de memoria:
Se pueden utilizar las pruebas repetitivas en el nivel del sistema o en el nivel de módulo. La ventaja de realizar las pruebas en el nivel de módulo es que el control es mejor. Cuando se define un módulo de modo que todo lo que sucede en dicho módulo sea confidencial y no cree efectos colaterales externos, incluido el uso de memoria, las pruebas de falta de memoria pueden resultar más fáciles. En primer lugar, se anota el uso de la memoria antes de ejecutar el módulo y luego se ejecuta de forma repetitiva un número fijo de casos de prueba. Al final de la ejecución de la prueba, el uso de la memoria actual debe ser siempre el que se ha anotado previamente y se comprueba si ha cambiado de forma drástica. Debe recordar, que se ha de forzar la recogida de basura cuando se anota el uso de memoria real. Para hacerlo, inserte System.gc() en el módulo en el que desea que se lleve a cabo la recogida de basura o utilice una herramienta de creación de perfiles que fuerce este suceso.
Considere los puntos siguientes cuando seleccione qué casos de prueba va a utilizar para comprobar la falta de memoria:
Resource Analyzer ayuda a determinar si falta memoria. Para obtener mejores resultados, repita los experimentos aumentando la duración, por ejemplo, 1000, 2000 y 4000 peticiones de página. El gráfico de Resource Analyzer con la memoria utilizada debería tener forma de diente de sierra. Cada descenso en el gráfico corresponde a una recogida de basura. Faltará memoria cuando se produzcan una de las situaciones siguientes:
Si el consumo del almacenamiento dinámico indica una posible falta de memoria cuando la carga de trabajo es elevada (es decir, el servidor de aplicaciones constantemente utiliza casi el 100% de la CPU) y, sin embargo, el almacenamiento dinámico parece recuperarse cuando la carga de trabajo es más ligera o prácticamente nula, esto es una indicación de que hay una fragmentación del almacenamiento dinámico. La fragmentación del almacenamiento dinámico puede ocurrir cuando la JVM puede liberar los objetos suficientes para satisfacer las peticiones de asignación de memoria durante los ciclos de recogida de basura, pero no tiene tiempo de compactar pequeñas áreas de memoria libre en el almacenamiento dinámico de modo que se conviertan en espacios contiguos más grandes.
Otra forma de fragmentación del almacenamiento dinámico sucede cuando se liberan pequeños objetos (de menos de 512 bytes). Los objetos se liberan pero el almacenamiento no se recupera, lo que da como resultado la fragmentación de la memoria.
La fragmentación del almacenamiento dinámico puede evitarse activando el distintivo -Xcompactgc en los argumentos de línea de mandatos de valores avanzados de la JVM. El distintivo -Xcompactgc garantiza que cada ciclo de recogida de basura eliminará la fragmentación pero tiene un ligero impacto en el rendimiento.
Los parámetros de almacenamiento dinámico de Java también influyen en el comportamiento de la recogida de basura. El aumento del tamaño de almacenamiento dinámico permite la creación de más objetos. Puesto que se tarda más en rellenar un almacenamiento dinámico mayor, la aplicación se ejecuta durante más tiempo antes de que se produzca la recogida de basura. Sin embargo, también se tarda más en compactar un almacenamiento dinámico mayor. La recogida de basura también tardará más.
La ilustración representa tres perfiles de CPU, cada uno de los cuales ejecuta una carga de trabajo fija con valores de almacenamiento dinámico de Java variables. En el perfil del medio, los valores son los tamaños de almacenamiento dinámico inicial y máximo o 128 MB. Se producen cuatro recogidas de basura. El tiempo total empleado en la recogida de basura es de un 15% de la ejecución total. Cuando se doblan los parámetros del almacenamiento dinámico a 256 MB, como en el perfil superior, aumenta la duración del tiempo de trabajo entre las recogidas de basura. Se producen únicamente tres recogidas de basura aunque también aumenta la duración de cada recogida de basura. En el tercer perfil, el tamaño de almacenamiento dinámico se reduce a 64 MB y muestra el efecto contrario. Con un almacenamiento dinámico menor, se reduce tanto el tiempo entre las recogidas de basura como el tiempo para cada una de ellas. Para las tres configuraciones, el tiempo total de recogida de basura es de aproximadamente un 15%. Eso muestra un concepto importante sobre el almacenamiento dinámico de Java y su relación con la utilización de objetos. Siempre hay un coste para la recogida de basura en aplicaciones Java.
Ejecute una serie de experimentos de prueba que varíen los valores del almacenamiento dinámico de Java. Por ejemplo, ejecute experimentos con 128 MB, 192 MB, 256 MB y 320 MB. Durante cada experimento, supervise la utilización total de memoria. Si aumenta el almacenamiento dinámico demasiado, se producirá una paginación. Utilice el mandato vmstat o Monitor de sistema de Windows NT/2000 para comprobar si hay paginación. Si se produce una paginación, reduzca el tamaño del almacenamiento dinámico o añada más memoria al sistema. Una vez finalizadas todas las ejecuciones, compare las siguientes estadísticas:
Si el tamaño libre del almacenamiento dinámico permanece en el 85 por ciento o más, puede disminuir los valores del tamaño máximo del almacenamiento dinámico porque el servidor de aplicaciones y la aplicación están utilizando una cantidad muy pequeña de la memoria que se ha asignado para el almacenamiento dinámico.
tcp_close_wait_interval/tcp_time_wait_interval de Solaris
tcp_fin_wait_2_flush_interval de Solaris
tcp_keepalive_interval de Solaris
Existen otros muchos parámetros TCP; su modificación puede afectar al rendimiento del entorno. Para obtener más información acerca del ajuste de la pila TCP/IP, consulte el sitio Web Tuning your TCP/IP Stack and More.
Antes de cambiar los tres parámetros TCP, el servidor se atascaba durante los períodos de mucha actividad. El mandato netstat indica que hay muchos sockets abiertos en el puerto 80 cuyo estado es CLOSE_WAIT o FIN_WAIT_2.
En ambas topologías, se ha seleccionado el valor de pasar por referencia de Object Request Broker y la base de datos del programa de fondo está en su propia máquina dedicada.
Además, si el uso del procesador que hacen las cuatro máquinas se aproxima al 100%, se puede añadir una quinta máquina. O si el cuadro del servidor Web no está ejecutándose a plena capacidad y el proceso del contenedor Web no es elevado, puede intentar liberar los procesadores de las cuatro máquinas pasando a la Topología B.
La misma relación se aplica al número de conexiones del gestor de sesiones.
El valor de MaxAppls debe ser igual o mayor que el número de conexiones.
Si utiliza la misma base de datos para la sesión y los orígenes de datos,
el valor de MaxAppls debe ser la suma del número de valores de conexión
del gestor de sesiones y de los orígenes de datos.
MaxAppls = (número de conexiones establecidas para el origen de datos + número de conexiones del gestor de sesiones) x número de clones
Después de calcular los valores MaxAppls correspondientes a la base de datos WAS y a cada una de las bases de datos de la aplicación, asegúrese de que el valor MaxAgents de DB2 es igual o superior a la suma de todos los valores MaxAppls.
MaxAgents = suma de MaxAppls para todas las bases de datos
En este apartado se describen las consideraciones a tener en cuenta a la hora de seleccionar y configurar el hardware en el que se ejecutarán los servidores de aplicaciones.
Deje al menos 512 MB de memoria para cada procesador.
Consulte el libro blanco WebSphere Application Server Admin Best Practices for Performance and Scalability para obtener información relacionada con la resolución de nombres de sistemas principales en el sistema principal del cliente de administración.
Este apartado trata las consideraciones a tener en cuenta al ajustar los sistemas operativos en el entorno del servidor.
Nota: estos dos parámetros deben utilizase conjuntamente cuando se ajuste WebSphere Application Server en un sistema operativo Windows NT/2000.
ulimit -n 2000Para máquinas SMP con clones, emita el mandato siguiente:
ulimit -unlimited
Utilice el mandato ulimit -a para visualizar los valores actuales correspondientes a todas las limitaciones de recursos del sistema.
ulimit -n 1024
Utilice ulimit -a para visualizar los valores actuales correspondientes a todas las limitaciones de recursos del sistema.
El servidor puede atascarse durante determinados períodos de mucha actividad. Si esto sucede, el mandato netstat mostrará que muchos de los sockets abiertos en el puerto 80 estaban en estado CLOSE_WAIT o FIN_WAIT_2. Se han producido retardos visibles durante hasta cuatro minutos, durante los cuales el servidor no ha enviado ninguna respuesta pero el uso de CPU se ha mantenido alto, con toda la actividad en los procesos de sistema.
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 60000
El servidor puede atascarse durante determinados períodos de mucha actividad. El mandato netstat ha indicado que muchos de los sockets abiertos en el puerto 80 estaban en estado CLOSE_WAIT o FIN_WAIT_2. Se han producido retardos visibles durante hasta cuatro minutos, durante los cuales el servidor no ha enviado ninguna respuesta, pero el uso de CPU se ha mantenido alto, con toda la actividad en los procesos de sistema.
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval ndd -set /dev/tcp tcp_keepalive_interval 300000
Los clientes han informado que han modificado satisfactoriamente otros parámetros TCP de Solaris, incluidos los siguientes:
tcp_conn_req_max_q tcp_comm_hash_size tcp_xmit_hiwat
Aunque no se han observado diferencias importantes en el rendimiento después de aumentar estos valores, es posible que el sistema salga beneficiado.
Se establece mediante la entrada de /etc/system:
set semsys:seminfo_semume = 1024
Se establece mediante la entrada de /etc/system:
semsys:seminfo_semopm = 200
Los valores de HP-UX 11 se pueden modificar para mejorar significativamente el rendimiento de WebSphere Application Server.
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
La salida del mandato proporciona las características del sistema operativo actual del ejecutable del proceso.
Consulte la página de Web Hewlett Packard para obtener más detalles sobre esta modificación.
connect requests dropped due to full queue
ndd -set /dev/tcp tcp_conn_request_max 1024
Consulte la siguiente página Web de Hewlett Packard para obtener más detalles acerca de esta modificación.
| Parám. del kernel | Ajuste de WebSphere Application Server | Ajuste en DB2 | Ajuste en Oracle |
| maxdsiz | No ajustado | No ajustado | No ajustado |
| maxdsiz_64b | No ajustado | No ajustado | No ajustado |
| maxuprc | 512 | ||
| maxfiles | 2.048 | ||
| maxfiles_lim | 2.048 | ||
| nkthreads | 10.000 | ||
| max_thread_proc | 2.048 | ||
| nproc | 1.028 | ||
| nflocks | 8.192 | ||
| ninode | 2.048 | ||
| nfile | 8.192 | ||
| msgseg | 32.767 | ||
| msgmnb | 65.535 | ||
| msgmax | 65.535 | ||
| msgtql | 1.024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1.024 | 200 | |
| semmnu | 1.024 | ||
| shmmax | 966.367.642 | 1 GB | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
Consulte la siguiente página Web de Hewlett Packard para obtener más información sobre los parámetros del kernel de HP-UX 11.
El producto WebSphere Application Server proporciona plug-ins para varias marcas de servidores Web y sus versiones. Cada combinación de servidor Web y sistema operativo ofrece distintos parámetros de ajuste que influyen en el rendimiento de las aplicaciones.
Este apartado trata sobre los valores de ajuste del rendimiento asociados a los servidores Web.
IHS es un servidor multiproceso de una sola hebra. Para obtener más información, consulte esta página Web sobre el ajuste de IBM HTTP Server
La configuración por omisión de iPlanet Web Server Enterprise Edition proporciona un servidor de un solo proceso y de varias hebras.
Para ver si existe un atasco en el servidor Web, consulte sus estadísticas perfdump. Consulte los datos siguientes:
Nota: es posible que también sea necesario comprobar los permisos de sePlugin:
Puede evitar esta condición utilizando el parámetro ListenBackLog para aumentar el número de peticiones que IIS mantiene en su cola.
MaxPoolThreads, PoolThreadLimit
IBM HTTP Server se puede configurar fácilmente. Los valores por omisión suelen resultar aceptables.
Cómo ver la utilización de hebras: hay dos modos de averiguar el número de hebras que se están utilizando bajo carga:
Realice los pasos siguientes para utilizar el estado del servidor de IBM HTTP Server:
Cada proceso de WebSphere Application Server tiene varios parámetros que influyen en el rendimiento de las aplicaciones. Cada servidor de aplicaciones del producto WebSphere Application Server consta de un contenedor EJB y de un contenedor Web.
Utilice la consola de administración de WebSphere Application Server para configurar y ajustar las aplicaciones, los contenedores Web, los contenedores EJB, los servidores de aplicaciones y los nodos del dominio de administración.
Cómo ver el uso de parámetros: en UNIX, utilice el mandato ps -efl para ver la prioridad de procesos actual.
Para dirigir las peticiones de servlets desde el servidor Web a los contenedores Web, el producto establece una cola de transporte entre el plug-in del servidor Web y cada contenedor Web.
Resource Analyzer muestra un valor que se denomina porcentaje de número máximo que se utiliza para determinar durante cuánto tiempo se han estado utilizando las hebras configuradas. Si este valor se muestra constantemente con dos dígitos, entonces el contenedor Web puede ser el que está creando un cuello de botella y deberá aumentarse el número de hebras.
Se crea una antememoria del tamaño solicitado para cada hebra. El número de hebras lo determina el valor del número máximo de hebras del contenedor Web.
Nota: una antememoria de más tamaño utiliza más almacenamiento dinámico de Java, por lo tanto, es posible que tenga que aumentar el tamaño máximo del almacenamiento dinámico de Java. Por ejemplo, si cada entrada de antememoria requiere 2 KB, el número máximo de hebras está establecido en 25 y el tamaño de la antememoria de invocación de URL es de 100, se necesitan 5 MB de almacenamiento dinámico de Java.
Utilice Resource Analyzer para ver información sobre el rendimiento de los beans.
La información de seguridad perteneciente a beans, permisos y credenciales se almacena en antememoria. Cuando transcurre el tiempo de espera de la antememoria, toda la información que hay almacenada en antememoria deja de ser válida. Las siguientes peticiones de información dan lugar a una búsqueda en la base de datos. A veces, para adquirir la información hay que invocar un enlace LDAP (Lightweight Directory Access Protocol) o una autenticación nativa, y ambas son operaciones que tienen cierto coste para el rendimiento.
Intente averiguar cuáles es la mejor combinación para la aplicación, basándose en el modo en que se utiliza y en las necesidades de seguridad del sitio.
Las siguientes propiedades del sistema determinan el tamaño inicial de las Hashtables primaria y secundaria de la antememoria que pueden afectar a la frecuencia con que se renuevan las Hashtables y a la distribución de los algoritmos hash. Cuanto mayor sea el número de valores hash disponibles, menos probabilidades habrá de que se produzca una colisión hash y mayor será la probabilidad de que la recuperación sea más lenta. Si una Hashtable de antememoria consta de varias entradas, al aumentar la capacidad de la tabla se permitirá que las entradas se inserten de modo más eficaz en lugar de dejar que el proceso de renovación de la Hashtable determine el crecimiento de la tabla. La renovación de la Hashtable hace que cada entrada se mueva una vez hecha.
La función Secure Association Service (SAS) establece una conexión SSL únicamente si se trata de una conexión de una JVM con otra JVM. Por lo tanto, si todos los beans se encuentran en la misma JVM, el SSL que utiliza SAS no debería perjudicar al rendimiento.
Utilice la pestaña Servicios y, a continuación, Editar propiedades de Object Request Broker, para que el servidor por omisión o cualquier servidor de aplicaciones que esté configurado en el dominio de administración, establezca estos parámetros.
AVISO: pasar por referencia puede ser peligroso y puede generar resultados imprevistos. Si una referencia de objeto se modifica mediante un método remoto, el llamante puede ver el cambio.
Si el servidor de aplicaciones espera una carga de trabajo importante para las peticiones de enterprise beans, la configuración de ORB resulta crucial. Observe las propiedades siguientes:
Al utilizar las hebras JNIReader se necesita menos memoria porque se debe crear un grupo de hebras fijo. También ahorra tiempo ya que las hebras solamente se crean una vez durante la inicialización y no se destruyen nunca. JNIReader es una implementación de C-nativo y debería ser más rápida que la hebra reader por omisión.
AVISO: asegúrese de que la implementación de la biblioteca JNI de JNIReader esté en el directorio bin de WebSphere Application Server. En la plataforma Intel, la biblioteca es Selector.dll y en UNIX es libSelector.a o libSelector.so. En Unix, si falta el prefijo "lib", debe cambiarse el nombre del archivo.
Ajuste de JVM
JVM dispone de varios parámetros de ajuste que pueden afectar al rendimiento de los servidores de WebSphere Application Server (formados principalmente por aplicaciones Java), así como al rendimiento de las aplicaciones del usuario.
En general, al aumentar el tamaño de almacenamiento dinámico de Java se mejora la productividad siempre que el almacenamiento dinámico resida en la memoria física. Cuando el almacenamiento dinámico empieza a pasar a disco, el rendimiento de Java se ve drásticamente perjudicado. Por lo tanto, el tamaño máximo del almacenamiento dinámico debe ser lo suficientemente bajo como para contener el almacenamiento dinámico en la memoria física.
El uso de la memoria física debe compartirse entre JVM y otras aplicaciones, como por ejemplo, la base de datos. Para asegurarse, utilice un almacenamiento dinámico más pequeño (por ejemplo 64 MB, en máquinas con menos memoria).
Intente utilizar un almacenamiento dinámico máximo de 128 MB en una máquina más pequeña (es decir, menos de 1 GB de memoria física), 256 MB para sistemas con 2 GB de memoria y 512 MB para sistemas más grandes. El punto de partida dependerá de la aplicación.
Si se realizan ejecuciones de rendimiento y se necesitan resultados que se repitan varias veces, el valor máximo y el inicial deben coincidir. Esto eliminará cualquier crecimiento en el almacenamiento dinámico durante la ejecución. Para sistemas de producción en los que el tamaño del grupo de trabajo de las aplicaciones Java no se comprende bien, un valor inicial de un cuarto del valor máximo constituye un buen punto de partida. JVM intentará adaptar el tamaño del almacenamiento dinámico al grupo de trabajo de la aplicación Java.
Utilice la propiedad de línea de mandatos del servidor por omisión o de cualquier servidor de aplicaciones adicional que haya configurado en el dominio de administración para establecer los parámetros de JVM:
WebSphere Application Server está estrechamente integrado con la base de datos soportada que elija. Para más información sobre productos de bases de datos soportados, consulte el sitio Web sobre los requisitos previos del producto en www.ibm.com/software/webservers/appserv/library.html. WebSphere Application Server utiliza la base de datos como almacén de reserva persistente de administración, así como para almacenar el estado de las sesiones y los datos de los enterprise beans correspondientes a la aplicación.
Si la aplicación utiliza el estado de la sesión de WebSphere Application Server, la agrupación de conexiones de la base de datos JDBC o los enterprise beans, preste especial atención cuando configure estos recursos y sus valores de base de datos en el dominio de administración. Durante la instalación de WebSphere Application Server, se establece una base de datos llamada WASnn, donde nn es el identificador del release, aunque se puede utilizar un nombre distinto. En este documento se presupone que se ha utilizado WAS40.
Por cuestiones de escalabilidad, es preferible que establezca la base de datos en otra máquina, especialmente si utiliza un clúster. Esto se refiere a la base de datos de WebSphere Application Server, cualquier base de datos de aplicaciones y la base de datos de sesiones de WebSphere Application Server (si se utiliza la sesión persistente).
Si está utilizando clones, tenga en cuenta que existe una agrupación de origen de datos para cada clon. Esto es importante a la hora de configurar el máximo de conexiones del servidor de base de datos.
Utilice Resource Analyzer para averiguar el número óptimo de conexiones de la agrupación que puede disminuir los valores de estos números. Si Percent Used siempre tiene un valor bajo, puede disminuir el número de conexiones de la agrupación.
En plataformas UNIX, se crea un proceso de DB2 separado para cada conexión. Esto afecta rápidamente al rendimiento de sistemas con baja memoria y se pueden producir errores.
Cada transacción de EJB de entidad requiere una conexión adicional con la base de datos, específicamente para manejar la transacción. No olvide tener esto en cuenta cuando calcule el número de conexiones de origen de datos. Se puede producir un punto muerto si la aplicación necesita más de una conexión simultánea por hebra y la agrupación de conexiones de base de datos no es lo suficientemente grande para el número de hebras. Supongamos que cada una de las hebras de aplicación necesita dos conexiones simultáneas con la base de datos y que el número de hebras equivale al tamaño máximo de la agrupación de conexiones. Se puede producir un punto muerto cuando se dan las dos situaciones siguientes:
Para evitar que se produzca un punto muerto en este caso, el valor de la agrupación de conexiones de base de datos debe establecerse como mínimo en un valor más, para que al menos una de las hebras que está en espera pueda completar la segunda conexión con la base de datos, con lo que liberaría conexiones de base de datos.
Para evitar que se produzca un punto muerto, codifique la aplicación para que utilice como máximo una conexión por hebra. Si la aplicación se codifica para que necesite C conexiones de base de datos simultáneas por hebra, la agrupación de conexiones debe dar soporte como mínimo al número de conexiones siguiente, donde T es el número máximo de hebras.
T * (C - 1) + 1
Los valores de la agrupación de conexiones están directamente relacionados con el número de conexiones que el servidor de base de datos soporta de acuerdo con su configuración. Si aumenta el número máximo de conexiones de la agrupación y no aumenta los valores correspondientes de la base de datos, se produce una anomalía en la aplicación y se mostrarán errores de excepción SQL en el archivo stderr.log.
Nota: las sentencias preparadas se han optimizado para manejar sentencias SQL paramétricas que pueden beneficiarse del proceso de precompilación. Si el controlador JDBC especificado en el origen de datos da soporte a la precompilación, la creación de la sentencia preparada enviará la sentencia a la base de datos para su precompilación. Puede que algunos controladores no den soporte a la precompilación. En este caso, puede que la sentencia no se envíe a la base de datos hasta que se ejecute la sentencia preparada.
El origen de datos de WebSphere Application Server gestiona una agrupación de conexiones de base de datos, así como una antememoria de objetos de sentencias preparadas asociada. Las sentencias preparadas se almacenan en antememoria con un código que identifica cada conexión que las ejecuta. La relación entre las sentencias SQL utilizadas, la antememoria de sentencias preparadas, un origen de datos y una base de datos es un punto que vale la pena revisar. Suponga que una aplicación utiliza 5 sentencias SQL: 2 select, 1 delete, 1 insert y 1 update.
El origen de datos anterior tiene configurado un máximo de tres conexiones simultáneas con la base de datos. Las conexiones ya se han creado y se han ejecutado muchas sentencias SQL. La antememoria de sentencias preparadas se ha configurado para que albergue 10 sentencias. Hay tres sentencias preparadas almacenadas en antememoria para las conexiones 1 y 2. La conexión 3 tiene cuatro sentencias almacenadas en la antememoria. Puesto que las sentencias se compilan en sentencias preparadas a medida que se utilizan, la antememoria de sentencias preparadas refleja los patrones de uso de bases de datos de la aplicación. La antememoria de sentencias preparadas implementa una cola FIFO (First-In, First-Out). Un objeto de sentencias preparadas, que representa una determinada sentencia SQL, puede aparecer varias veces en la antememoria de sentencias preparadas. En concreto, puede aparecer una vez por cada conexión de la agrupación de conexiones. Por ejemplo, las sentencias 1 y 2 aparecen en tres ocasiones, una por cada conexión. La sentencia 3 no aparece para la conexión 3 y las sentencias 4 y 5 sólo aparecen para la conexión 3. Por lo tanto, puede que se tarde más tiempo en ejecutar las sentencias 4 y 5 si se llevan a cabo en las conexiones 1 y 2 debido a que es necesario repetir la compilación para estas conexiones. Una alternativa mejor para este ejemplo consiste en especificar un tamaño de 15 (cinco sentencias preparadas para cada una de las tres conexiones) para la antememoria de sentencias preparadas.
Resource Analyzer puede ayudarle a ajustar este valor de modo que se minimicen las entradas descartadas en la antememoria. Utilice una carga de trabajo estándar que represente un número típico de peticiones de clientes de entrada, utilice un número fijo de iteraciones y un conjunto estándar de valores de configuración.
Siga estas instrucciones para utilizar Resource Analyzer:
El mejor valor para Origen de datos > Agrupación de conexiones > Tamaño de la antememoria de sentencias es el valor que se utiliza para obtener un valor de cero o el valor más bajo para PrepStmt Cache Discards. Esto indica cuál es el número más eficaz para una carga de trabajo típica.
Otros parámetros JDBC
Además de establecer el tamaño de la antememoria de sentencias preparadas, puede establecer otras propiedades específicas de los controladores JDBC.
Por ejemplo, si utiliza Oracle, puede aumentar el número de filas que se
han de recuperar mientras se obtienen grupos de resultados con la
sentencia siguiente:
name="defaultRowPrefetch", value="25"
Entre estos tipos de propiedades de personalizadas en la pestaña General de la base de datos.
Para establecer BUFFPAGE en un valor n, emita el mandato DB2 update db cfg for x using BUFFPAGE n y asegúrese de que NPAGES sea -1 como se indica a continuación:
db2 <-- entra en la modalidad de mandatos de DB2; de lo contrario la sentencia
"select" siguiente no funcionará
connect to x <-- (donde x es el nombre de la base de datos DB2 concreta)
select * from syscat.bufferpools
(y anote el nombre del valor por omisión, que puede ser: IBMDEFAULTBP)
(si NPAGES ya es -1, es correcto y no tiene que emitir el siguiente mandato)
alter bufferpool IBMDEFAULTBP size -1
(vuelva a emitir la sentencia "select" anterior; ahora NPAGES debería ser -1)
Un nivel de optimización 9 hace que DB2 dedique mucho tiempo y todas sus estadísticas disponibles a la optimización del plan de acceso.
Para obtener más información, consulte la documentación de DB2 y el sitio Web de IBM DB2.
Para poder ver si se ha ejecutado runstats, emita el siguiente mandato en DB2 CLP:
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
Si no se ha ejecutado runstats, nleaf y nlevels tendrán como entrada -1 y la entrada de stats_time estará vacía "-".
Si ya se ha ejecutado runstats, se mostrará también la indicación de la hora real en que se ha completado runstats bajo stats_time. Si cree que la hora que se muestra para el mandato runstats anterior es demasiado antigua, vuelva a ejecutar runstats.
Los nuevos valores surten efecto de forma inmediata.
Los valores siguientes son varios medidores relacionados con MinCommit de DB2:
Para obtener información adicional sobre cómo establecer los parámetros de gestión de sesiones, consulte el artículo 4.4.1.1 Modelo y entorno de programación de sesiones de InfoCenter.
Se puede ver la utilización de este parámetro habilitando el rastreo en el componente cmm.
Debe utilizarse un valor de 1 si desea que los mensajes se procesen en serie, es decir, que se utilice solamente una instancia de bean de mensajes para procesar un mensaje después de otro.
Un valor 20 proporcionará el mejor rendimiento. Si se aumenta por encima de este valor no se aumentará el rendimiento. Según el tipo de mensaje, la cantidad de trabajo y los recursos disponibles, se debe utilizar un valor entre 10 y 20 para obtener el máximo rendimiento de mensajes.
Aumentar el rendimiento de los mensajes depende de diferentes factores como, por ejemplo, los recursos del sistema y la configuración de la escucha. Los recursos del sistema hacen referencia al número y a la potencia de los procesadores. La configuración de la escucha es el número de sesiones que se utilizan y las interacciones JMS. En las interacciones de JMS se incluye la contención a la hora de compartir el acceso a los recursos del gestor de MQ Server subyacentes.
Siga los siguientes pasos:
En el menú Inicio seleccione Programas > Herramientas
administrativas > Monitor de sistema