Un problema tÃpico de sitios web dinámicos es que las páginas de inicio (o páginas interiores) requieren muchas llamadas a servidor de base de datos y por ello, incluso páginas ligeras de peso, a veces se ralentizan más allá de lo que se considera aceptable por los que navegan.
Este problema se ha visto agravado cuando a raiz de la implementación del famoso proxy-cache de Telefónica la mayorÃa de sitios, como defensa, optaron por especificar en su header que no fuesen cacheados.
Sin embargo esto es una solución desproporcionada. Optar por generar y enviar el sitio una y otra vez para cada nuevo usuario que se conecta sobrecarga el servidor. En realidad las páginas de inicio raramente necesitan actualización ininterrumpida a cada segundo.
Definiendo ciertos parámetros podemos usar los caches de manera que nuestra web este actualizada. Al mismo tiempo conseguimos más rapidez y utilizar menos ancho de banda porque el sitio no se descarga de nuestro servidor sino desde la cache del proxy.
Comprobar la cacheabilidad de nuestra web
Antes que nada podemos comprobar que tal está cacheada nuestra web en esta dirección:
En la información de "Last Modified" podemos ver si nuestro sitio esta optimizado. Si por el contrario envÃa un "No-Cache" o no especifica nada estamos enviando y generando el sitio una y otra vez sin aprovechar los beneficios de la cache intermedia.
Las páginas de inicio dinámicas
Al igual que muchos otros sitios, LoQUo.com dispone de una home dinámica donde se muestra el numero de anuncios activos y sufre este problema. Para aliviarlo, la solución ha sido cachear los contenidos de la home en disco y solo regenerarlos, o sea, acceder a base de datos, cada cierto tiempo.
En LoQUo, este intervalo es de 10 minutos. Otras páginas interiores pueden permanecer cacheadas por mucho más tiempo, incluso semanas, pues los anuncios están activos durante 30 dÃas y no suelen modificarse.
Cómo funciona una cache intermedia
Me atrevo a simplificar el problema para poder exponerlo con más claridad.
En los sitios dinámicos (e.j. paginas cuya información en parte procede de bases de datos) casi nunca se puede saber a priori por cuanto tiempo una pagina se mantendrá sin cambios, o sea, que tiempo podrÃa estar cacheada en proxies intermedios (como el de Telefónica) o en el disco duro del usuario que navega por internet.
Generalmente si se puede saber la fecha de la última actualización de una página, pero no asà por cuanto tiempo podrÃa ser válida, es decir, cuando se va actualizar. Por ejemplo, un anuncio en Loquo.com lo pone el usuario (sabemos cuando puso), pero lo puede modificar en cualquier momento (no sabemos cuando lo modificará).
La reacción tÃpica a este â??inconvenienteâ? es declarar (mediante un header en el protocolo http) que el sitio no es cacheable. Pero esta simpleza usualmente se traduce en gasto innecesario de ancho de banda en el servidor (mayores costes) y en un mayor tiempo de descarga para el usuario final.
Esta solución es la más extendida puesto que se sugirió en esta noticia de Barrapunto e incluso la Asociación de Internautas creó un programa para navegar saltándose la cache de Telefónica.
¿Entonces qué se puede hacer? Pues tratar de cooperar con la infraestructura de caching, proxies, etc en Internet y no verlos como el enemigo de los sitios dinámicos, como suele pasar.
Usando la cache a nuestro favor
Concretamente, para cooperar con la cache, hay que incluir un http header con la fecha de la última actualización (Last-Modified) y responder apropiadamente al â??If-Modified-Sinceâ? que se en envÃa desde el proxy intermedio para comprobar si la página ha sido actualizada.
Es decir, si la página no ha sido modificada, la almacenada en el proxy sigue siendo buena y por tanto en lugar de enviar la página de nuevo se envÃa un código de respuesta 304, lo que conlleva reducir el ancho de banda utilizado de nuestro servidor.
En caso contrario, cuando la página ha sido modificada, se envÃa la nueva página, que es lo que se hace en siempre que no se utilizan estos parámetros, es decir, no participar en el http caching.
Esta estrategia permite a LoQUo ahorrar costes en ancho de banda al hacer que muchas páginas se descarguen desde la copia almacenada en el proxy, y no desde nuestro servidor.
Además, hace que el tiempo de descarga disminuya considerablemente, o sea, el usuario final percibe que el sito funciona más rápido.
Problemas de las caches
Desafortunadamente, no todo es color de rosa, pues cada proxy-cache intermedio tiene sus idiosincrasias y su propia heurÃstica para determinar si un contenido en su cache es válido o no. En el caso del famoso Proxy de Telefónica, está explicado en este documento.
- Documento sobre el proxy de Telefónica en PDF (19 pág / 392Kb).
Al parecer, las intenciones de Telefónica son buenas, pero la implementación en algunos casos deja mucho que desear.
Por ejemplo en el caching de imágenes, no se respeta el Etag (código identificador de una imagen) y se recomienda, en caso de modificar una imagen, que se cambie el nombre del fichero. Esto es inaceptable y obliga a hacer cambios de código innecesarios, el Etag se ha creado precisamente para evitar esto.
En el caso de LoQUo, por ejemplo, en la home se generaba un nuevo thumbnail (imagen reducida) cada vez que se cambiaba la imagen de portada, pero el nombre del fichero era el mismo. Con el Proxy de telefónica, hubo que cambiar el código, generar un fichero nuevo y hacer los consiguientes ajustes al html de la home.
El otro tema, no menos grave, es que en su heurÃstica, al parecer, en algunos casos se omite la pregunta al servidor si la pagina ha caducado o no, o sea, no se hace una petición con el If-Modified-Since header. Este comportamiento me parece un poco agresivo; en casos que el desde el sitio web no se especifique un tiempo de validez de una página, en mi opinión siempre hay que preguntar, a traves del If-Modified-Since header y solo servir desde el cache si el servidor responde con â??Status: 304 Not Modifiedâ?
En cualquier caso, poca gente se ha quejado de ver contenidos antiguos (stale) en Loquo, por suerte, los logs de apache están repletos de respuestas 304 (o sea, la pagina no ha cambiado), lo que supone un ahorro significativo de ancho de banda y mayor velocidad de descarga para el usuario final.