El objetivo de este post es explicar cómo influyen los recursos disponibles en el funcionamiento de un hosting o servidor web. Para eso, antes tengo que explicarte cómo funciona un hosting y eso es precisamente lo que voy a hacer. A continuación, expondré algunos benchmarks y pruebas de rendimiento para que veas la diferencia entre un hosting muy barato y un hosting muy potente.
Muchos usuarios aún no son conscientes de que, al contratar un hosting, no solo se contrata el espacio y el ancho de banda, sino también el derecho a utilizar CPU (procesador), RAM (memoria) e incluso acceso a leer y escribir en el disco duro del servidor. Todo esto que acabo de comentar se limita (aunque el proveedor de hosting no te lo diga) porque lo ilimitado no existe.
En Raiola Networks especificamos todo esto SIEMPRE:
Si ponemos “no medido”, es diferente de ilimitado. Quiere decir que no tenemos en cuenta ese parámetro porque sería imposible que el cliente superara el uso permitido sin verse limitado antes por otros recursos.
Cada petición que se sirve desde el hosting consume recursos, pero no solo eso: los CMS actuales ejecutan procesos internos (por ejemplo, el wp-cron.php en WordPress) que también consumen recursos, sobre todo CPU y RAM.
Para poder utilizar bien un hosting y ser consciente de sus limitaciones, es necesario entender perfectamente los recursos y el funcionamiento de un plan de alojamiento. Esto es precisamente lo que vamos a explicar en este post.
¿Cómo funciona un hosting?
1 – El visitante accede a cargar una imagen en la web
2 – El visitante solicita una página web estática (HTML)
3 – El visitante solicita una página dinámica
4 – El visitante solicita una página dinámica cacheada
Otras variantes y conclusiones
La potencia de CPU y la velocidad en hosting
¿Cuántas visitas soporta un hosting?
¿Cómo funciona un hosting?
Como hemos dicho, al servir peticiones se ejecutan ciertos procesos que consumen recursos. Cualquier acción que realicemos en un sitio web alojado en un hosting consume recursos SÍ o SÍ, todo tiene un coste.
Vamos a mostrar varios casos básicos para que veas el funcionamiento de un hosting. Los organizaré de más simple a más complejo o específico.
1 – El visitante accede a cargar una imagen en la web
Como primer ejemplo, vamos con lo más básico: una petición para cargar una imagen. Esto es simple, pero es un caso común en el 99,99% de los casos.
El visitante, mediante el navegador, carga una URL que lleva a una imagen.
El navegador del visitante (sea el que sea) hace una petición HTTP al servidor web. El servidor web busca el archivo (si existe dentro del VHOST para la ruta especificada en la petición HTTP) y lo envía al navegador web del visitante.
Fácil, ¿no? Este es el caso más simple: una simple imagen o archivo estático como un PDF o un archivo JS o CSS que, si existe, será enviado al visitante.
Se consumen recursos de RAM y CPU, además de I/O de disco, pero muy pocos. Esto se debe a que el servidor web no suele ser lo que más consume. Además, este proceso puede ser más eficiente si se tiene configurado el cache de navegador de forma correcta.
2 – El visitante solicita una página web estática (HTML)
En este caso un poco más complejo, la cosa es más o menos igual que en el caso de si se tratara de un archivo estático, pero además hay que servir los recursos como imágenes, JS y CSS.
El proceso comienza del mismo modo. El visitante hace la petición con el navegador web al servidor, pidiendo una página estática HTML. Si existe en la ruta especificada, se envía al navegador del visitante.
El navegador del visitante la interpreta y pinta en la pantalla el contenido visual, pero para hacerlo necesita descargar del servidor los recursos (imágenes, JS, CSS, fuentes, etc.). Por ello, en condiciones normales va ejecutando el proceso descrito en el punto 1, una y otra vez, hasta tener todo lo necesario.
Al igual que en el punto 1, se consumen recursos de RAM y CPU, también I/O de disco, pero el consumo es bajo debido a que no hace falta procesar nada. Son simplemente peticiones.
3 – El visitante solicita una página dinámica
Aunque el contenido dinámico se sirve también por HTML, este no es estático y tiene que generarse. Normalmente, en las páginas dinámicas, los datos se almacenan en bases de datos y el código PHP tiene las instrucciones necesarias para crear el HTML como si fuera estático, pero con el dinamismo necesario.
Cuando un visitante hace una petición a un servidor web a una ruta de una página que debe generarse dinámicamente, el navegador del visitante hace la petición y el servidor web entiende que tiene que crear la página usando el intérprete PHP. De este modo, el intérprete PHP ejecuta el o los archivos PHP correspondientes solicitando datos a todos los orígenes necesarios para, finalmente, montar un archivo HTML que será servido al visitante.
A partir de aquí, el proceso es exactamente el mismo que en el punto 2: se sirve el HTML al visitante y después se cargan los recursos.
En este caso sí que se consumen más recursos de CPU, RAM e incluso I/O de disco. También aumentan los tiempos de espera, ya que hay que procesar datos y recuperarlos de donde haga falta para montar el HTML. Eso lleva tiempo.
4 – El visitante solicita una página dinámica cacheada
Por último, vamos con el tema más complejo y que más se acerca actualmente a la realidad de la mayoría de los sitios web.
Todo empieza igual. El visitante realiza la petición de una página que debe montarse dinámicamente al servidor web. Sin embargo, en este caso existe un sistema de cache y el servidor web, antes de pedirle al intérprete PHP que genere la página, comprueba si el HTML estático ya está generado en el sistema de cache de página.
Si la página se encuentra cacheada, se ejecuta el proceso como en el punto 2. De este modo se ahorran muchos recursos de proceso y, al mismo tiempo, se bajan bastante los tiempos de respuesta porque se está sirviendo una página estática.
Si la página no está cacheada, debe generarse y se ejecuta el proceso tal y como se muestra en el punto 3.
En este caso, si la página esta cacheada no se consumirán casi recursos y tampoco habrá tiempos de espera. Si la página NO está cacheada, se consumirán recursos y habrá un aumento en el tiempo de respuesta, como en el caso del punto 3.
Otras variantes y conclusiones
Lo que he mostrado anteriormente son distintos procesos, desde más simple hasta el más complejo y real. No obstante, existen muchas otras combinaciones y casos, ya que hay otros sistemas que modifican el proceso y que mejoran la eficiencia a cambio de que este sea un poco más complejo y difícil de explicar para gente sin conocimientos sobre el tema.
Actualmente se utilizan bastante los sistemas de cache de objetos, que modifican el funcionamiento del intérprete PHP haciéndolo más eficiente. También está el cache de navegador, que ahorra muchos recursos al reducir peticiones.
Otros factores que influyen en cómo se ejecutan los procesos son los servicios CDN, los proxy inverso y el cache de navegador. Cuanto más compleja sea la web, más sistemas se implementan para mejorar la eficiencia y también deja de ser tan fácil explicar cómo funciona el conjunto completo de una forma simple y fácil de entender.
Si lees el final de cada punto anterior verás que, cuanto más complejo es el proceso, más recursos se consumen en el hosting y (repito) los recursos consumidos NO solo son el ancho de banda y el espacio en disco. Un plan de hosting funciona sobre un ordenador (servidor) y todos los procesos se ejecutan sobre una CPU (procesador) y en una memoria RAM que NO son infinitos.
La potencia de CPU y la velocidad en hosting
Volviendo al tema de los recursos de CPU y RAM y de cómo influyen, voy a demostrar con pruebas cómo afectan a la ejecución y a la velocidad de respuesta.
Para esto, he realizado algunas pruebas en formato benchmark utilizando un script PHP de benchmark y un sistema externo de prueba de sobrecarga llamado Loader.io.
Durante el proceso, he empleado los planes de hosting compartido de Raiola Networks, así como los planes de hosting avanzado.
Los resultados, utilizando este script de benchmark, son estos:
¿Qué quiere decir esto? Pues que, en una situación ideal en la que no exista otro tráfico distinto al de la prueba, cuanta mayor sea la potencia de CPU antes tendremos el resultado de las pruebas matemáticas ejecutadas en el script de benchmark.
La tabla de la derecha es simplemente para que veas la versión de PHP utilizada y cómo saca los datos el script. Si quieres utilizar este script, puedes descargarlo desde aquí: DESCARGAR
Los tiempos no son directamente proporcionales a la potencia, pero esto no es todo así de simple. Los núcleos de CPU también influyen junto con la potencia en Ghz y esto depende del tipo de procesador utilizado. En este caso, el servidor lleva un Intel Xeon E-2288G y cada hilo rinde a 3,70 Ghz.
También debemos tener en cuenta que, cuanta menos potencia tenga un hosting y más tiempo tarde en ejecutar los scripts PHP necesarios para generar el HTML, más posibilidades tiene el hosting de saturarse al no poder realizar el trabajo lo suficientemente rápido en entornos con tráfico.
¿Cuántas visitas soporta un hosting?
Las visitas que aguanta un hosting no dependen directamente de la potencia. Sin embargo, cuanta más potencia de CPU y RAM tengamos, más visitas vamos a poder recibir si la web ya está optimizada o en condiciones óptimas.
Mucha gente se hace esta pregunta continuamente y en el departamento comercial de Raiola Networks siempre respondemos que, aunque no depende de nosotros directamente (porque solo el cliente sabe cómo de optimizada está su web), podemos dar una estimación de lo que consumirá la web al verla funcionando en el hosting anterior.
Por otro lado también quiero recalcar que, en este sentido, la versión 7.X de PHP ha ayudado mucho a aprovechar mejor la potencia de proceso y es un gran salto para el WPO desde la rama 5.6.
Vamos a suponer que ejecutamos la misma web (en este caso, el script de benchmark) y le lanzamos la misma cantidad de tráfico, pero sobre distintos planes de hosting con diferente potencia. En este caso, he ejecutado los test sobre los siguientes planes de hosting:
Plan Inicio SSD: 50% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM.
Plan Pro SSD: 80% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM.
Plan Avanzado 4 SSD: 100% de 4 núcleos de CPU Intel Xeon E-2288G y 4 GB de RAM.
Este último plan tiene muchos más recursos y lo he añadido a la prueba, para que se vea la diferencia entre 1 núcleo de CPU y 4 núcleos de CPU al soportar tráfico y carga de proceso.
El script de benchmark esta creado precisamente para eso, para que sea pesado y le exija al plan de hosting usar los máximos recursos.
En la siguientes gráficas puedes ver cómo afectan los recursos a la prueba. Una vez más, esta ha sido realizada con Loader.io, un test de 1 minuto donde se van subiendo los usuarios concurrentes de 1 a 100 visitantes. El tema es que, al utilizar el script de benchmark (que no es cacheable) y no una web normal, llega un punto que el hosting se satura. Con una web normal no se llegaría a saturar, pero esto es precisamente lo que buscamos en esta prueba.
¿Qué intento demostrar con estos benchmarks de rendimiento? Pues simplemente quiero sacar de la cabeza a mucha gente que el disco duro y el ancho de banda que ofrecen los planes de hosting influyen en el rendimiento. Lo que realmente influye en el rendimiento son los recursos de CPU, la RAM, el I/O de disco y la prioridad de ejecución. Además, existen algunas métricas más que afectan y que normalmente son internas.
Lo normal es alcanzar el límite de CPU y RAM durante la ejecución de PHP compleja, pero también podemos alcanzar el límite de I/O en disco fácilmente al realizar actualizaciones en los CMS o al tener mucho tráfico descargando archivos estáticos grandes a la vez.
Lo que puedes ver en la imagen anterior son las métricas medidas en un hosting compartido con cPanel y CloudLinux. Como has visto, nada es infinito. Se suelen limitar el número de procesos, la RAM, la CPU, el I/O y los IOPS. Aunque en algunos valores los números pueden llegar a ser lo suficientemente altos como para no tener que preocuparnos, eso no quiere decir que sean ilimitado.