¿Qué pasa cuando un proyecto WordPress comienza a ir lento o se satura? Ya sea una escuela, un eCommerce o cualquier proyecto con transacciones. Hoy veremos cómo escalarlo.
Patrocinador
Cuando hablamos de negocios y de proyectos un poco grandes, es posible que quieras dar un paso más en tu alojamiento y pasar a tener servidores garantizados para ti. en este caso tienes el hosting Cloud de SiteGround.
Enlaces comentados
- Joan ha presentado un Curso de Community Manager.
- Javier nos explicará hoy en el tema del día uno de los proyectos en los que ha estado trabajando con un cliente.
Actualidad
- WordPress 5.8, parece que en julio 2021 (con o sin FSE)
- FSE Program Build a Homepage Testing Summary
Tema del Día
Escuela de formación con 3.000 alumnos simultáneos, por Javier Casares
Hace unas semanas os conté que había estado trabajando en un proyecto de escalabilidad con WordPress y hoy me gustaría explicar un poco más los intríngulis de cómo un cliente ha podido pasar de tener un montón de problemas a que todo vaya mucho más fluido sin aumentar mucho el coste, simplemente haciendo las cosas ordenadas.
Para poner en situación, este cliente es una agencia que tiene sus clientes a los que les prepara un WordPress con un sistema de formación, de eventos concentrados puntualmente un día a una hora. Esto hace que se WordPress se tenga que tragar entre 1.000 y 3.000 alumnos a la vez para ver un vídeo en directo. Estos usuarios están previamente registrados, y para acceder a esos vídeos han de loguearse en la web para poder seguir el vídeo.
En un primer momento a este cliente se le montaba una máquina con un cPanel que controlaba los sitios, el correo, las DNS y las webs. Las webs, obviamente hablamos de sus 3 elementos: el WordPress con su PHP, la base de datos y los certificados TLS para el HTTPS. Luego entenderéis porqué desgrano todo esto con tanto detalle.
El problema básicamente es que aunque le daban mucha gasolina a la máquina, un servidor con hasta 16 CPU y 32 GB de RAM, la cosa no tiraba, porque el problema no es que la web vaya mejor o peor, el problema es que todo el sistema es un monolito… y no olvidéis lo que voy a decir ahora:
Internet se creó para ser un sistema distribuido de servicios controlados por ficheros de texto.
El primer paso que tuve que hacer fue un poco lo que la agencia me pidió: montar distintas máquinas con sus paneles correspondientes pero distribuyendo las webs en cada máquina. Esto tiene sus pros y sus contras, y es que aunque las webs estén separados, seguimos trabajando en sistemas monolíticos. Los primeros problemas los encontramos en la parte de las DNS, ya que al no estar centralizadas, los paneles no saben trabajar si no las tienen 100% controladas… así que eso requería algún trabajo manual que ya complica la vida a los clientes.
Lo segundo es que, aunque todo va mejor, dejar a un panel de control del tipo cPanel para un proyecto grande te limita en cuanto a las configuraciones. Un panel de éstos está pensado para que cualquiera entre en el panel y haga los cambios que necesita sin tener conocimientos técnicos… pero ¿qué pasa cuando la web se satura, deja de funcionar y en general no funciona nada? Pues que ningún panel ni nada te acaba de servir. Y aquí es donde entra la distribución de los servicios de Internet.
Visto lo visto, el planteamiento en esta segunda fase fue completamente distinta. En vez de decirle al cliente qué quería que hiciera, fui yo el que le propuso qué sería lo mejor a la hora de plantear el sistema.
Si empezamos por la parte más baja, los dominios están en donde los clientes los registren… en ese sentido no hay muchos cambios.
Lo siguiente fue crear una máquina central que es la que se utiliza para la gestión de sólo 2 elementos: las DNS y las cuentas de correo básicas. No son cuentas de correo corporativas por norma general, sino algunas cuentas necesarias para validar el dominio y otros servicios. Incluso, a veces son simples redirecciones.
La parte de envíos de correo tiene un servicio externo. Es decir, los correos de los WordPress no se mandarán desde la propia máquina (como normalmente pasa) sino que se utiliza un servicio externo de SMTP. Esto significa que con un plugin de los que te permiten configurar el correo SMTP externo, y los datos, es más que suficiente.
El hecho de dejar todo esto fuera y separado tiene un único objetivo: la web en sí, el WordPress, estará completamente separado del resto de servicios que pueden generar ruido.
Así que nos quedan los WordPress… ¿cómo se han montado? Pues básicamente la agencia ha separado a cada uno de los clientes en un concepto de cluster. Esto se ha pensado así para que una o varias webs puedan estar en un conjunto de servidores, sobre todo pensando que puede haber un cliente que haga 2 formaciones a la vez… y eso puede suponer un problema, ya que no tendríamos 3.000 usuarios concurrentes, sino 6.000, y si una plataforma falla, la otra también. Así que cada uno de estos clusters se ha pensado para dar una formación a la vez en un día y hora concreta.
Y ¿cómo se ha montado cada cluster? Pues cada uno tiene 3 máquinas por defecto. Una de ellas se va a utilizar como «máquina web» y las otras dos se van a utilizar como máquinas de base de datos, concretamente una de ellas hará de master y la otra de slave.
Comienzo por las bases de datos. La idea es que sean dos máquinas iguales a nivel de configuración. La idea es que en el momento de la formación tengan 2 CPU y 4 GB de RAM, con el disco que necesiten para que quepa toda la información bien.
La máquina principal, la del master, se configura de forma norma, como cualquier servidor con MySQL o MariaDB. En este caso las montamos con MariaDB porque sí. Una vez montada esta máquina se configura la otra máquina igual, y al final se le dice a una que es la master y la otra la slave.
Esto significa que en la base de datos master se puede leer y escribir, y en la slave sólo se puede leer, y entre ellas se sincronizan. Por ejemplo, si añades una página en WordPress, se guarda en la master, e inmediatamente se genera una copia en la slave. Lo bueno de esto es que los datos de la slave se leen muy rápido (ya que el sistema se autoconfigura para que leer sea muy rápido) y a la vez separamos el coste tecnológico, porque añadir o modificar un contenido es mucho más lento y costoso que leer… de forma que el consumo de cada máquina se separa… y así una se encarga de hacer lo que menos se hace, la master, que es guardar datos, y la otra se encarga de hacer lo que más se hace que es leer datos, y lo hace mucho más rápido. Con esto nos aseguramos que la parte de base de datos no se satura.
La otra máquina, la máquina web, es la que va a tener las siguientes cosas: el WordPress en sí, el servidor web, que en este caso es nginx y no Apache, tendrá el PHP (una o varias versiones configurables), además le pondremos un Redis que es una capa de caché y es la que gestionará los crones.
Cuando se monta la máquina se configura primero el nginx para que sea óptimo, que tenga configurada mínimamente la propia caché interna y las cuatro cosas básicas del servidor web.
Lo siguiente es más complejo, que es el PHP. En este caso se configuran 2 cosas importantes: por un lado el PHP Opcaché, que es una caché interna del código de WordPress (es como si se cachease el código fuente de PHP, lo que hace que, mientras no haya una versión nueva, funcione de forma precalculada) y por otro lado configuramos el PHP-FPM específicamente para unas CPU y RAM concretas, reservando memoria y otras cosas. En este caso se ha configurado para una máquina con 8 CPU y 16 GB de RAM; reservando parte de la memoria sólo y exclusivamente para el PHP.
Y por último configuramos el Redis. Redis es un sistema de caché que sobre todo almacena los resultados de la base de datos. Esto significa que si ejecutas 10 veces la misma consulta a la base de datos (por ejemplo, cuando entras en la página principal y siempre muestras los mismos contenidos) pues esos resultados se almacenan en Rdis y así no hay que llamar a la base de datos, que es mucho más lento. Con esto ganas mucha velocidad.
Digamos que hasta aquí tenemos esas 3 máquinas, con un futuro WordPress, pero que hemos de configurar un poco, porque esta no es la configuración habitual.
Lo primero que haremos es configurar el HTTPS y todo para que la web única y exclusivamente funcione por HTTPS y no haya esos mensajes de error de que el sitio es inseguro.
Por otro lado, configuramos el nginx para dar capas de seguridad al WordPress. De esta forma el propio servidor bloqueará determinados ataques o sobresaturación.
Lo siguiente es la configuración de los crones. Como ya expliqué hace unos programas, hay que evitar que el WordPress controle los crones y por eso los lanzaremos cuando nosotros decidamos. Y esto se hace usando WP-CLI. Aunque lo lancemos cada minuto, nos aseguramos que sólos e ejecuta una única vez y cuando nosotros queramos. Incluso, si detectamos que los crones se saturan, podemos decidir que en vez de cada minuto se ejecuten cada 2 o cada 5, por lo que todo se verá más calmado.
Y ahora llega lo más raro, y un poco complicado, que es configurar que WordPress sea capaz de hacer llamadas a dos bases de datos distintas, según sea una lectura o una escritura. Para esto en vez de usar HyperDB, que es el sistema que usa Automattic en WordPress.com, usaremos Ludicrous. Este sistema lo que permite es decirle a WordPress que hay una o varias bases de datos master, donde poder escribir y otras en las que sólo se pueda leer, los slave.
Una vez el WordPress esté montado podemos añadir algunos plugins que mejoren el control de todo. Algunos de ellos son:
- Autoptimize, que permite comprimir y controlar los JavaScript y CSS, de forma que sea mucho más simple controlarlos y cachearlos.
- Health Check & Troubleshooting, que es una ampliación del «Salud del Sitio» y que nos da información de que todo está funcionando correctamente.
- HTTP/2 Server Push, que permite enviar en modo PUSH, y aprovechando el HTTP2 para que los CSS y JavaScript se carguen más rápido y en paralelo.
- Redis Object Cache, que como el nombre indica, activa el uso de la caché de Redis, además tiene unas pequeñas estadísticas que te dejan ver si necesitas más o menos caché.
- WP Super Cache, que será el plugin de caché de página que vamos a usar. Como usamos nginx hay que hacer unas configuraciones especiales para que se lean primero los ficheros cacheados.
- y WP OPcache, que también, como el nombre indica, permite controlar la caché de PHP del OpCaché y que también tiene algunas estadísticas que te ayudan a ver y a configurar esta caché.
Se pueden hacer algunas cosas más, muy relacionadas con las caché de los estáticos, de forma que, en vez de usar una CDN se utilice el propio servidor como sistema de cachés de imágenes y demás, pero en este caso todavía no hemos llegado ahí, aunque ya llegaremos, porque ayer conseguimos un récord de usuarios concurrentes que hasta ahora no habían podido tener…
Sé que esto es bastante complejo, pero es sólo una idea de qué cosas se pueden hacer sobre todo con aquellos que tengan tiendas, o sitios en los que hay mucho trabajo de la base de datos, usuarios que no se puedan cachear y cosas así… así que, si tienes un proyecto en el que el funcionamiento de la web es clave, no dudes en hablar con algún administrador de sistemas que sepa de WordPress, porque, por un precio razonable, puede hacer que se solucionen tus problemas.
Y, un consejo a los Administradores… recordad que sois vosotros los que sabéis cómo se monta esto, así que no os dejéis marear mucho por los clientes, haced lo que sabéis que funciona, hacer que WordPress se adapte a los sistemas y no al revés.
Despedida
Recordad que nos podéis dejar y votar en la página de ideas posibles temas de los que queréis que hablemos en el podcast.
Ya sabéis que podéis encontrar a Joan Boluda donde tenéis sus cursos de WordPress, y a Javier Casares con todos sus proyectos.
Ya sabéis que estáis más que invitados a participar a través de la sección de contacto de la web, a través de la que podéis enviar preguntas, dudas, y sugerencias para nuevos episodios.
Y recuerda que puedes suscribirte y escucharnos cada semana en Apple Podcasts, Spotify, Google Podcasts e iVoox.
¡Nos vemos el programa que viene con más WordPress!