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.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
¿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. Aquí tienes un enlace: https://alvaro.click/hosting20
- Hosting Inicio SSD: 50% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM.
- Hosting Base SSD: 60% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM
- Hosting Medio SSD: 70% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM
- Hosting Pro SSD: 80% de 1 núcleo de CPU Intel Xeon E-2288G y 1 GB de RAM
- Hosting Avanzado 1 SSD: 100% de 1 núcleo de CPU Intel Xeon E-2288G y 1GB de RAM.
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.
En Raiola Networks somos conscientes de que lo “ilimitado” NO EXISTE, así que preferimos decir siempre “no medido”.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
20 comentarios
Gracias por compartir el conocimiento Álvaro, excelente post.
Saludos desde Perú.
Gracias a ti por leerme Frank 🙂
Muy interesante y bien explicado para un neófito en la materia, te aclara muchas dudas que no consigues entender cuando estás viendo ofertas y ofertas de hosting barato.
Un saludo
Hola Antonio, efectivamente, muchos hostings baratos omiten el tema de la CPU y la RAM pero aunque sean “ilimitados” es donde limitan, en los recursos importantes que no mencionan.
Que buen articulo, no tenia idea de como concionaba todo ese proceso,
Me alegro de que te sirva Raul 🙂
Hola Álvaro.
Felicitarte por Raiola, estoy muy contento con el hosting.
Quería consultarte sobre el rendimiento de cache en Ram. Veo que otros hosting lo han implementado en planes compartidos y me gustaría saber si tenéis fecha en Raiola para ello. Entiendo que aumentaría aunque sea ligeramente la velocidad de carga de mi web.
Gracias!
Hola Marcos, nosotros ofrecemos cache en RAM pero solo para cache de pagina con LiteSpeed; sin embargo, si te refieres a Object Cache, no tenemos pensado implementarlo en hosting normal, aunque puede que lo hagamos en los planes de hosting Avanzado en breves.
La razón es que el publico al que se dirige el hosting compartido normal, en la mayoría de casos no es consciente de los problemas intermitentes que puede causar por ejemplo con un Prestashop con Memcached en un hosting Inicio o Base, es decir, queremos evitar problemas.
Nuestros planes de hosting compartido están limitados a 1 GB de RAM, con esa memoria RAM Memcached o Redis puede llegar dar problemas en webs complejas o con trafico.
En cuanto al cache de LiteSpeed, se gestiona externamente independientemente de la RAM del hosting del cliente.
Hola Álvaro.
No se si te he entendido bien, Litespeed guarda la cache en disco no? Por eso no he entendido lo de que tenemos cache en RAM.
He pensado pasarme a un VPS optimizado, pero me da miedo por el cambio de IP que pueda afectar al posicionamiento y también que nunca he contratado uno por lo que no se cuanto me costaría administrarlo solo para mi web. Un VPS administrado se me va de precio, por eso buscaba una solución intermedia entre el VPS y lo que tengo actualmente. No necesito más RAM, ni CPU, ni banda pero si pagaría y estaría supercontento por un plus de velocidad.
A nivel de optimización de wordpress no puedo apretar ya más y he probado ya 4 CDNs y la velocidad de carga me empeora por lo menos aquí en España. ¿Esto es normal? Quizá no lo esté probando bien aunque siempre sigo tus tutoriales.
Aprovecho a consultarte también: he activado opcache en el php, no he notado nada, ¿está bien que lo habilite o lo quito? Estoy en un plam Wordpress compartido.
SI se te ocurre algo que pueda hacer, te lo agradezco, ram no consumo más de 100MB aprox.
Perdón por extenderme.
Gracias.
Hola Marcos, LiteSpeed guarda cache donde le digas (no hablo del plugin, sino del Webserver) y nosotros en Raiola Networks lo guardamos en un RAMDisk y por lo tanto se carga desde RAM.
El cambio de IP no te va a afectar al posicionamiento, ya que sino las webs que están usando CloudFlare no posicionarian por estar constantemente cambiando de IPs dentro del pull.
Depende del producto que tengas ahora, pero si no tienes requisitos especiales a nivel CPU o RAM, si no sabes nada de VPS, quizás no sea el mejor producto para ti. Yo por ejemplo, en este blog estoy con un VPS optimizado porque tengo varios scripts y subdominios que tienen ciertos requisitos.
Tema de CDN, envíame mas detalles por privado a intento orientarte, ya que no es normal, aunque depende del CDN…hay cada uno…
Desde PHP7, con el OPCache solo vas a notar algo si lo buscas, es decir, haciendo un benchmark o en entornos de mucha carga de visitas. Esta bien tenerlo activado, sobre todo si vas a usar algún plugin como Docket Cache, pero no es para notar directamente.
Hola Álvaro,
Te felicito por el articulo.
Me gustaría preguntarte lo siguiente: yo tengo una tienda online y tengo instalado un plugin para pruebas que clona la web, y ahí pruebo nuevos plugins y hago las actualizaciones de todo, para comprobar que no hay ninguna incidencia en la web.
Cuando dejo de realizar las pruebas desactivo el plugin (WP STAGING), pero siempre tengo la duda de si, no es mejor, eliminar el clon de la tienda o no?
Bien la pregunta es el plugin desactivado con la copia de la tienda consume recursos de mi hosting?
Seria mejor eliminar el clon, y volverlo a crear cuando tenga que realizar mas pruebas?
Hola Francisco, todo depende de si la tienda esta en el mismo plan de hosting o no. Si esta en el mismo plan de hosting, las ejecuciones de WP CRON pueden causar un pequeño consumo de recursos.
Hola, muy buen contenido, te consulto. SI quisiera alojar 6 sitios web (consultoras, servicios profesionales, etc) que no sean complejos y de unas 6 a 10 paginas cada una, cuanto en nucleos o RAM necesitaria para que los sitios trabajen perfectamente.
Te agrdezco cualquier comentario o sugerencia.
Hola Michael, pues…no te podría decir exactamente porque depende de muchos factores, pero con menos de un vCore y con 1GB de RAM seria suficiente. Aparte de eso si tienes imágenes muy pesadas, tendrías que tener mas de 4MB de I/O.
Hola Álvaro,
No necesito nada, solo felicitarte por el blog.
Un saludo.
Gracias a ti por el comentario Joan, que se me escapo sin contestar 😉
Hola, quisiera consejo para contratar algo que funcione, mi hosting actual se cae con mi web cada vez que actualizo mi formulario complejo, contiene miles de operaciones y cientos de condiciones.
Necesito poder ampliarlo sin estar rezando para que me deje guardar el trabajo y no aparezca un 502 o 503.
Gracias de antemano
Hola Manel, escríbeme a https://alvarofontela.com/contacto/ e intentamos ayudarte desde Raiola Networks.
a veces uno como usuario,pide tantas especificaciones y hay algunas cosas que sabemos ,pero no sabemos como es el funcionamiento..es como saber que un carro es para transportarnos de un lugar para otro,pero no sabemos como es el proceso para que las ruedas funcione ,por ejemplo. muy ilustrativo este blog,uno nunca deja de aprender ..gracias por compartir tus conocimientos…
Gracias a ti por el comentario Ever 😉