Encuentre y corrija 15 cuellos de botella de rendimiento

"Cuello de botella" es un término maravillosamente descriptivo. Describe una restricción artificial sobre alguna forma de comunicación, interacción o transferencia de información. Y lleva a uno a creer que una combinación mágica de suerte, dinero e ingenio puede romper ese cuello de botella y dejar fluir todas las cosas buenas.

El problema con los cuellos de botella en el rendimiento es que pueden ser difíciles de identificar. ¿Es la CPU? ¿La red? ¿Un código torpe? A menudo, el culpable más obvio es en realidad aguas abajo de algo más grande y desconcertante. Y cuando los acertijos de desempeño siguen sin resolverse, la administración de TI puede encontrarse ante la elección de Hobson entre admitir ignorancia e inventar excusas.

Afortunadamente, al igual que con los diagnósticos médicos o el trabajo de detective, la experiencia ayuda. Basándonos en nuestros años de investigación y experimentación, hemos recopilado 15 de las dolencias más probables, y soluciones sugeridas, para ayudar a su operación de TI a rastrear y resolver problemas de rendimiento.

Algunos de estos cuellos de botella son más obvios que otros. Lo más probable es que tengas algo que decir sobre algunos de tus propios spoilers furtivos (y nos encantaría escuchar tus historias sobre ellos). Pero al identificar los asesinos de velocidad comunes en todas las disciplinas de TI, esperamos impulsar su búsqueda para crear la infraestructura de mayor rendimiento que sus recursos permitan.

No. 1: Probablemente no sean los servidores

Las actualizaciones del servidor solían marcar la diferencia, razón por la cual el viejo dicho "Cuando todo lo demás falla, utilice más hardware" persiste hoy. Eso sigue siendo cierto en algunos casos. Pero, ¿cuánto de TI es realmente tan intensivo en computación? Por lo general, puede ahorrar mucho tiempo y dinero apartando su ojo peludo del hardware del servidor. El extremo inferior del espectro de servidores tiene potencia más que suficiente para manejar las tareas diarias.

He aquí un ejemplo concreto. En una red de más de 125 usuarios, un controlador de dominio de Windows de edad avanzada parecía estar listo para ser reemplazado. Este servidor originalmente ejecutaba Windows 2000 Server y se actualizó a Windows Server 2003 hace algún tiempo, pero el hardware permaneció sin cambios. Este HP ML330 con una CPU de 1 Ghz y 128 MB de RAM funcionaba como un controlador de dominio de Active Directory con todas las funciones de AD FSMO, ejecutando servicios DHCP y DNS, así como con IAS (Servicios de autenticación de Internet).

Melaza, ¿verdad? De hecho, hizo bien el trabajo. Su reemplazo fue un HP DL360 G4 con una CPU de 3Ghz, 1GB de RAM y unidades SCSI duplicadas de 72GB. Con todos esos servicios, casi no ejecuta ninguna carga y la diferencia de rendimiento es imperceptible.

Es fácil identificar aplicaciones que consumirán toda su CPU y memoria, pero tienden a ser bastante especializadas. Para casi todo lo demás, la humilde caja de productos básicos funcionará.

No. 2: Acelere esas consultas

Puede crear la aplicación más ingeniosa del mundo, pero si el acceso a los servidores de bases de datos back-end crea un cuello de botella, sus usuarios finales o clientes no estarán contentos. Por lo tanto, ajuste esas consultas a la base de datos y maximice el rendimiento.

Tres medidas básicas pueden ayudarlo a mejorar el rendimiento de las consultas. En primer lugar, la mayoría de los productos de base de datos incluyen herramientas (como DB2 UDB para Visual Explain de iSeries) que pueden analizar su consulta durante el desarrollo, proporcionando comentarios sobre la sintaxis y el tiempo aproximado de las distintas secciones de las sentencias SQL. Con esta información, localice las partes más largas de la consulta y divídalas más para ver cómo puede acortar el tiempo de ejecución. Algunos productos de bases de datos también incluyen herramientas de asesoramiento de rendimiento, como el Monitor de diagnóstico automático de bases de datos de Oracle, que brindan recomendaciones (como sugerirle que cree un nuevo índice) para acelerar las consultas.

A continuación, active las herramientas de supervisión de la base de datos en un servidor intermedio. Puede utilizar un producto de monitoreo de terceros, como NetVigil de Fidelia, si su base de datos carece de soporte de monitoreo. Con los monitores habilitados, genere tráfico contra el servidor de la base de datos utilizando scripts de prueba de carga. Examine los datos recopilados para ver cómo se desempeñaron sus consultas bajo carga; esta información puede llevarlo a realizar más ajustes en las consultas.

Si tiene suficientes recursos de servidor para imitar su entorno de producción de carga de trabajo mixta de manera bastante cercana, puede ejecutar una tercera ronda de ajuste de consultas utilizando una herramienta de prueba de carga, como OpenSTA, además de monitoreo de base de datos para ver cómo se desempeñan sus consultas junto con otras aplicaciones que llegan al base de datos.

A medida que cambian las condiciones de la base de datos, con el crecimiento del volumen, la eliminación de registros, etc., siga probando y ajustando. A menudo vale la pena el esfuerzo.

No. 3: ¿Qué costo, protección contra virus?

La protección antivirus en servidores críticos es un requisito básico, especialmente para servidores Windows. Sin embargo, el impacto puede ser doloroso. Algunos escáneres de virus son más molestos que otros y pueden reducir significativamente el rendimiento del servidor.

Intente ejecutar pruebas de rendimiento con y sin su escáner de virus en ejecución para determinar el impacto. Si ve una mejora notable sin el escáner, es hora de buscar otro proveedor. Compruebe también las características específicas. Desactive los análisis en tiempo real y, con bastante frecuencia, aumentará el rendimiento.

No importa qué tan bien redactada su lógica empresarial, cuando la implemente en el nivel intermedio, deberá ajustar el entorno de ejecución del servidor de aplicaciones para maximizar el rendimiento.

Como un estéreo clásico con montones de perillas para ajustar la calidad del sonido, los servidores de aplicaciones de proveedores como BEA, IBM y Oracle proporcionan un conjunto de controles vertiginoso. El truco consiste en girar las perillas de la manera correcta, según los atributos de su aplicación.

No. 4: Maximizar el nivel medio

No importa qué tan bien redactada su lógica empresarial, cuando la implemente en el nivel intermedio, deberá ajustar el entorno de ejecución del servidor de aplicaciones para maximizar el rendimiento.

Como un estéreo clásico con montones de perillas para ajustar la calidad del sonido, los servidores de aplicaciones de proveedores como BEA, IBM y Oracle proporcionan un conjunto de controles vertiginoso. El truco consiste en girar las perillas de la manera correcta, según los atributos de su aplicación.

Por ejemplo, si su aplicación tiene muchos servlets, querrá habilitar el almacenamiento en caché de servlets. Del mismo modo, si su aplicación usa muchas declaraciones SQL para admitir una gran base de usuarios, querrá habilitar el almacenamiento en caché de declaraciones preparadas y establecer el tamaño máximo de la memoria caché para que sea lo suficientemente grande como para admitir la carga de trabajo prevista.

Una de las áreas principales en las que el ajuste del rendimiento puede ayudar realmente es con el grupo de conexiones de la base de datos. Establezca las conexiones mínimas o máximas demasiado bajas y seguramente creará un cuello de botella. Configúrelos demasiado altos y probablemente verá una desaceleración como resultado de la sobrecarga adicional necesaria para mantener el grupo de conexiones más grande.

Si conoce la carga de trabajo prevista, ajuste el tiempo de ejecución del servidor de aplicaciones activando las herramientas de supervisión del rendimiento, como Tivoli Performance Viewer para WebSphere de IBM, en un servidor de aplicaciones intermedio. Genere la cantidad de carga de trabajo que espera utilizando una herramienta de generación de carga, luego guarde los resultados de monitoreo y reprodúzcalos para analizar qué perillas necesitan ajustar.

Cuando está en producción, es una buena idea activar la supervisión pasiva de baja sobrecarga para controlar el tiempo de ejecución. Si su carga de trabajo cambia con el tiempo, querrá ejecutar una nueva revisión de rendimiento.

No. 5: Optimice la conectividad de la red

La mayoría de los servidores empresariales de nivel medio ahora tienen NIC de doble gigabit, pero la mayoría de ellos no utilizan el segundo conducto. Además, los precios de los conmutadores gigabit se han desplomado. Con un enlace de 120 MBps a su servidor de archivos, varios clientes de 100 megabits pueden acceder simultáneamente a los archivos a velocidad de cable.

Incluso sin conmutación de gigabits, la vinculación NIC debería ser un elemento básico. En su forma más simple, la vinculación de dos NIC le brinda redundancia, pero agrega un equilibrio de carga de transmisión y puede duplicar de manera efectiva el ancho de banda de salida. El uso de equipos asistidos por conmutadores proporcionará el mismo efecto en el tráfico entrante. Casi todos los principales proveedores de servidores ofrecen controladores de equipos NIC, y también existen utilidades de terceros. Es un aumento de ancho de banda grande y económico.

No 6: liquidación de sus servidores web

¿Realmente hay mucho que puede hacer para ajustar un servidor web y maximizar el rendimiento? De hecho, la hay, principalmente al ajustar un puñado de configuraciones críticas para que coincida con el tráfico de producción que espera.

Para los servidores web que ya están en producción, comience por recopilar estadísticas de servidores web en tiempo real (la mayoría de los principales servidores web tienen esa funcionalidad incorporada). Luego, pase a la puesta en escena para determinar qué parámetros, si los hay, necesitan ajuste.

Active las herramientas de supervisión del rendimiento del servidor web en el servidor de ensayo. Ejecute una prueba de carga e inspeccione los parámetros relevantes, como el tiempo de respuesta, los bytes enviados y recibidos y el número de solicitudes y respuestas.

Los parámetros clave que querrá ajustar según el volumen de tráfico incluyen el almacenamiento en caché, el subproceso y la configuración de conexión.

Habilite el almacenamiento en caché para el contenido de uso frecuente; algunos servidores web le permiten almacenar archivos en caché de forma dinámica según el uso, mientras que otros exigen que especifique qué se almacenará en caché. Asegúrese de que su tamaño máximo de caché sea suficiente para el tráfico que espera. Y si su servidor web admite la aceleración de caché, habilítelo también.

Para la configuración de subprocesos y conexiones, establezca los mínimos y máximos de acuerdo con la carga de trabajo esperada. Para las conexiones, también deberá definir el número máximo de solicitudes por conexión y la configuración del tiempo de espera de la conexión. No establezca ninguno de estos valores demasiado pequeño o demasiado grande, o se pueden producir ralentizaciones.

No. 7: El infortunio de la WAN

¿Crees que necesitas recuperar el ancho de banda WAN? Puede gastar fácilmente un paquete en dispositivos de modelado de tráfico o motores de almacenamiento en caché en un intento de controlar la utilización del ancho de banda WAN. Pero, ¿y si no es la pipa?

Lo primero es lo primero: antes de comprar algo, tenga una idea sólida del tráfico que atraviesa la WAN. Las herramientas de análisis de red como Ethereal, ntop, Network Instrument's Observer o EtherPeek NX de WildPacket pueden brindarle una nueva visión de lo que realmente está en juego.

Puede encontrar que los tiempos de replicación para su Active Directory están configurados demasiado bajos y simplemente configurar intervalos de replicación más largos puede darle un respiro durante la jornada laboral. ¿Algunos usuarios de ubicaciones remotas asignan recursos compartidos a los servidores incorrectos y extraen archivos grandes a través de la WAN sin darse cuenta? ¿Siguen flotando los vestigios de una red IPX desactivada durante mucho tiempo? Algunos problemas de WAN se reducen a una mala configuración de la aplicación, donde el tráfico se dirige a través de la WAN cuando debería haber permanecido local. Los informes periódicos sobre los patrones de tráfico de la WAN le permitirán ahorrar dinero y dolores de cabeza.

No. 8: Juguemos bien

Con demasiada frecuencia, las aplicaciones, los servicios web y los sitios web de varios departamentos de la empresa compiten por los recursos del servidor. Aunque cada uno de estos componentes puede estar bien ajustado por derecho propio, una aplicación de otro departamento que también esté utilizando los mismos clústeres de producción puede tener una consulta mal ajustada o algún otro problema, que a su vez afecta a sus usuarios o clientes.

A corto plazo, todo lo que puede hacer es trabajar con los administradores de su sistema y el departamento que tiene el problema de rendimiento para obtener una solución para sus usuarios o clientes. A largo plazo, cree una comunidad en todos los departamentos que utilizan los clústeres de producción donde se implementan sus objetos. Trabaje entre equipos para asegurarse de que haya una financiación adecuada para un entorno de ensayo que sea verdaderamente representativo del entorno de producción de cargas de trabajo mixtas. En última instancia, querrá desarrollar una serie de puntos de referencia que se puedan usar para validar el rendimiento de cargas de trabajo mixtas en el entorno de ensayo.

No. 9: Almacenamiento en caché, modelado, limitación, ¡oh Dios!

Si su WAN es realmente de tamaño insuficiente, y no puede pagar una red de retransmisión de tramas de larga distancia, la configuración del tráfico y el almacenamiento en caché pueden ayudar a destapar la tubería.

Las configuraciones de modelado del tráfico son más un arte que una ciencia. Dar prioridad a las aplicaciones suele ser más político que técnico, pero puede tener efectos tremendos en el rendimiento percibido de la red.

El almacenamiento en caché es una bestia completamente diferente. Requiere menos trabajo que la configuración del tráfico, pero es probable que el impacto sea menor. Los motores de almacenamiento en caché almacenan y ofrecen copias locales de los datos a los que se accede habitualmente para reducir el tráfico WAN. La desventaja es que el contenido dinámico realmente no se puede almacenar en caché, por lo que el correo electrónico no disfrutará del mismo aumento de rendimiento.

No. 10: parcheo predictivo

Llega al trabajo el lunes solo para enterarse de que un montón de escritorios están bloqueados o que el rendimiento de una aplicación crítica se ha ralentizado. Después de investigar, determina que un parche que se aplicó durante el fin de semana es la causa.

Es por eso que necesita herramientas que admitan la reversión de parches. Aún mejor, incluya la prueba de parches como parte de su estrategia de administración de parches. Primero, debe hacer un inventario regular de las aplicaciones y tecnologías en juego en los equipos de escritorio y servidores. La mayoría de las herramientas de administración de sistemas, como el SMS de Microsoft, tienen la capacidad de realizar un inventario automáticamente.

A continuación, replique las aplicaciones y tecnologías en un entorno de ensayo. Si su sistema operativo y el software de infraestructura no incluyen herramientas de prueba de parches, obtenga una herramienta de terceros como FLEXnet AdminStudio o Wise Package Studio.

Alternativamente, puede escribir algunos scripts para ejercitar funcionalmente la plataforma o la tecnología con los últimos parches en juego. Deberá repetir este escenario (y ajustar los scripts) a medida que lleguen nuevos parches y se realicen cambios en el software.