Manual recomendaciones para preparar una campaña de visitas

#1

1. Introducción

En el siguiente artículo os explicamos los puntos relevantes a tener en cuenta para preparar tu web para soportar picos de tráfico asociados a campañas (#BlackFriday, #CyberMonday y similares).

El artículo tiene un enfoque metodológico ya que se centra en los puntos que se pueden mejorar externamente, pero también lo que debéis que revisar en vuestra web para que esté preparada.

2. Objetivos del manual

El presente manual cubre los siguientes elementos principales:

  1. Presentar los puntos concretos de análisis de la web que recibirá visitas
  2. Elementos a tener en cuenta antes de la campaña
  3. Análisis del consumo de la web tanto en recursos, cpu, memoria y base de datos
  4. Conclusiones con los datos anteriores para obtener el divisor de visitas.

Como decimos, el artículo tiene un enfoque sistemático para que los puntos sean revisados de principio a fin hasta llegar al final donde obtenemos el divisor de visitas.

2. Primera parte: elementos a tener en cuenta antes de la campaña

  1. ¿Qué es el divisor de visitas?

    Toda web, como sistema basado en consumo de recursos, tiene un límite. El divisor de visitas os dará ese número que os permitirá saber cuántos recursos necesitará la web, tal cual está, para atender una visita sin cambiar la arquitectura de la web.

    Este valor, que nosotros llamamos divisor de visitas (DV) :checkered_flag:, os permitirá saber cuánto trafico podrá soportar la web con los recursos actuales y cuánto necesitarás de más para soportar el tráfico adicional que necesitas.

  2. Datos antes de comenzar

    :loudspeaker: Antes de comenzar ningún análisis, es necesario:

    1. Una web que haya sido totalmente optimizada.

    2. Una web sin errores.

      • Comprobar los logs del servidor realizando una visita para descartar fallos:
        # no puede haber errores, ni warnings ni 404, 500, 503..
>> tail -f /var/webs/dominio.com/logs/*.log
      • Comprobar con una consola javascript (F12) que al cargar la web no hay errores.
      • Si hay errores parar! :stop_sign: La web no está preparada para hacer campañas.

    3. Determinar la URL que recibirá visitas o si será toda la web de manera general.

  3. Alcance de este manual y aclaraciones

    :no_entry: Es importante tener presente los siguientes puntos, de lo contrario, este manual carecerá de utilizadad y la campaña tendrá más posibilidades de fallar:

    1. Se parte de la base de que la web está totalmente optimizada. Si la web no ha recibido ningún tipo de optimización, no podrá recibir campañas.

    2. Se asume que la web está libre de errores. Si la web tiene errores, no podrá recibir campañas.

    Aunque este manual habla de los distintos aspectos de mejora, es importante tener presente que el objetivo del mismo es determinar el divisor de visitas (DV) :checkered_flag:.

    Es decir, el manual buscar ayudar a resolver el problema de recibir picos de tráfico para ventas. No busca ser un manual de optimización general ya que existe muchísima documentación y más específica para cada producto o CMS particular usado como motor de la web.

Segunda parte: Análisis de consumos actuales

  1. Análisis del número de recursos y ancho de banda usado por visita:

    Visitar la web con un explorador de Desarrollo Google Chrome (F12) en las URLs que recibirán tráfico. Apuntar número de peticiones, tiempo de carga y cantidad de tráfico descargado:

    image
    image.png717x321 39 KB

    Referencia:

    Número de recursos: De manera general, la web debe de estar por debajo de 100 recursos cargados. Mientras más recursos necesite, más se necesitará por un usuario y vuestro divisor de visita será mayor.

    Cantidad de descarga: De manera general, hay que intentar estar por debajo de los 2MB. Mientras más cantidad de tráfico haya, más tardará la visita, más consumo y mayor divisor de visita.

    Tiempo de carga: En este punto hay que intentar estar por debajo de los 3 segundos. Cualquier valor mayor hará que las visitas se solapen y se tarde más en atender volumen.

    NOTA IMPORTANTE: Cualquier pequeña desviación de consumo de ancho de banda y peticiones tendrá un efecto multiplicador negativo durante una campaña. Un exceso de tráfico de 500KB, significará generar 48GB de descarga adicionales por hora si se reciben 100.000 visitas (27 visitas al segundo).

  2. Análisis de consumo de memoria por visita (procesos PHP):

    Si tu backend servidor no es PHP no importa. Este punto pretende ver qué consumo PHP hace la web por visita. Si tienes un backend distinto, estas notas deberían ayudarte. No se pretende una medida exacta sino un valor aproximado de referencia.

    Ejecutar el siguiente comando (similar) para visualizar consumos procesos php:

    >> ps faux | grep php-fpm | grep usuario-de-la-web
reddom+ 32494  6.2  2.3 550676 170944 ?       S    11:47   1:59  \_ php-fpm: pool red.domain.org                                                                       
reddom+   644  7.0  2.5 638388 184804 ?       S    11:50   2:05  \_ php-fpm: pool red.domain.org                                                                       
reddom+   693  5.7  2.4 557532 177168 ?       R    11:50   1:41  \_ php-fpm: pool red.domain.org                                                                       
reddom+  2701  5.9  2.4 632384 176188 ?       S    11:53   1:32  \_ php-fpm: pool red.domain.org                                                                       
reddom+  4661  5.9  2.1 610188 154808 ?       S    11:59   1:12  \_ php-fpm: pool red.domain.org

    Ahora, realizar varias visitas con algunas pausas entre ellas y ver qué cantidad de procesos se lanzan y qué consumos hay. Apuntar las diferencias.

    Recomendación: para motores php-fpm, tomar el consumo individual de uno de los procesos y dividirlo por 3. Usar ese valor para dividir la memoria total del servidor para obtener consumo de memoria por usuario. Por ejemplo para un servidor con 6GB sería (realmente máquina de 7GB - 1GB destinado al procesado de la propia máquina):

    Explicación: Máximo memoria usable por el proyecto (6GB) / consumo memoria por visita
    PHP-FPM:
    Aproximación optimista: (6 * 1024) MB / (170/3) MB = 108 DMCM optimista (visitas máximas optimista)
    Aproximación conservadora: (6 * 1024) MB / (170/2) MB = 72 DMCM conservador (visitas máximas conservador)
    DMCM = (DMCM optimista + DMCM conservador) / 2
    ITK / LibApache2:
    DMCM = (total memoria del servidor o límite de procesos) / (total memoria procesos por visita)

    DMCM = Divisor máximo por consumo de memoria = Máximo visitas atendiendo sólo a la memoria

  3. Análisis de consumo de cpu por visita (Tipo de carga de cpu TCC):

    Siguiendo el punto anterior, usar la herramienta top y comprobar que al hacer visitas no se generan procesos con consumos elevados.

    Recomendación: si se detecta que la web genera procesos con gran consumo de CPU, la web no está preparada para la campaña. Añadir recursos tampoco lo resolverá ya que estamos hablando de mucho consumo de cpu con pocas visitas. El problema se multiplicará con exceso de visitas.

    Recomendación: El objetivo es comprobar que no haya consumos muy elevados al producirse visitas (por encima de 60% de cpu).

    Apuntar tipo de carga cpu (TCC): cuando se recibe visita, consumo de cpu: bajo (menos del 30%), medio (entre el 30% y el 40%), moderado (entre el 40% y el 50%), alta (entre el 50% y el 60%) y muy alto (por encima del 60%).

  4. Análisis de consultas MySQL/MariaDB:

    Analizar la carga que genera la web al recibir visitas en el servidor de base de datos. Usar la herramienta MySQL Manager de core-admin para visualizar las consultas al recibir visitas:

    Cómo visualizar las consultas MySQL que se están ejecutando en mi servidor con Core-Admin

  5. Revisar que la web tenga motor de caché bajo demanda

    Existen muchos productos de caché Web (TotalCache, WpRocket).

    Hay que evitar todos aquellos que hagan cacheo preventivo de toda la web. Es un trabajo que restará potencia a la web y que cacheará webs que posiblemente no sean consultadas. Esto es más importante para webs con muchos artículos.

    Wp-Rocket es un ejemplo de plugin de caché preventiva: hay que evitarlo.

    Recomendamos TotalCache y similares ya que cachean bajo demanda. Esto es importante porque la caché que se genera solo lo hace para las webs visitadas. Esto aplica cierta validación: sólo se cachea lo que tiene interés. Artículos y páginas antiguas que no reciben visitas no generan caché ni consumo para generarlas ni mantenerlas.

    Wp-Rocket, aunque tenga buena prensa, es un componente de caché que genera una totalización mediante el rastreo de todas las urls que genera la web, que tiene muchos inconvenientes con respecto a la estrategia que realiza plugins como Total Cache que generan caché bajo demanda.

    Recomendación: revisar que no se usa WpRocket ni plugins que generan caché con visitas contra sí mismo. Para ello, revisar la web para buscar accesos desde la misma IP del servidor:

    # Si se ven accesos desde el propio servidor, analizarlos para ver 
# si es la cache o mecanismo similar
>> grep `hostname -i` /var/webs/dominio.com/logs/access.log

  6. Optimizar base de datos asociada a la web y programar optimización:

    Usar la herramienta de core-admin para optimizar la base de datos asociada a la web. Programar la optimización para que se haga todos los días entre las 03:00 y las 07:00 de la mañana. Evitar poner todo a la misma hora:

    Optimización de bases de datos MySQL usando el Gestor de MySQL de Core-Admin -- Automatización

    En el caso de webs con Prestashop revisar el siguiente artículo para automatizar el limpiado de tablas que se llenan y que causan pérdida de rendimiento:

    Limpiado automatizado de tablas Prestashop para mejorar rendimiento con Core-Admin

  7. Revisar para evitar incluir plugins de seguridad:

    Confirmar que Core-Admin ya proporciona mecanismos de protección que son superiores a los que pueda proporcionar un plugin. El motivo es que Core-Admin ejecuta a nivel de servidor, con permisos administrativos, y con un mayor control de más partes del sistema, mientras que el plugin necesita a la propia web que pretende proteger.

    Hay más información extensa sobre estos puntos en:

    Recomendación: desinstalar plugins como Securi, Wordfence y similares. No proporcionan una protección adicional a lo que ya proporciona Core-Admin y ralentizarán la web.

    Recuerde, cualquier variación en consumos de tiempo, memoria y cpu, se multiplicará durante la campaña.

  8. Evitar programadores y cualquier componente de llamada a si mismo

    Varios motores como Wordpress incluyen mecanismos de cron para ejecutar tareas programadas. El problema es que dichos mecanismos se revisan y se activan justo cuando se recibe la visita, generando un consumo adicional que debería estar destinado a atender al visitante.

    Tiene más información explicando esta problemática aquí:

    Deshabilitar WP-Cron del wordpress

    Recomendación: desactivar el cron del wordpress. Si es necesario, programar tarea con URL específica en el momento más adecuado al contexto de usuarios de la web.

  9. Revisar llamadas 404 NOT FOUND

    Los motores CMS como Wordpress, Prestashop y similares sufren mucho problema de rendimiento cuando reciben visitas para URLs que no existen y que generan 404 NOT FOUND.

    El motivo es que cuando algo no existe, por configuración .htaccess, el tráfico es inyectado en el motor del CMS. Esto a su vez provoca una búsqueda generalizada por parte del motor CMS para intentar resolver dicha url, para finalmente desembocar en un 404 NOT FOUND.

    Lo que para una web sin URL de este modo se gestiona de manera rápida y estática, para motores CMS como el Wordpress, y similares, genera mucha sobrecarga al intentar resolver URLs que no existen.

    Recomendación: revisar que la web no tenga accesos 404. Si los tiene, revisar para que no se produzcan creando la página correspondiente, bloqueado con .htaccess o similar. No instalar plugin para resolver este tema. Lo empeorará.

    >> grep ' 404 ' /var/webs/dominio.com/logs/access.log
# No se deberían ver accesos

  10. Quitar todo plugin, módulo o código que no sea extríctamente necesario

    Es fundamental destinar todos los recursos al proceso principal de la web (sea la venta, generación de leads).

    Para ello, hay que borrar totalmente cualquier código o plugin que no vaya ser usado.

    No vale con desactivar el plugin para el caso de Wordpress, Prestashop y similares. Se seguirán procesando mínimamente, causando gasto adicional no necesario.

    Recomendación: mientras menos líneas de código tenga la web, menos será necesario procesador por el motor del lenguaje para comenzar a trabajar.

    Recomendación: intentar tener una web por debajo de las 300.000 líneas de código .php. Usar el siguiente comando para contabilizar:

    >> cd /root/
>> find /var/webs/dominio.com/html/ -name '*.php' -print0 > listado.txt
>> wc -l --files0-from=listado.txt | grep total$
525786 total <== líneas de código

    También se puede usar el siguiente comando para obtener un valor por carpeta:

    # entramos en la carpeta raiz del proyecto 
>> cd /var/webs/dominio.com/html
# iteramos carpeta a carpeta o obtenemos total individual
>> for I in `find ./ -maxdepth 1 -mindepth 1 -type d `; do echo "$I: "; find $I -name '*.php' -print0 > listado.txt;  wc -l --files0-from=listado.txt | grep total$; done

  11. Instalar motores de PHP modernos y con OpCache:

    Con cada versión nueva de PHP se ha notado una mejora en el rendimiento. Se recomienda configurar el alojamiento para usar motor PHP 7.4.

    También se recomienda activar el motor de caché PHP opCache. Core-Admin lo activa por defecto.

    Recomendación: Activar la versión PHP más moderna junto con el OpCache.

  12. El servidor debe estar tranquilo en condiciones normales:

    La programación que tiene la web, las consultas que genera y la carga de la base de datos debe ser tal que en condiciones de visitas normales, debe hacer que el servidor esté al 40% de su carga media, no excederse del 50% y nunca sobrepasar el 60%.

    Si el servidor está sobrecargado o por encima de estos valores, cuando reciba visitas, la carga se multiplicará.

    Apuntar incrementos del Factor de solape (FS) en función de si está tranquilo el servidor: +0 (por debajo de 40%, +1 (entre 40% y el 60%), +2 (por encima del 60%). Estos incrementos se añadirán en el cálculo posterior.

Tercera parte: Conclusiones con los datos anteriores para obtener el divisor de visitas.

Todos los puntos mencionados en este artículo han de ser revisados y corregidos antes de continuar.

Una vez resueltos, se habrá obtenido la mejor optimización posible hasta el momento. Con ese estado, usar los siguientes indicadores para estimar cargas para motores PHP-FPM:

  1. Divisor máximo por consumo cpu (DMCC). Determinar grado de consumo de cpu de la aplicación. Este consumo debe incluir el consumo de motores de base de datos (MySQL/MariaDB) y motores PHP-FPM:

    Tipo de carga de cpu (TCC) visitas por cpu factor de solape
    Muy alto 4 5
    Alto 9 4
    Moderado 15 3
    Medio 35 2
    Bajo 45 1

    Multiplicar por número de cpus para obtener divisor máximo por consumo de cpu (DMCC) y el Factor de solape (FS).

    Ejemplos:

    Consumo bajo de cpu por visita (45) x cpus (3) = 135/1 DMCC / FS
    Consumo alto de cpu por visita (9) x cpus (3) = 27/4 DMCC / FS

    DMCC = Divisor máximo por consumo de cpu
    FS = Factor de solape

  2. Divisor máximo por consumo de memoria (DMCM):

    Usar el valor obtenido del análisis de memoria de los puntos anteriores (consumo de memoria por visita optimista/conservador). El valor será la medida entre la estimación optimista y la conservadora. En este artículo se usan como ejemplo el valor 72 para conservadora y 108 para optimista.

    Por tanto el tope máximo de visitas limitadas por la memoria será: (optimista + conservadora) / 2
    En este caso: (108 + 72) / 2 = 90 DMCM (visitas máximas atendiendo al límite de memoria)

    DMCM = Divisor máximo por consumo memoria = Máximo de visitas que se podrían recibir midiendo sólo por memoria disponible para el proyecto

Cuarta parte. Informe de conclusiones

Calculo de visitas soportadas:

  1. Con los datos anteriores podemos concluir cuál es el máximo de visitas concurrentes que podrá recibir el servidor con la programación actual de la web. Este es el divisor de visitas de la web.

  2. Divisor de visitas de la web = MIN (DMCC, DMCM) / FS

Usando el ejemplo de este artículo, tenemos que nuestro divisor de visitas es:

  1. DV (Divisor de visitas) = MIN (90, 135)/1 = 90 (para una web con consumo bajo de cpu)
  2. DV (Divisor de visitas) = MIN (90, 27)/4 = 9 (para una web con consumo alto de cpu)

Conclusiones para una web con los datos de alta carga de cpu (con un divisor de visitas 27):

  • Máximo de visitas concurrentes (al mismo tiempo) por segundo: DV
  • Hasta DV usuarios concurrentes/segundo (y DV * 360 visitas cada 5 minutos): sin cambios de alojamiento y sin carga en la máquina (de otras webs)
  • Hasta DV usuarios concurrentes/segundo (y DV * 3600 visitas a la hora): sin cambios de alojamiento y sin carga en la máquina (de otras webs)

Ejemplos:

  • Máximo de visitas concurrentes (al mismo tiempo) por segundo: 9
  • Hasta 9 usuarios concurrentes/segundo (y 32400 visitas a la hora): sin cambios de alojamiento y sin carga en la máquina (de otras webs)