Gestionar la caché

y evitar hacer trabajar al servidor que tiene otras cosas que hacer

En las lecciones precedente hemos comenzado a elaborar los esqueletos. El éxito de nuestro sitio web corre el riesgo de ser fulgurante. Pensemos enseguida en las pobres neuronas de nuestro ordenador. En esta lección, nada de divertido, tampoco nada de esencial. Los y las perezosos/as aprovecharán para acurrucarse en el fondo, cerca del radiador. ;-)

Resumen para ellos y para la gente que tiene prisa: en los ficheros de llamada de tipo tutorial.php3, cambiar por $delais = 3600 ; la cifra de 0.

En el momento en el que una página es solicitada a SPIP este comprueba si, por azar, esta página ya ha sido vista anteriormente. Si la URL solicitada es http://tusitio.net/tutorial.php3?id_article=12, SPIP mira en su sub-repertorio CACHE/ si este fichero existe y, en caso de que así sea, compara la fecha del fichero caché a el $delais (plazo) fijado en le fichero de llamada tutorial.php3.

En nuestro ejemplo habíamos fijado un plazo de $delais=0; es decir que se produce un cálculo sistemático de las páginas en cada consulta del sitio. Pasemos a $delais=3600 ; (se expresa en segundos).

Nuestra página web sólo es renovada si, cuando un o una visitante la solicita, su versión en caché data de más de una hora (es decir 3600 s.) De lo contrario SPIP lee simplemente el contenido del fichero caché [1] y reenvía el resultado sin conectarse a la base de datos (salvo para insertar un “hit” en las estadísticas).

¿Como fijar estos $delais para optimizar la relación reactividad/carga del servidor? No hay soluciones milagrosas pero no dudes en fijar un plazo de un día (i.e. $delais=24*3600) o más, para los artículos y las secciones (rúbricas). Las páginas de navegación más importantes pueden tener $delais más cortos (veinte minutos o una hora, por ejemplo) si se supone que tu sitio debe a reaccionar con frecuencia a la validación de noticias breves y de sitios sindicados... Si estás albergado en un servidor compartido con otros sitios, debes ser respetuoso/a con los demás y no tomar todo el tiempo de cálculo para páginas que raramente cambian: sería especialmente tonto por lo que respecta a los artículos grandes o en los sumarios, ya que el cálculo de páginas puede tomar algunos segundos, lo que ralentiza la consulta de tus páginas...

¿Como provocar una puesta al día fuera de plazo? Acabamos de decidir $delais extremadamente largos y nos damos cuenta de una falta de ortografía en una página. Corrección en el back-office... ¿Como borrar de inmediato tal villana cicatriz del sitio?

-  Desde una página de modificación de artículo o sección el back-office (la interfaz privada de SPIP), al pinchar en «Ver en línea» (abajo del n° de artículo o sección) se inicia la actualización de la página correspondiente a #URL_ARTICLE o #URL_RUBRIQUE del artículo o de la rúbrica que acabas de corregir. Este es el caso más frecuente. ¿Pero sinó, cómo actualizar un esqueleto personalizado?

-  La solución más sencilla consiste en pinchar en el botón “Actualizar esta página” que le aparece al administrador en la zona inferior izquierda de cada página del sitio público. Cabe recalcar que éste botón te aparece únicamente si eres administrador, y sólo una vez que te hayas conectado a la interfacz privada (back-office) desde el navegador que utilizas. Para ésto, SPIP coloca un cookie en tu navegador que le permite reconocerte. Si deseas suprimir ese cookie, lo puedes hacer desde la portada de la interfaz privada, pinchando en el triángulo al lado de tu nombre, que muestra tus informaciones personales.

-  Finalmente, en el back-office del sitio, en la sub-sección «Mantenimiento del sitio» de la «Administración del sitio», encontrarás los comandos para «vaciar la caché» que borra todos los ficheros de la cachés (útil si haces muchas modificaciones y con un sitio muy complejo, evitar si no es así).

Volviendo al contexto: Volvemos aquí sobre la noción de contexto. Si se llama un esqueleto con un contexto de id_article, de id_rubrique o incluso id_breve, se propone otro botón cuando SPIP detecta el cookie : « Modificar este artículo (ou sección, o breve) », que conduce directamente a la página correspondiente en el back-office. ¿Y se le dice gracias a quién?

Últimos detalles:

-  por razones evidentes el motor de búsqueda no dispara la cache y se reactualizan las páginas con forum son en cuanto se envía una nueva contribución.
-  la carpeta CACHE/ en la ramificación del sitio se divide en 16 sub-carpeta numeradas 0, 1, 2... 9, A, B... F, en las cuales los ficheros cachés se distribuyen casi-aleatoriamente; esto se llama «hacer un hash de la caché» y sólo por ello ya merece que se le mencione.
-  los ficheros cachés quedan accesibles incluso si la base de datos “se cae”, lo que proteje al sitio en caso de averías transitorias del servidor mySQL.

Notas

[1Para los/las especialistas, se trata de hecho de un include PHP del fichero correspondiente, permitiendo ejecutar el código desde la caché


Traducido por:
Montserrat Boix
Mujeres en Red por el Software Libre y no sexista

Autor o autora mboix Publicado el: Actualizado: 26/10/12

Traducciones: عربي, català, corsu, Deutsch, English, Español, italiano, Português, русский, slovenčina, Türkçe, українська