Hosting para mucho tráfico - WordPress y el consumo de recursos

En Raiola Networks estamos acostumbrados a un tipo de cliente bastante especial, aunque tenemos clientes de todos los tipos y sectores posibles.

Desde el principio nos hemos especializado en clientes con webs creadas en WordPress y alta carga o volumen de visitas, llegando incluso a necesitar varios servidores dedicados para soportar el tráfico en momentos puntuales.

Por eso creamos los servidores VPS optimizados, un producto que siempre ha tenido muy buena acogida entre nuestros clientes y que ha dado muy buenos resultados. De hecho, yo personalmente he llegado a soportar picos de tráfico de 3500 visitas concurrentes (a la vez) con un servidor VPS 3 de 4 GB de RAM y 4 núcleos de CPU. Evidentemente, el WordPress estaba correctamente optimizado.

Aunque la optimización del CMS (en este caso WordPress) influye mucho, la elección de componentes y configuración del stack web instalado en el servidor también influye bastante.

Este es un ejemplo de un pico de tráfico que tuvo uno de mis clientes hace tiempo.

Mientras que a nivel ancho de banda y tráfico de red se notó MUCHO:



A nivel CPU y RAM ni se inmutó:





El peso de página rondaba los 1,5 – 2,0 MB por cada hit provocado por un cliente (sin tener en cuenta el cache de navegador).

Gracias al trabajo del cache de página del proxy inverso Nginx, el servidor es capaz de servir más de 600 Mbps sin que los recursos de CPU y RAM sufran.
Aunque en este caso no hemos monitorizado el I/O, posiblemente los discos SSD también fueran un elemento clave para evitar retrasos al servir el cache.

En este caso no se usó ningún CDN para servir estáticos, por lo que el servidor ha tenido que absorber todo el tráfico.

Los recursos en hosting, lo ilimitado no existe

Pues como dice el título, lo ilimitado no existe por mucho que algunos proveedores utilicen esto para su publicidad.
Si algo pone que es ilimitado, puede ser por dos razones:

• Porque hay algo en los contratos que “controla” esto y no permite que ningún cliente abuse.


• Porque una métrica ilimitada, posiblemente no pueda llegar a aprovecharse por el factor limitante de otra métrica relacionada.

El hosting ilimitado no existe ni nunca ha existido ni va a existir. Una de las razones de esto es precisamente que los procesadores ilimitados no existen, la RAM ilimitada no existe, los discos duros ilimitados no existen, etc.

En Raiola Networks en lugar de “ilimitado”, si una métrica suele estar limitada por otra métrica, solemos usar el concepto “No medido”, ya que no queremos asociar nuestros productos a la tendencia del “ilimitado”.

Cuando nosotros cargamos una web y esta web está creada con un lenguaje que se interpreta del lado del servidor (como PHP), para generar el HTML que interpreta el navegador del visitante tienen que ejecutarse unos procesos.



Para ejecutar estos procesos se usa el procesador y la memoria RAM del servidor, que al fin y al cabo es como un ordenador.

Y vuelvo a repetir, que no existen las RAM y CPU (procesador) ilimitados. También comentar que en los planes de hosting compartido tienen unos recursos de CPU y RAM limitados: nadie te alquila un servidor dedicado entero con una CPU Intel Xeon y 64 GB de RAM por 6 euros al mes.

Benchmarks de rendimiento de hosting

Para que veas la diferencia de rendimiento entre un plan de hosting pequeño y uno grande, te dejo esta imagen:



Como ves, el rendimiento no es proporcional a los recursos, salvo… que tengamos un volumen alto de visitas en nuestra web, ya que entonces sí que la cosa cambia.

En esta prueba de impacto lanzamos 25 visitantes concurrentes a un WordPress que está por defecto y sin cache.

En el hosting con 1 GB de RAM y 50% de 1 CPU los tiempos de respuesta medios está en 0,73 segundos:



Mientras que, en el caso del hosting con 4 GB de RAM y 4 CPU, el tiempo de respuesta con las 25 visitas concurrentes es mucho mejor (0,08 segundos):



Esto demuestra que cuantos más recursos no solo podremos procesar más, sino que también mantendremos los tiempos de respuesta mucho más bajos.

Ahora vamos a plantear 50 visitas concurrentes en lugar de 25, lo que buscamos es que empiece a dar errores, ya que el plan de hosting pequeño tiene límite de procesos PHP abiertos.

En el plan de hosting con 1 GB de RAM y 50% de 1 CPU conseguimos un tiempo de respuesta medio de 0,73 segundos y un tiempo máximo de 5,55 segundos con las 50 visitas concurrentes:



Además, que… también tenemos algunos errores debido a que se ha alcanzando repetidas veces el límite de recursos del hosting:



Mientras que en el plan de hosting con 4 GB de RAM y 4 CPU conseguimos unos tiempos de respuesta mucho mejores y ningún error.



Estos test de cargan han sido realizados con la herramienta Loadster.

CPU o procesador

Lo pongo el primero porque para mí es uno de los recursos más importantes, ya que no solo va a definir la “capacidad”, sino también la “velocidad”.

Evidentemente, cuanta más potencia de CPU, más rápido se ejecutarán las tareas y más tareas podremos ejecutar al mismo tiempo.

En una situación teórica donde no se haga nada de cache de página, cada visita se procesa en la CPU o procesador y dependiendo de la potencia de este, vamos a poder servir más visitas más rápido o menos visitas más lento.

En hosting compartido nadie habla de este recurso o límite, pero existe siempre.

Memoria RAM

La memoria RAM es otra parte importante, ya no solo porque ahí se almacenan cosas que se van a procesar, sino que también se utiliza como cache en el caso del OPCache de PHP y en algunos casos también para guardar cache de objetos.

En la RAM no solo influye la cantidad, sino también la velocidad de esta. No es igual de rápida la memoria RAM DDR3 que la DDR4 a la hora de mover datos.

Este es otro recurso que no se suele mencionar en hosting compartido, pero también existe.

Cuando en WordPress trabajamos con plugins complejos como WooCommerce, LearnDash o incluso cuando trabajamos con Elementor Pro y algún plugin complejo de Crocoblock trabajando con muchos datos, podemos requerir hasta 1 GB de memoria RAM por proceso o recibiremos unos cuantos errores 500.

Si tenemos una web social, normalmente no podemos usar mucho el cache de página, y esto quiere decir que tendremos que procesar constantemente datos y hacer consultas a la base de datos. En estos casos la RAM es imprescindible, de hecho, cuanta más RAM más visitas podremos servir al mismo tiempo.

I/O de disco

El I/O de disco es la capacidad de leer y escribir en el disco duro, una limitación que existe en TODOS los discos duros y que está limitada por software en los hosting compartidos.

El I/O (Input/Output) es el “caudal” que podremos usar para leer y escribir, evidentemente en los discos SSD SATA y SSD NVME conseguimos mucho más ancho de banda al leer y escribir, además de que estas operaciones serán mucho más rápidas.

Aquí es donde entra otra característica, los IOPS, que son las operaciones máximas por segundo de lectora y escritura que podemos hacer en disco. Como en el caso del I/O, en los hostings compartidos se limita esto ya que se reparte entre todos los clientes alojados en el servidor.

Otras limitaciones variables

Te falta algo, ¿no? Efectivamente, no he hablado del almacenamiento en disco ni de la transferencia o ancho de banda.

¿Por qué no he hablado de estos dos recursos? Pues porque, sinceramente, no son importantes a la hora de ejecutar scripts o servir páginas. Simplemente son dos recursos asociados a un concepto antiguo del hosting que consistía en alojar páginas en HTML e imágenes.

Aquí es donde entra la filosofía y transparencia de cada proveedor de hosting, ya que mientras unos mostramos los recursos ofrecidos claramente, otros siguen usando el concepto antiguo y poco transparente.

Además de esto, hay otros límites específicos que aplican a hosting compartido o a servidores VPS.

En hosting compartido, por ejemplo, se suelen limitar los procesos PHP abiertos y los procesos PHP nuevos abiertos cada minuto.

La transparencia al hablar de recursos

La transparencia a la hora de hablar de recursos en hosting compartido es algo complejo, ya que la mayoría de proveedores prefieren no comentar ciertas cosas.

Nosotros siempre hemos mencionado los recursos de CPU y RAM en nuestros planes de hosting, además de mencionar las características típicas: espacio en disco y transferencia.



Pero otros proveedores no lo mencionan, y la gente realmente no sabe lo que contrata.

Llevo ya 8 años en el sector del hosting y, personalmente, creo que se ha dado un gran paso dándole importancia a estos recursos ya que, desde que existen los hostings PHP, estos recursos son importantes, pero el sector no se había actualizado.

El concepto antiguo estaba bien cuando las páginas eran HTML, pero actualmente no es lo común y es necesario hablar de CPU y RAM como mínimo.

Vuelvo a repetir: no existe la RAM ilimitada, ni la CPU ilimitada, ni el I/O de disco ilimitado, etc.
Y si no, que alguien me enseñe un módulo de RAM ilimitado y le pago lo que sea.

La elección del stack y su configuración

Lo he dicho antes y vuelvo a repetirlo, la elección del stack es una de las cosas más importantes tanto para el cliente como para el proveedor.

Antes de nada, vamos a definir lo que es el stack.

Definimos stack como la combinación de servidor web, forma de ejecutar PHP y servidor de bases de datos.

La elección de componentes influye muchísimo, no se consigue la misma eficiencia con un servidor web Apache, que un servidor web Nginx.

Tampoco se consigue el mismo rendimiento ejecutando PHP como mod_PHP en Apache, que ejecutando PHP con PHP-FPM.

Es una cuestión de elección de componentes y de configuración de estos componentes.

Servidor web: Nginx o LiteSpeed

Durante los últimos años he predicado sobre las ventajas de Nginx y las de LiteSpeed, contando las desventajas de Apache.

Y parece que, por fin, la gente está viendo lo mismo que yo he visto hace 10 años:



Ahora mismo Nginx es el servidor web con más cuota de mercado del mundo, ya que realmente hay que sumar la cuota de Nginx (el primero) con la cuota de CloudFlare Server, que está basado en Nginx (el tercero).

Pero durante muchos años Apache fue el servidor web más utilizado y, actualmente, se sigue usando por detrás de Nginx cuando se utiliza este como proxy inverso cache.

Pero… a donde quiero llegar, es que la cuota de Apache baja cada mes:



Mientras que Nginx sube:



Y CloudFlare Server, que está basado en Nginx, también sube:



Y hasta sube LiteSpeed Web Server, un servidor web de pago que ofrece un rendimiento brutal. Precisamente el servidor web que usamos en Raiola Networks:



No hablo de otros servidores web porque IIS (Internet Information Service) sigue bajando y el resto no son implementables en hosting compartido o tienen cuotas residuales comparándolas con los que hemos mencionado.

Ahora vamos a hablar de rendimiento.

Nginx y LiteSpeed son los servidores web más eficientes y rápidos, Apache se ha quedado atrás a nivel arquitectura y no es eficiente.

La ventaja de Apache es que la gente está muy acostumbrada al .htaccess, pero LiteSpeed también es compatible con este tipo de archivos que sirven para definir comportamientos en el servidor web.

Nginx no es compatible con los archivos .htaccess, por eso se suele usar Nginx como proxy inverso cache para Apache y de esta forma aprovechar las ventajas de Nginx y las de Apache. Es cierto que un Nginx + Apache no es tan efectivo como un Nginx solo, pero al menos es mejor que Apache solo.

Esta es una comparación de rendimiento usando en cada caso un sistema de cache, para evitar que se ejecute código PHP y entren más factores en juego.



En el caso de Apache se ha usado W3 Total Cache en WordPress, ya que no tiene nada nativo. Esto creo que ya dice bastante sobre este servidor web.

Soy consultor WPO desde hace unos cuantos años y, actualmente, si me llega una web que funciona sobre Apache solo, rechazo el proyecto, ya que los tiempos de respuesta de Apache en general dejan mucho que desear:



Por no hablar del consumo de recursos al realizar exactamente las mismas acciones:



Creo que esto es una prueba lo suficientemente importante como para usar Nginx o LiteSpeed como servidor web en lugar de Apache.

También quiero comentar que en algunos casos se usa Varnish como proxy inverso cache por delante de Apache o incluso de Nginx. Esto es otra configuración posible, aunque difícil de mantener y administrar.

Forma de ejecutar PHP: PHP-FPM o LSAPI

El intérprete PHP es importante, ya no solo por la versión PHP, como hemos comentado en otro post, sino por la forma de ejecutar el intérprete PHP.

Existen varias formas de ejecutar PHP, cada una con sus características, pero también con ventajas y desventajas.

A mí, personalmente, me encanta PHP-FPM y odio mod_php. Personalmente, creo que combinar PHP-FPM con Nginx solo puede ser una combinación de stack brutal, mientras que Apache con mod_PHP o FastCGI es una combinación que para mí es lenta.

Además, PHP-FPM al ejecutarse de forma “autónoma” no depende del servidor web y si hay cualquier problema de rendimiento o retraso afecta solo al intérprete PHP y no al servidor web.



Adicionalmente, con LiteSpeed Web Server tenemos LSAPI, y puedo dar fe de que su rendimiento es literalmente espectacular.

Actualmente en Raiola Networks ejecutamos PHP LSAPI en servidores con LiteSpeed y PHP-FPM en los servidores VPS optimizados que llevan Nginx como proxy inverso para Apache (por compatibilidad con .htaccess).

Servidor de base de datos: MySQL y MariaDB

De esto poco voy a hablar, ya que es el tema del que menos controlo debido a que hay poco margen de juego con el stack, aunque adaptando la configuración del servidor MySQL o MariaDB al contenido del servidor podemos conseguir una buena mejora en las consultas o en las modificaciones.

Además, las mejoras son prácticamente inapreciables si comparamos las dos alternativas: MySQL y MariaDB.



Como ves, en situaciones de mucha carga puede verse alguna diferencia mínima, pero no es concluyente.

En Raiola Networks actualmente utilizamos MariaDB en todos nuestros servidores, aunque esto es prácticamente irrelevante para el cliente final.

La principal diferencia es que MariaDB es un fork de MySQL, actualmente MySQL está gestionado por Oracle, mientras que MariaDB es completamente opensource y está gestionado por MariaDB Foundation.