Mucho se ha dicho recientemente sobre los méritos de los sitios estáticos . Pero en muchas situaciones, un enfoque dinámico es una necesidad. Ya sea un sistema de administración de contenido, una herramienta de relación con el cliente o una tienda en línea, permiten a los usuarios finales mantener sitios complejos de forma rápida y consistente. Y cuando se combinan adecuadamente, pueden competir con los sitios estáticos por la velocidad.
cualquier aplicación que necesite leer y escribir datos con frecuencia causará un retraso notable
Cualquiera que sea el sistema que use, los sitios dinámicos generalmente forman parte de elementos similares. Estos son una forma de servidor web, un servidor y una aplicación, escritos en uno o más lenguajes de programación. Esta combinación de componentes ofrece una gran flexibilidad, pero cada uno contribuye con sus propios gastos generales y aumenta el tiempo de carga, algo que todos los sitios web modernos desean evitar. Esto es especialmente cierto con el acceso a la base de datos: cualquier aplicación que necesite leer y escribir datos con frecuencia causará un retraso notable.
Aquí es útil el almacenamiento en caché y una estrategia de almacenamiento en caché adecuada para su caso de uso. El objetivo básico del almacenamiento en caché es evitar llamadas innecesariamente frecuentes entre las capas de la base de datos de la aplicación y, en su lugar, utilizar páginas HTML estáticas pregeneradas, que son mucho más rápidas de representar en un navegador.
El primer caché que cualquier usuario de la web habría notado es el caché en su navegador. ¿Cuántas veces los desarrolladores le han pedido que realice una "actualización forzosa" para ver los cambios? Las memorias caché del navegador son simples pero un buen punto de partida para comenzar a explicar los conceptos de almacenamiento en caché. Un navegador almacena representaciones de páginas web visitadas en la computadora de un usuario, por lo general actualizándolas una vez por sesión si el sitio detecta o impone cambios.
Una herramienta común empleada por los propietarios y administradores de sitios es un "caché de proxy inverso" que se ubica entre las solicitudes de página realizadas por un navegador web y la aplicación web. Se intercepta las solicitudes y hace copias de las páginas directamente desde la memoria caché, lo que proporciona un aumento de velocidad notable.
Hay varias opciones importantes de caché de proxy disponibles para autoinstalar o como 'Software como servicio'. (Estamos ignorando a los proveedores de alojamiento en la nube que suelen empaquetar todo lo que pueda necesitar en una pila web autónoma).
Las opciones populares de caché de proxy incluyen:
Las opciones de SaaS para el almacenamiento en caché generalmente se encuentran en el mundo de las Content Delivery Networks (CDN) que, en lugar de ubicar un caché entre un usuario y una pila web, brindan a los usuarios conjuntos de contenido en caché que están más cerca geográficamente de ellos. Es una diferencia sutil, pero una que para grandes sitios con audiencias globales puede marcar una diferencia significativa.
Barniz está disponible en todos los administradores de paquetes de Linux, como una imagen Docker y muchas otras opciones, lea el página de instalación del proyecto para más detalles.
Varnish almacena un archivo de configuración predeterminado en /usr/local/etc/varnish/default.vcl o /etc/varnish/default.vcl , escrito en VCL (Lenguaje de configuración de barniz). Este archivo de configuración se compila en un pequeño programa a través de un intérprete C para aumentar aún más la velocidad.
Dependiendo de cómo haya instalado Varnish, el archivo de configuración se verá más o menos así:
backend default {.host = "127.0.0.1";.port = "8000";}En su forma más simple, esto define el backend predeterminado utilizado por Varnish, que define el host y el puerto que debería escuchar e interceptar el contenido.
Una característica práctica de Varnish es verificar a intervalos predefinidos si un backend sigue siendo saludable. Se llama 'Back-end Polling' y se configura agregando una sección de sondeo en la declaración back-end:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Lo anterior es la configuración predeterminada proporcionada por Varnish y le dice que visite un .url particular cada .interval y que si por lo menos. Umbral fuera de .Window Probes , la url responde dentro de .timeout milisegundos, el back-end todavía se considera saludable. Una vez considerado 'no saludable', el contenido se sirve desde el caché durante un período predefinido.
Cubriremos los cambios específicos de la configuración de Varnish en cada opción de plataforma, por ahora echemos un vistazo a las opciones generales.
Puertos
Inicialmente, el puerto de su servidor web deberá cambiar de forma predeterminada. Por ejemplo, en la configuración de Apache Vhost, cambie el puerto a 81 o 8080.
Inicie el daemon de barniz con el comando barnizar o con un contenedor de servicios. El daemon tiene opciones de bandera, siendo la más común y útil:
Verificando que todo esté funcionando
Ejecute el comando varnishstat o visite isvarnishworking.com para verificar que tu servidor Varnish esté listo y para escuchar las solicitudes.
Lo que no debe caché
Hay ciertas partes de un sitio que no queremos almacenar en caché, por ejemplo, las páginas de administración. Podemos excluirlos creando una subrutina vcl_recv en el archivo default.vcl que contiene una instrucción if que define qué no se debe almacenar en caché:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Si está utilizando Barniz 4, las cosas son ligeramente diferentes, incluidos los valores de devolución. La función vcl_recv ahora devuelve un valor ahash en lugar de una búsqueda.
sub vcl_recv {...return(hash);}Aquí también es donde establecemos los sitios o subdominios que Varnish debe ignorar agregando un req.http.host ~ 'example.com' a la declaración if .
Galletas
De forma predeterminada, Varnish no almacenará en caché el contenido del servidor que establece las cookies. Del mismo modo, si el cliente envía una cookie, omitirá el barniz directamente al servidor.
Las cookies son utilizadas frecuentemente por los sitios para rastrear la actividad del usuario y almacenar valores específicos del usuario. En general, estas cookies solo son de interés para el código del lado del cliente y no son de interés para el backend o barniz. Podemos decirle a Varnish que ignore las cookies, excepto en áreas particulares del sitio:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Esta declaración if ignora las cookies a menos que estemos en el área de administración del sitio, donde el uso de cookies puede ser de mayor utilidad (a menos que realmente desee frustrar a los administradores del sitio).
Otras excepciones
Con una instalación predeterminada, Varnish tampoco almacena páginas protegidas por contraseña, solicitudes GET y HEAD.
Ahora veremos dos casos de uso perfectos para Barniz: Drupal y Magento. Ambos son sistemas altamente dinámicos que permiten a los usuarios no técnicos realizar una amplia variedad de tareas complejas. Esto puede llevar a cargas de páginas pesadas de consulta en la base de datos y los sitios ocupados se vuelven notablemente lentos. Las páginas típicas creadas con estos sistemas tendrán una mezcla de contenido actualizado con poca frecuencia y frecuencia.
Drupal tiene opciones de almacenamiento en caché predeterminadas que realizan funciones similares a Varnish, pero no proporciona la flexibilidad o los incrementos de velocidad requeridos por sitios más grandes o más complejos.
En la verdadera forma Drupal hay una módulo para manejar la integración de barniz para guardar parte de la configuración manual descrita arriba.
Instale el módulo y asegúrese de seguir las instrucciones de instalación incluidas en el archivo Léame del módulo.
Asegúrese de que el archivo / etc / default / barniz tenga configuradas las siguientes opciones de daemon (y que la sangría sea importante):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Asegúrese de que Apache y los hosts virtuales asociados estén escuchando en el puerto 8080, no en el 80. Reinicie ambos servicios después de realizar estos cambios.
Es posible que deba establecer una 'Clave de control de Barniz' en la página de configuración del módulo. Averigüe qué es esa clave con el comando cat / etc / barnish / secret y péguela en la página de configuración. Seleccione la versión de Barniz correcta, guarde la configuración y verá una serie de marcas verdes en la parte inferior de la página.
El módulo Varnish interactúa con la configuración de caché de Drupal por defecto, así que asegúrese de tenerla habilitada y configurada para su caso de uso.
Ejecute varnishstat desde la línea de comandos, comience a navegar por el sitio como un usuario anónimo y debería ver las estadísticas cambiando en el resultado del comando.
Una de las rutas que no queremos guardar en Drupal son las páginas de administración, podemos hacerlo con una sub-rutina vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Es posible que desee considerar no almacenar en caché las páginas de usuario, las páginas de actualización del sistema y otras páginas generadas por módulos altamente dinámicos, como la bandera que hace un uso extensivo de ajax para funcionar. Haga esto agregando otros parámetros req.url a la declaración if .
Una instalación predeterminada de Magento se envía con un sistema de almacenamiento en caché interno que almacena las versiones estáticas de los elementos del sitio en una carpeta especificada. La página Sistema -> Administración de caché proporciona una descripción general del estado actual de la caché y le permite borrar todas las cachés de componentes o individuales. Puede borrar archivos agregados de CSS y JS y archivos de imágenes generados automáticamente desde esta página.
La próxima versión 2 de Magento admitirá el almacenamiento en caché de Varnish de manera predeterminada, pero por ahora debemos usar complementos de terceros, recomiendo Módulo de trementina . Asegúrate de leer el archivo léame del proyecto como se observan algunos pasos de configuración adicionales, ignorarlos puede romper su sitio.
El módulo Turpentine es altamente configurable y realizará los cambios necesarios en los archivos vcl y en la configuración de Varnish por usted. Algunas opciones clave para establecer son:
El módulo de trementina se vincula con la memoria caché de Magento predeterminada, por lo que borrar los cachés en la página de caché de barniz borrará las cachés de barniz correspondientes.
Además de usar Varnish con cualquiera de los sistemas dinámicos anteriores, aquí hay algunos otros consejos diversos que ayudarán a la capacidad de caché de cualquier sitio.
Si está publicando el mismo contenido en diferentes contextos, debería usar la misma URL. Por ejemplo, no mezcle el uso de article.html , article.htm y el artículo , aunque su CMS puede permitirlo. Esto dará lugar a tres versiones diferentes en caché del mismo contenido.
Como vimos anteriormente, las cookies son difíciles de almacenar en caché y rara vez son tan necesarias como creemos. Intenta limitar su uso y número a las páginas dinámicas.
La carga de los activos del sitio puede ser una de las partes que más tiempo consume en la renderización de una página y hay consejos simples para reducir esta carga:
El uso de sprites de imagen de CSS para la iconografía en lugar de múltiples archivos pequeños genera menos tráfico de red.
Alojar localmente las bibliotecas de CSS y JavaScript significa menos tráfico de red y más control sobre las estrategias de almacenamiento en caché. Esto puede significar un aumento en los gastos generales de mantenimiento para mantener estos activos actualizados. Almacene estos activos en carpetas con nombres consistentes para que las referencias a ellos también sean consistentes.
Espero que esta introducción para acelerar sus sitios dinámicos con el almacenamiento en caché sea útil. La ganancia de rendimiento vale un período inicial de configuración, experimentación y ajuste. En esta era de breves períodos de atención e impaciencia, cualquier ganancia de velocidad que pueda sacar de su configuración marcará la diferencia para sus usuarios y competencia.
Foto principal, imagen de caché de red a través de Shutterstock.