El problema con Cloudflare y nginx

Después de escribir WordPress y el problema con wp_options en donde explicaba que gracias al nuevo alojamiento había podido migrar del servidor web Apache a nginx continué haciendo seguimiento y pruebas.

Me di cuenta que aunque nginx iba bastante rápido, en una máquina de esa capacidad debería dar bastante más rendimiento. Observé también como ocasionalmente, no necesariamente bajo elevada carga se producían errores internos de servidor (500, 501, 502, 520, …), y como consecuencia se rechazaban esas conexiones.

La primera conclusión a la que llegué es que el problema estaba en nginx, o al menos en la configuración concreta que yo usaba. Este desarrollo ruso lanzado en 2004, se concibió precisamente para mejorar el rendimiento de Apache. En efecto sirviendo archivos estáticos, nginx es muy rápido, está optimizado para ello implementando lecturas y escrituras asíncronas o con un eficiente caché. Sin embargo con archivos dinámicos, es decir los que provienen de la mayoría de webs en donde el contenido cambia a menudo como es mi caso y el de la mayoría, sus ventajas ya no están tan claras. Según pude leer, su principal problema es que cuando se activa la compresión gzip o brotli, nginx necesita comprimir toda la respuesta antes de empezar a enviarla. Eso significa que hasta que WordPress y PHP no han generado el contenido completo nginx no lo puede comprimir y enviarlo. La consecuencia es que el TTFB, es decir, el Time To First Byte, lo que espera el usuario para empezar a recibir la información aumenta.

Con Apache esto no así, y desde que se empieza a generar la información él puede comenzar a enviarla. Pero en tecnología todo cambia muy rápido y si es cierto que hasta 2012 Apache fue volviéndose cada vez más lento y pesado, con la versión 2.4 de ese año las tornas empezaron a cambiar y su velocidad aumentó.

El otro problema con el que me topé fue con Cloudflare un CDN que llevaba usando años y que siempre había ofrecido una buena mejora de rendimiento. Con Cloudflare ocurría algo parecido, y es que internamente funcionan también con nginx.

Como decía, regresé de nginx a Apache y eliminé Cloudflare. El TTFB pasó de unos 450ms a unos 120ms, casí 4 veces más rápido. Pero además, según Apache Bench (ab), la capacidad del servidor pasó de 90 solicitudes/segundo hasta las casi 1.300; casi 15 veces más rápido. Considerando que mi página requiere de unas 60 solicitudes distintas para cargarse, eso da una potencia aproximada de 21 páginas servidas por segundo, un buen pico que si se mantiene llega hasta las 75.000 a la hora.

El problema con Cloudflare y nginx

Si lo comparo con otras webs de relojes las cifras son altas, puesto que esas suelen dar entre 150 y 600 solicitudes por segundo.

A veces menos es más.

El problema con Cloudflare y nginx

El problema con Cloudflare y nginx

El problema con Cloudflare y nginx

10 comentarios en “El problema con Cloudflare y nginx”

  1. De nuevo te doy las gracias amigo Guti, gracias por tu esfuerzo para divulgar en esta chulada de Bitácora.
    Feliz diciembre!!

  2. Genial! Que alegría que Bitacora esté cada vez más más optimizada, junto a este contenido que aporta de verdad. Un lujo que valoro muchísimo. Espero que siga creciendo y que te siga dando muchas satisfacciones Guti.
    Gracias por compartir tanto y saludos a todos

  3. Javier Gutiérrez Chamorro (Guti)

    Es duro y requiere mucha dedicación, pero también es justo reconocer que a veces me entretiene estar a la última ARBcuentatiempos.

  4. Javier Gutiérrez Chamorro (Guti)

    En eso seguimos Cesar+jose+Maestre, rascando por aquí y rascando por allá. Así que tras la de horas que perdí investigando el tema me dije que al menos un post valdría la pena, ayudaría a otros con problemas similares.

  5. Esta parte del “trabajo sucio” tiene que ser un auténtico quebradero de cabeza para cualquiera que quiera iniciarse en el mundo de los blogs y no sea alguien con grandes conocimientos.

    Blogger (don´t be evil….me río por no llorar) ofrece al “lego” una alternativa fácil, o al menos eso parece. Sí, he leído mucho acerca de la posibilidad de perder todos los contenidos el día que a Google le de la gana, pero me gustaría saber si tienes datos acerca del tiempo del “enemigo” de wordpress.

    Es por curiosidad, pues supongo que Google se encargará de la “fontanería”. Un saludo.

  6. Javier Gutiérrez Chamorro (Guti)

    Si usar Blogger/Blogspot o incluso WordPress.com, efectivamente ellos se encargan de todo el trabajo sucio WR_100. Ellos parchean servidores, actualizan plugins o componentes… Te ahorras eso. Pero también aplican cambios que te pueden no interesar, el controvertido nuevo editor de blogger, o su contrapartida con el Guttemberg de WordPress. Son cosas que si tu tienes el control puedes desactivar o puedes elegir no actualizar. Cuando estás en manos de otros, pues pasa eso.

    Nada es perfecto, y aunque se quiera dar la imagen de que es algo accesible para cualquiera es falso. En el mejor de los casos requiere tiempo y si vas más en serio dinero. Ese es el motivo por el que la vida de un blog es tan corta, la gente se cansa. Y el porqué los que tienen historia son medios comerciales, porque de algún modo has de pagar al técnico que te gestione el sistema.

  7. Lo curioso es la meritoria resistencia de Zonacasio dentro de blogspot sin eliminar la coletilla o pasarse a un dominio/nombre propio.

    No entiendo muy bien cómo van estas cosas, pero es la excepción a la “ley” mil veces escrita de que lo primero que hay que hacer para monetizar un blog y tener éxito es usar un nombre sin coletilla de “gratuíto”.

  8. Javier Gutiérrez Chamorro (Guti)

    Bueno WR_100, Zonacasio tiene activo también Zonacasio.com, aunque no deja de ser una redirección. También creo que hay mucha leyenda urbana en cuanto a la monetización, principalmente generada por personas que te venden sus servicio para que monetices. La primer pregunta es, ¿Monetizar para qué?

    Si quieres monetizar para cubrir gastos, es decir el pago del dominio y del hosting sencillamente es más fácil irte a una plataforma gratuita. Así no hay gastos y por tanto no es necesario monetizar. En esa situación, si ganas algo, aunque sea muy poquito es para ti. Si entramos en cosas más serias todo cuesta dinero, así que los ingresos son algo fundamental sino quieres estar cada mes poniendo dinero de tu bolsillo (aunque no sea una cantidad exorbitante).

    Si lo que se pretende es monetizar para cubrir las horas que pasas “quemándote las pestañas”, puedes irte olvidando. En la mayoría de casos eso no funciona, ni en web, ni en redes sociales, ni en vídeos. Aunque seas alguien que tiene buena acogida como es mi caso, el canal de Youtube de GES o ZonaCasio las horas que se echan nunca se van a cubrir. Te va a salir mucho más rentable invertirlas cuidando niños, paseando perros, o limpiando cosas. Trabajos no cualificados donde a malas te vas a sacar 5€/hora.

    Evidentemente cuando llegas a la cumbre, y para ello me refiero a unas pocas webs internacionales que tienen millones de visitas al mes, comparable a la de los diarios líderes del panorama nacional, o a Youtubers con centenares de miles de visualizaciones en sus vídeos. Algo a lo que la mayoría no llegaremos. Primero por centrarnos en el español, que a fin de cuentas no es el idioma top, y en segundo lugar porque la relojería es un nicho relativamente pequeño.

Deja un comentario