Los “n” mandamientos para el óptimo rendimiento de una aplicación web.

En un ambiente web comercial, en donde el rendimiento de una aplicación orientada al servicio es indispensable para mantener la imagen de una marca, compañía o la fiabilidad del servicio mismo, es importante tener bien claro, que la misión de una equipo de desarrollo de TI, es proveer una capacidad de procesamiento de información que verdaderamente beneficie al negocio, al asegurar la calidad y el rendimiento del procesamiento de la información a pequeña y gran escala.

¿Por qué es importante el rendimiento, su monitoreo, y las pruebas de carga  (load-testing) de una aplicación web?

Bien, una razón principal, es evitar el índice de sesiones abandonadas debido a tiempos de carga excesivamente lentos,cuellos de botella, down-time de la aplicación, o errores prevenibles, que se traducen directamente en pérdidas y mala imagen.Y lamentablemente, el último responsable  para el usuario no será el arquitecto o desarrollador de la aplicación, sino la empresa misma que da la cara.

Excesiva carga colgará una aplicación, no importa la plataforma, los miles de dólares gastados en  hardware o la tecnología implementada, mientras la aplicación no sepa hacer uso correcto de los recursos de hardware dedicados a esta, o simplemente exista un mal diseño estructural de la misma.

Métricas y tipos de pruebas.

A continuación presento las métricas y pruebas más comunes a considerar para mantener una aplicación a raya:

  • Rendimiento/Load-testing – Se trata de confirmar que la aplicación responderá en tiempos razonables durante la carga de tráfico.
  • Pruebas de estrés- Identificar las áreas en donde la aplicación podría fallar en primera instancia.
  • Pruebas de fiabilidad- Verificar si la aplicación puede operar bajo largos periodos de carga de tráfico.
  • Pruebas de volumen. Confirmar si la aplicación soporta ciertas cantidades de datos concurrentes introducidos.

Existen diversas herramientas en el mercado, que ofrecen servicios a estos niveles como Apache JMeter, y  iGATE (www.igate.com).

La carga y la concurrencia.

Un factor a considerar muy importante, es la carga. La carga es el volumen de datos y conexiones concurrentes en un sistema. En los ambientes eCommerce, el significado de carga no es el mismo que en una aplicación convencional, puesto que consume mucho más recursos. El proceso de compra, catalogo, clientes, etc, consumirá  mucho más recursos en cuestión de objetos en la memoria y carga a la base de datos .Entonces, para hacer un estimado del  hardware necesario al que la aplicación deberá tener acceso, no basta solo con calcular la carga de tráfico, sino la memoria y tiempo de procesamiento que consumirá cada petición HTTP . Considerando también, que no todos los usuarios consumen la misma cantidad de memoria, al existir diferentes tipos de acciones, objetos y consultas a la BD que afectan directamente el consumo de memoria. Entonces, un estimado simple y a grandes rasgos, solo para la memoria del servidor,  deberá ser basado en lo siguiente:

Conexiones concurrentes/min  X consumo de memoria promedio por petición HTTP, eso le dará una idea de cuánta memoria se necesita para atender X peticiones , pensando que la conexión durará un minuto en promedio. Otro factor a considerar es cuál es el rendimiento deseado bajo esa carga, si óptimo, o razonable, multiplicar por 2 el resultado generalmente es garantía que con ese tráfico el rendimiento sería óptimo.

A continuación un ejemplo de que cómo opera una aplicación (Magento) con y sin caché. El resultado es evidente.

Factores y tecnologías a considerar

  • Disponibilidad de la aplicación y tiempo en línea deseado
  • Implementación Load Balancers
  • Más de un servidor de aplicación.
  • Servidor de base de datos redundante: Master-Slave
  • Sistemas de caché:
  •        Caché de contenido estático (varnish)
  •        Caché distribuida en memoria de objetos (apc, memcache)
  •        Caché de consultas a la BD para alivianar la carga .(redis)
  • Conexiones concurrentes esperadas
  • Tamaño en Kb de  memoria que la aplicación consume a por conexión HTTP
  • Tiempo de carga de la aplicación deseado
  • Hardware disponible :
  •        Memoria
  •        Procesador
  •        Ancho de banda
  •        Disponibilidad de un CDN (Content Delivery Network)
  •        Load Balancer
  •        Múltiples instancias de servidores web y BD. (cluster)
  • Optimización de los recursos del servidor:
  •        Métodos de compresión de contenido
  •        Headers de expiración para diferente tipo contenido
  •        Compresión de recursos CSS y JS
  •        Leverage browser caching.
  • Calidad de código.

Hacer pruebas unitarias o pruebas de rendimiento del código es fundamental para un buen rendimiento independientemente de la infraestructura, un código mal estructurado es la principal causa dolorosos cuellos de botella, colgando la aplicación y  echando  a perder cualquier infraestructura que halla usted implementado. Por eso es importante hacer pruebas rigurosas del código en tiempo de ejecución para evitar este tipo de problemas. El arquitecto de software, el CTO, o CIO, deberán ser responsables del monitoreo del desarrollo durante la implementación al aplicar rigurosas métricas y estándares de calidad de código.

Caso de uso:

Suponga una aplicación robusta, consumidora de muchos recursos, sumamente concurrida, y con 99% de tiempo en línea esperado, de alta disponibilidad.

  • El código pasó por sus debidas pruebas de estrés buenas prácticas.

  • Estime el tráfico esperado concurrente.

  • Calcule cuánta memoria consumirá la aplicación por cada conexión.

  • Obtenga la memoria.

  • Provea suficientes procesadores proporcionales a la memoria implementada.

  • Asegure su ancho de banda

  • Configure su infraestructura a manera de cluster, todo bajo un load balancer que decide cómo enrutar el tráfico a los diferentes servidores de aplicación .

  • Configure un esquema replicado Master-Salve para la BD administrado por un sistema como Redis que actúa también como cache de queries, para alivianar el uso de la BD, y acelerar los “reads” en un 500%. (Siempre es más rápido leer de la memoria que del disco duro)

  • Implemente un sistema de caché  distribuida en memoria de objetos (apc, memcache)

  • Implemente un sistema de caché de contenido estático como varnish.

  • En casos como PHP, precompile su código.

  • Comprima el contenido gráfico, scripts y hojas de estilo.

  • Utilice un CDN externo para el contenido gráfico.

  • Evite demasiados scripts externos.

  • Haga pruebas en el ambiente pre-productivo simulando actividad del usuario automatizados.

  • Genere scripts que simulen cantidades masivas de datos. (Apache JMeter)

  • Identifique los puntos de quiebre de la aplicación.

  • Defina una estrategia de failover.

  • Defina una estrategia de monitoreo.

Aqui un diagrama  como referencia de un esquema de BD replicado


Con load balancer:

Costo-beneficio

Según los requerimientos de rendimiento, entre más disponibilidad y fiabilidad requiera, bajo alta concurrencia, el costo se elevará proporcionalmente en términos de hardware, pero el beneficio a largo plazo será siempre una pieza de ingeniería que agregará un valor real a su negocio asegurando la imagen y el prestigio de su empresa y su equipo mismo de TI.

Sobre el autor: José Manuel Castañeda trabaja actualmente como Director de TI en PengoStores, líderes en comercio electrónico en México, su participación es activa en el mundo de las tecnologías aplicadas al comercio electrónico, y esta certificado actualmente por la Empresa Magento como “Magento Certified Developer Plus” desde 2013.

This entry was posted in Ecommerce, Magento, Pengo Stores and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>