Indicadores de rendimiento de la red, investigación de pruebas y optimización (venga y vea los maestros)

Enviar esta página por correo electrónico

Código de muestra

Nivel: principiante

Marty Lurie (lurie@us. ibm.com), Especialista en tecnología de la información de IBM

29 de mayo de 2006

Este artículo describe cómo optimizar WebSphere Application Server V6 para obtener la máxima mejora del rendimiento al mínimo costo. Se centra en la optimización de la línea de comandos utilizando wsadmin y Jython en lugar de utilizar tecnologías de interfaz gráfica de usuario. Al aplicar un conjunto de métodos empíricos, WebSphere Application Server puede utilizar completamente los recursos de hardware disponibles con un mínimo esfuerzo administrativo. Las técnicas descritas aquí se aplican a cualquier problema de optimización del rendimiento; sólo ciertos métodos empíricos son específicos de WebSphere.

Introducción

Si es una de esas personas que, después de poner en funcionamiento WebSphere Application Server, está demasiado ocupada con otras cosas para estudiar la documentación relacionada con la optimización del rendimiento (consulte Recursos ). Bueno, ha venido al lugar correcto: este artículo está diseñado para ayudarlo a identificar 20 actualizaciones de rendimiento que pueden brindarle 80 mejoras de rendimiento. Este artículo se centrará en el producto base de WebSphere Application Server; el siguiente artículo cubrirá la implementación de red de WebSphere Application Server.

Las ganancias de rendimiento derivadas de la optimización de la infraestructura de aplicaciones no se pueden comparar con las espectaculares ganancias de rendimiento obtenidas al corregir aplicaciones mal codificadas. Algunas aplicaciones no tienen cláusulas donde en las consultas de la base de datos; algunas aplicaciones llaman a wait() para siempre; algunas aplicaciones crean generadores de interbloqueos; algunas aplicaciones tienen una sesión HTTP enorme; algunas aplicaciones seleccionan * e intentan almacenar en caché el nivel medio (y lo hacen en gigabytes); !) Este artículo le presentará algunas de las ventajas de HTTPSession. Este artículo le presentará algunas técnicas de optimización excelentes, pero es la aplicación en sí la que ofrecerá resultados verdaderamente significativos. Sí, esto significa que los desarrolladores de aplicaciones y los administradores de servidores deben comunicarse con regularidad.

Este artículo incluye el siguiente contenido:

Entorno de prueba de rendimiento

Identificación de enlaces débiles

Herramientas de prueba

Simulación de este artículo Entornos utilizados en

Saneamiento

Obtener recuentos de referencia de rendimiento

Optimizar registros/registro

Uso de CPU

Uso de memoria

Otros factores ambientales

Implementar optimización de la experiencia Jython

Recolección de basura (GC) redundante de JVM

Configuración de JVM

Configuración del grupo de conexiones

Habilitar el almacenamiento en caché de servlets

Grupo de subprocesos del contenedor web

Ideas de optimización avanzadas: divulgación completa de SpecJ

Entorno de prueba de rendimiento

Identificar debilidades

Necesita un entorno de prueba que sea lo más cercano posible al entorno de producción. Si está utilizando un almacén de datos de varios gigabytes, es posible que su sistema de prueba deba ser más pequeño. Sin embargo, cualquier diferencia entre los entornos de rendimiento y producción puede generar costosos errores de inferencia. No hay razón para que una gran empresa afirme que no puede proporcionar servidores de prueba de rendimiento del mismo tamaño. Es posible que los entornos de prueba más pequeños no expongan problemas existentes en ciertas áreas, como operaciones de bloqueo, registro, sesiones HTTP, recolección de basura, grupos de conexiones, CPU, memoria, bases de datos, redes o aplicaciones.

Arneses de prueba: encontrar una manera

Crear arneses de prueba reales es un paso crítico para una optimización efectiva. Si la carga de trabajo que impone a su servidor de prueba no refleja lo que realmente está sucediendo en su sitio, ¡sus optimizaciones no resolverán el problema! Existen muchos productos de prueba de software comercial y de código abierto (consulte Recursos a continuación). Puede comprender escenarios de prueba reales viendo los registros del servidor existentes. Este historial no le ayudará a la hora de introducir una nueva aplicación, por lo que es importante contar con el mejor escenario posible.

Herramientas de prueba: rompiendo límites

La optimización está diseñada para encontrar problemas y resolverlos. Algunos problemas pasarán desapercibidos si la prueba no carga el servidor hasta el punto de ruptura, así que asegúrese de que el servidor esté cargado más allá del tráfico máximo esperado. Hacerlo proporciona un margen de error para la definición del arnés de prueba. Optimice las cargas en el peor de los casos para que pueda alcanzar valores de rendimiento con cargas más altas cuando entre en producción. De esta manera, sabrá qué tan seguro es su margen de error y cuándo necesita ampliarlo para aplicaciones muy populares. Los creadores de aplicaciones no deben desarrollar métodos de prueba porque conocen las condiciones límite supuestas y evitarán intencionalmente crear casos de prueba que superen estas condiciones. ¡Las cargas de trabajo de producción no son tan amigables!

Algunas pruebas aumentan modestamente el número de usuarios, lo que da como resultado un gráfico de rendimiento bastante lineal. Pero la llegada real de usuarios tiende a ser agrupada e irregular, por lo que es necesario probar estas condiciones antes de ponerlas en producción.

Si tiene otros usuarios en su máquina de prueba, es importante informarles sobre su plan de prueba, de lo contrario pueden pensar que tienen algún tipo de problema grave, como un ataque de denegación de servicio.

Entorno de prueba utilizado en este artículo

Los resultados de este artículo provienen de un programa de capacitación de IBM que utiliza puntos de referencia internos de WebSphere Trade6 para capacitar a los participantes en la optimización del rendimiento en un entorno competitivo de alta presión. . El entorno de prueba utiliza Red Hat Enterprise Linux V3, WebSphere Application Server V6.0.1, DB2 V8.2 y Apache JMeter. Estos productos se instalarán bajo VMWare V5.0. Dos computadoras portátiles IBM ThinkPad® están conectadas mediante un cable cruzado Ethernet. El servidor de aplicaciones se ejecuta en una computadora y las herramientas de prueba y la base de datos se ejecutan en otra.

Para simplificar su entorno de optimización del rendimiento y reducir la probabilidad de errores, debe utilizar scripts de shell para iniciar diferentes componentes. El Listado 1 a continuación muestra un script de ejemplo llamado go_trade6. El script inicia el punto de referencia de principio a fin, incluido WebSphere Application Server, el servidor DB2, el programa JMeter y xterm para monitorear top y vmstat.

Script para iniciar todos los componentes del entorno de prueba

xterm -exec top amp;

xterm -exec vmstat 3 amp;

su - -c db2start db2inst1

#su - -c oninit informix

startWAS

mozilla amp;

# inicio del arnés de prueba

cd /root /trade6/jakarta-jmeter-2.0.2/bin

/opt/IBMJava2-141/bin/java ApacheJMeter.jar -t tradebuysell.jmx amp;

# leer wastecpu.c

wastecpu amp;

wastecpu amp

exportar PATH=$PATH:/opt/IBM/WebSphere/AppServer/bin