Método de almacenamiento en caché alternativo para .htaccess. ¿Qué es la caché del navegador?

Obtenga más información sobre la caché BLOB de SharePoint, la caché de resultados de páginas y la caché de objetos.

Microsoft SharePoint Server 2010 se puede utilizar para crear diversas soluciones empresariales, desde portales de colaboración y archivos de registros hasta sitios de Internet. Cualquiera que sea la opción que elija, todavía le interesará la velocidad aceptable de la solución y, en este caso, comprender los principios del caché no será superfluo. La tarea principal del caché es garantizar una visualización más rápida de su portal a los usuarios finales. Pero cada moneda tiene dos caras, por lo que es necesario conocer las ventajas y desventajas de los diferentes tipos de caché.

En este artículo hablaremos de tres tipos de caché. Cada uno de ellos tiene una funcionalidad única para ayudar a que su servidor SharePoint crezca. Sin embargo, el caché no es una panacea; cada tipo de caché tiene sus propios compromisos y está lejos de ser un hecho que todos los tipos de caché se adapten a su escenario específico. Habilitar irreflexivamente el caché sin configuración correcta, lo más probable es que no conduzca a la mejora de rendimiento esperada.

Cualquier instalación de SharePoint Server consta de una instancia de Microsoft servidor SQL y al menos un servidor front-end web. Cuando los usuarios solicitan datos de SharePoint Server (por ejemplo, una página o documento), el servidor WFE recibe todos los datos necesarios de SQL y procesa la solicitud del usuario en función de ellos. Aunque esto garantiza que el usuario reciba la información más actualizada, esta situación genera un aumento del tráfico entre los servidores SQL y WFE, lo que a su vez afecta la velocidad del usuario final.

La caché de SharePoint Server se ejecuta en servidores front-end web, cada tipo de caché almacena una copia local de datos para, siempre que sea posible, atender a los clientes que utilizan la caché local, reduciendo la cantidad de datos transferidos desde el servidor SQL y la carga en su Procesadores propios.

Caché de BLOB.

La caché BLOB reduce la carga en SQL Server al almacenar el contenido de los archivos solicitados (principalmente partes de la página como JavaScript, CSS e imágenes) en los discos duros del servidor WFE. Cuando llega una nueva solicitud para un archivo que ya se ha almacenado en caché, la caché BLOB devuelve el archivo desde el disco en lugar de llamar a SQL Server.

Cuando desarrolla sitios web de SharePoint, existen varios lugares para almacenar el contenido de la página. Se pueden almacenar en sistema de archivos Servidor WFE (normalmente en el directorio _layouts) o en la biblioteca de SharePoint. Los archivos almacenados en el directorio _layouts se pueden leer desde el disco con bastante rapidez, pero si es necesario actualizar los archivos, el administrador debe cambiarlos en cada servidor WFE. Almacenar en una biblioteca de SharePoint tiene sus beneficios, de modo que no sólo los administradores de la granja pueden agregar y actualizar contenido, sino también los usuarios. Pero como todo lo que se almacena en la biblioteca está en SQL, y al extraer datos de SQL, la velocidad de obtención será menor. Entonces, al almacenar un archivo en SharePoint y usar un caché BLOB, el acceso al contenido se proporciona rápidamente y existe la posibilidad de una administración centralizada.

Pero también hay matices. Al agregar un nuevo archivo, realiza cinco veces más solicitudes al servidor SQL que en una situación con el caché BLOB deshabilitado. Estas llamadas adicionales recuperan información de permisos y otros metadatos para garantizar un funcionamiento seguro y confiable de la caché. Además, para evitar devolver contenido desactualizado al cliente, la caché BLOB eliminará los archivos de la caché si existe la posibilidad de que queden obsoletos. Naturalmente, después de esto el archivo se volverá a almacenar en caché, lo que afectará nuevamente a las llamadas a SQL.

Además de reducir los accesos al servidor SQL, la caché BLOB ayuda a reducir el tiempo de recarga de la página agregando encabezados de control a la respuesta HTTP para los archivos que sirve. Estos encabezados le indican al navegador del usuario que almacene estos archivos en la memoria caché del navegador. Cuando el navegador necesita uno de los archivos almacenados en caché, puede usar ese caché en lugar de ir a SharePoint Server. Esto conduce a una reducción significativa de las solicitudes HTTP y del tiempo de carga de la página.

Como ya se mencionó, el caché BLOB es especialmente útil cuando se almacenan en caché archivos multimedia de gran tamaño. El propio SharePoint está optimizado para trabajar con archivos pequeños. Puede manejar archivos más pequeños ArchivoReadChunkSize (100 KB) por solicitud y archivos de hasta 5 MB Tamaño de fragmento de archivo grande servido directamente desde SQL sin almacenamiento en búfer de disco con baja latencia. SharePoint almacena archivos de más de 5 MB en el disco del servidor WFE antes de devolverlos al usuario. Esto ahorra memoria, pero afecta el retraso de retorno. La caché BLOB puede reducir la latencia en esta situación. Cuando un archivo se almacena en caché en un BLOB, se devuelve tan rápido como si estuviera ubicado directamente en IIS.

Otra ventaja del caché BLOB es que le permite solicitar HTTP una parte de un archivo en lugar de solicitar el archivo completo. Por ejemplo, si el navegador solo necesita 1 MB de un archivo de 10 MB, puede realizar una solicitud y solo obtener 1 MB del caché. Cuando la caché BLOB está deshabilitada, SharePoint Server ignora dichas solicitudes (en la documentación en inglés se denominan solicitudes de rango HTTP) y devuelve el tamaño completo del archivo solicitado. Resulta que el caché BLOB aumenta el rendimiento de la red al minimizar la carga de la red.

Los reproductores multimedia del cliente serán los que más se beneficiarán de estas solicitudes de rango HTTP parcial. No importa si es Windows Media Player o Silverlight integrado en una página web, cuando mueve el control deslizante de video hacia adelante, el caché BLOB devolverá la parte requerida del archivo sin descargarlo por completo al cliente.

Arquitectura lógica y diseño.

La caché BLOB se ejecuta en todos los servidores WFE de la granja. Más precisamente, cada aplicación web y cada servidor virtual Tenemos nuestro propio caché BLOB. En este caso, un servidor virtual significa un sitio web IIS, pero en SharePoint Server, como regla general, cada aplicación web está asociada con un servidor virtual. Solo se puede ejecutar una instancia de caché BLOB en un servidor virtual a la vez. Esto significa que la caché BLOB no se puede utilizar con Web Garden. (Un jardín web es un grupo de aplicaciones que utiliza más de un proceso de solicitud para procesar solicitudes, más de un proceso w3wp.exe)

Si la aplicación web de SharePoint está extendida, y generalmente se extiende cuando se usa diferentes caminos autenticación para un portal, el segundo servidor virtual será manejado por su propia instancia de la caché BLOB. Por lo tanto, la caché BLOB se habilita para cada zona por separado. Por ejemplo, los datos solicitados por los usuarios internos se almacenan en caché, pero los datos solicitados por los usuarios externos (a través de una URL externa) no se almacenan en caché. Y aunque el contenido proporcionado a los usuarios externos e internos es idéntico, no se puede evitar tener dos instancias de caché.

Mecanismo de llenado de caché.

Los archivos con determinadas extensiones terminan en la caché BLOB cuando los usuarios los solicitan. La lista de extensiones es personalizable y se puede configurar para tareas específicas. Al extraer un archivo por primera vez desde la caché BLOB, los archivos pequeños pueden experimentar un retraso ligeramente mayor que en una extracción típica de SharePoint. Por otro lado, los archivos grandes se entregan más rápido debido a la optimización de la caché BLOB realizada. El archivo comienza a almacenarse en caché cuando se leen los primeros bytes de SQL Server. Los datos se devuelven al cliente, mientras que el resto continúa cargándose desde el servidor de la base de datos. Naturalmente, esto solo es cierto para la primera solicitud, ya que en las siguientes ocasiones los datos se entregan directamente desde la caché BLOB.

La caché BLOB puede manejar múltiples solicitudes para un solo archivo haciendo que los datos en la caché estén disponibles para todas las solicitudes. Esto ocurre incluso si el archivo aún no se ha recuperado por completo de SQL Server. Por ejemplo, se envía un vínculo a un informe en vídeo (500 MB) almacenado en SharePoint Server a correo electrónico empleados de la empresa. Si una gran cantidad de usuarios hacen clic en el enlace al mismo tiempo, con el caché deshabilitado, se realizarán muchas consultas a SQL Server. (uno para cada usuario) No es difícil adivinar cómo afectará esto al rendimiento. Con el caché habilitado, el video será recibido desde SQL una vez por cada servidor WFE, e incluso si no tiene tiempo para almacenarse en caché por completo, se utilizará para atender todas las solicitudes. La conclusión se sugiere por sí sola: el caché BLOB es necesario para servir archivos grandes en el servidor SharePoint.

Almacenamiento de datos y tamaño de caché en disco.

Dado que no debe editar ninguno de los archivos de caché manualmente, es útil comprender la estructura del almacenamiento de datos de caché BLOB en el disco, al menos desde un punto de vista teórico. La caché BLOB almacena sus archivos en el disco en una estructura que refleja la estructura de su portal. Por ejemplo, un archivo en el portal con la URL http://contoso/sites/publishing/documents/somefile.jpg se almacenará en el disco aproximadamente en la siguiente ruta c:\BlobCache\14\11111111\AB25499AF39572\sites\publishing \documentos\algún archivo-1238DEF8097AB .jpg. Esta ruta contiene partes aleatorias de la cadena, esto se hace para evitar la sobrescritura. versión antigua el archivo es más nuevo porque archivo antiguo en este momento todavía se puede utilizar. El nombre del host donde se encuentra el archivo se reemplaza en el vínculo con una cadena única, lo que evita conflictos de almacenamiento en caché entre dos archivos con direcciones como http://contoso/images/logo.jpg y http://northwinds/images/ logotipo.jpg.

en el quirófano sistema windows Hay un límite de 260 caracteres en la ruta del archivo. Dado que la caché BLOB agrega líneas únicas adicionales a las rutas de los archivos de la caché, es muy posible que al escribir un archivo en el disco se supere este límite. Por lo tanto, debes intentar evitar URL excesivamente largas en tu portal de SharePoint. Si sigue la recomendación, para el almacenamiento en caché de archivos normal no debe crear enlaces en el portal de más de 160 caracteres.

Además del espacio en disco, la caché BLOB requiere una pequeña cantidad de RAM para mantener un índice de archivos en el disco. Cada entrada de índice utiliza aproximadamente 800 bytes de memoria. En la mayoría de los casos, la memoria consumida por la caché BLOB será una pequeña porción de la memoria total consumida por SharePoint. Sin embargo, si la caché BLOB necesita almacenar cientos de miles de archivos, los requisitos de memoria deberán planificarse teniendo en cuenta lo anterior.

Persistencia de la caché de BLOB al reiniciar el grupo de aplicaciones.

La caché BLOB es la única caché persistente, lo que significa que sobrevivirá a los reinicios o cierres del grupo de aplicaciones IIS. Esto sucede porque el índice se escribe periódicamente en el disco. Un índice serializado tiene aproximadamente un tercio del tamaño de un índice en memoria. Como todas las operaciones de E/S, el tamaño del índice afecta la duración de la serialización y deserialización. Una caché BLOB muy grande contiene cientos de miles de elementos, por lo que el proceso de reescribirlos en el índice puede tardar más de un minuto. Mientras el proceso de serialización está en curso, no se pueden agregar nuevos elementos al caché. Esto significa que si se reciben solicitudes de archivos que aún no están en la caché, el cliente tendrá que esperar hasta que se complete el proceso de serialización. Si el índice es extremadamente grande (millones de objetos), el tiempo de serialización puede exceder el tiempo de espera de la solicitud del cliente y la solicitud se descartará.

Mecanismo de verificación de caché.

La caché BLOB limpia los archivos almacenados en caché obsoletos sondeando SharePoint Server en busca de cambios. El intervalo de sondeo predeterminado es de cinco segundos, pero este parámetro se puede configurar. De hecho, el archivo se elimina más tarde (este intervalo también es configurable), después de que se deshabiliten las sesiones HTTP. Los archivos obsoletos y eliminados del caché no se agregan al caché automáticamente; se agregarán la próxima vez que el usuario solicite el archivo. Cuando el contenido cambia en un sitio de SharePoint, la caché BLOB puede cambiar con bastante rapidez. La siguiente tabla muestra las operaciones de archivos y su impacto en la caché de BLOB.

El tamaño máximo de la caché BLOB también se ajusta para evitar desperdicios innecesarios. espacio libre en el disco. Cuando el tamaño total de los archivos en la caché excede los límites establecidos, la caché BLOB elimina los archivos menos utilizados hasta que el peso de los archivos almacenados en caché cae al 70% del tamaño permitido. Este proceso se llama compactación. La compactación es un proceso bastante “costoso” en términos de rendimiento, esto se debe al posible almacenamiento en caché repetido archivos eliminados. La ejecución periódica de la compactación le permite deshacerse de archivos "impopulares" y liberar espacio para los que se utilizan con más frecuencia. Si la compactación ocurre con frecuencia, esto solo indica una falta de espacio en caché; puede ver la frecuencia de esta operación usando el contador "Número total de compactaciones de caché" en el grupo Caché basado en disco de SharePoint. Proporcionar espacio adicional para la compactación frecuente es Buena decisión, en condiciones ideales, el tamaño de la caché debería ser suficiente para dar cabida a todas las consultas populares.

Otra forma de eliminar archivos almacenados en caché es restablecer el caché. Cuando se restablece el caché, se crea una nueva carpeta, pero el caché anterior permanece. Esto permite completar consultas existentes en la caché anterior. El caché antiguo se elimina más tarde después de un tiempo determinado. (intervalo configurable) La caché se puede restablecer por varias razones: si el índice no se puede deserializar correctamente al inicio, la política de usuario para la aplicación web ha cambiado, la base de datos de contenido no se puede leer. El caché también se puede borrar manualmente llamando a la función Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache() desde PowerShell.

Autenticación y caché BLOB.

La caché BLOB está optimizada para la devolución de archivos anónimos. Cuando se solicita un archivo accesible de forma anónima, la caché BLOB lo devuelve antes de intentar la autenticación.

Los beneficios de este principio de funcionamiento se pueden obtener en dos casos.

1. Se permite el acceso anónimo al sitio.

2. Los archivos solicitados con frecuencia se almacenan en bibliotecas que tienen la opción habilitada Permitir que todos vean elementos.

Al crear un portal basado en la plantilla del Portal de publicación, se crean dos bibliotecas con el conjunto de parámetros Permitir que todos vean elementos. Estas son las bibliotecas "Imágenes" e "Imágenes de la colección de sitios". En cualquier caso, incluso si no se utiliza el acceso anónimo, la caché BLOB funcionará, pero el servidor WFE tendrá que contactar con el servidor SQL para comprobar los permisos de los usuarios. (LCA)

Continuará….

MCT/MVP Ilya Rud

Basado en el documento "Descripción general de las cachés de SharePoint Server"

Si, después de actualizar la configuración, sus formularios flotan, el informe deja de funcionar y aparecen ventanas de error, lo más probable es que el problema se pueda resolver borrando el caché. Te contamos cómo.

¿Qué es el caché?

El programa 1C:Enterprise está creado de tal manera que durante su trabajo se esfuerza constantemente por optimizar la velocidad de las operaciones. Para ello, se crea un "caché" en la computadora del usuario, que almacena información de uso frecuente, por ejemplo: la ubicación y forma de las ventanas, datos de servicio del usuario, configuraciones de selección, fuentes, etc.

El almacenamiento en caché le permite reducir la cantidad de llamadas al servidor y, por lo tanto, . Este mecanismo ahorra tiempo, pero también plantea una serie de problemas.

Si, después de actualizar la configuración, sus formularios flotan, el informe deja de funcionar y aparecen ventanas de error, lo más probable es que el problema se pueda resolver borrando el caché.

¿Cómo borrar el caché?

Hay dos formas principales de borrar el caché.

1. Ejecutar la base de datos 1C usando el parámetro "/ClearCache"

Este método es muy sencillo. En la ventana de selección de la base de datos, seleccione aquel cuyo caché desea borrar. Haga clic en el botón "Editar".

En la última ventana Editar base de datos, configure el parámetro de inicio "/ClearCache". Haga clic en "Finalizar" e inicie la base de información.

Como resultado de los pasos anteriores, se borrará la caché de solicitudes cliente-servidor. Por lo tanto, si el problema estaba en la caché de metadatos local, este método de borrado de la caché no funcionará. Al utilizar este método, es importante comprender que la carpeta de archivos temporales se "desvinculará" de la base de datos, pero No será eliminado de su computadora.

2. Borrar el caché 1C manualmente

Para eliminar archivos de caché manualmente, necesita encontrar las carpetas donde está almacenado el caché. Para sistemas operativos Los archivos temporales de Win7 y superiores se almacenan en:

• C:\Usuarios\Nombre de usuario\AppData\Roaming\1C Y C:\Usuarios\Nombre de usuario\AppData\Local\1C en carpetas que comienzan con "1cv8".
• En Windows XP, en la carpeta del usuario en Configuración local\Datos de aplicación\1C\.
• Si la carpeta AppData no está visible, entonces necesita configurar la visibilidad de las carpetas ocultas.

La siguiente figura muestra cómo se ven los archivos de caché: carpetas con nombres largos y poco claros. En nuestro caso, solo hay un archivo.

Para borrar el caché, debe eliminar estas carpetas.

¡Importante! Puede eliminar carpetas solo cuando se completen los procesos de trabajo con 1C:Enterprise.

3. Borrar el caché en 1C en un servidor o en la PC del usuario usando scripts ya preparados

En Internet puede encontrar scripts ya preparados para limpiar archivos temporales 1C. El uso de dichos scripts puede tener consecuencias impredecibles, por lo que se recomienda únicamente para administradores de sistemas y personal de soporte técnico.

Este método ayudará a borrar el caché 1C tanto en el cliente como en el servidor. Para hacer esto necesitará acceso a las carpetas del servidor correspondientes.

4.Adicional

Si después de utilizar los métodos anteriores para borrar el caché se produce un error, por ejemplo " Formato de almacenamiento de datos no válido“Aún está guardado, se recomienda detenerlo y limpiar manualmente la carpeta reg_1541/SNCCNTX. Está ubicado en la computadora del servidor central 1C:Enterprise en el directorio<рабочий каталог кластера> / <идентификатор информационной базы>.

Por ejemplo:

Tenga cuidado, no todo lo que hay en esta carpeta se puede limpiar. Enumeraré lo que se puede limpiar:

• 1CV8Reg.lst – registro del clúster (almacena una lista de bases de datos registradas, servidores y procesos en funcionamiento, correspondencia entre el clúster y el administrador adicional, y una lista de administradores).
• srvribrg.lst: lista de clústeres (clústeres registrados y administradores de servidores centrales)
• 1cv8ftxt – datos de búsqueda de texto completo. Están ubicados en el servidor central 1c: directorio de trabajo del clúster - identificador de la base de datos
• 1Cv8Log – registro de registro de base de datos *.lgp y *.lgf.

Es importante tener en cuenta que después de borrar el caché, el inicio de 1C se ralentizará un poco.

Fotos, aprendimos que el almacenamiento en caché y RAM juegan un papel clave en la escalabilidad y el rendimiento del sitio.

El sitio puede almacenar datos para acelerar el procesamiento de solicitudes posteriores en cuatro niveles:

• cliente;
• red;
• servidor;
• nivel de aplicación.

Diferentes páginas de un sitio web suelen compartir los mismos recursos. El usuario deberá reutilizar recursos durante la navegación. Las imágenes, guiones y estilos se pueden almacenar en caché durante meses, y la página del documento en sí se puede almacenar en caché durante minutos en el navegador del cliente.

Caché a nivel de cliente

Los encabezados HTTP son responsables de determinar si la respuesta se puede almacenar en caché y de determinar cuánto tiempo se conservarán los datos. El siguiente ejemplo de encabezado Cache-control especifica que la respuesta se puede almacenar en caché durante 7 días. El navegador reenviará la solicitud de almacenamiento de datos si el período de almacenamiento expira o si el usuario actualiza deliberadamente la página.

Una solicitud y respuesta que se pueden almacenar en caché durante 604800 segundos.

La respuesta también puede incluir un encabezado Última modificación o Etag. Estos encabezados son necesarios para comprobar si los datos se pueden reutilizar. Un estado de respuesta 304 indica que el contenido no ha cambiado y no es necesario volver a cargarlo. Tenga en cuenta los encabezados emparejados Última modificación y Si se modifica desde entonces, así como las fechas a continuación:

Una respuesta con un encabezado "Última modificación" seguido de una solicitud que lo utiliza.

El encabezado Etag se usa con If-None-Match de manera similar para intercambiar códigos de respuesta al detectar cambios en el contenido, si los hubiera.

Un sitio con encabezados HTTP bien pensados ​​tendrá más éxito entre los usuarios. Además, el navegador ahorrará tiempo y ancho de banda.

Caché a nivel de red

Clientes que solicitan el mismo contenido del servidor proxy.

Varios clientes solicitando el mismo contenido al mismo tiempo.

Este mecanismo simple pero poderoso evita el desorden del lado de la aplicación cuando hay una gran cantidad de solicitudes cuando el contenido caduca.

La idea detrás de este último pero no menos importante enfoque es que un servidor proxy puede mejorar la tolerancia a fallos de la aplicación. Existen indicadores de directiva proxy_cache_use_stale para entregar contenido caducado cuando la aplicación devuelve un estado de error o cuando la comunicación entre el servidor proxy y la aplicación no funciona como se esperaba.

Otra consideración importante al utilizar almacenes de caché es la condición de carrera que se produce cuando diferentes instancias de una aplicación acceden a datos no almacenados en caché al mismo tiempo. La API de almacenamiento en caché de solicitudes de Rails incluye una propiedad race_condition_ttl para minimizar este efecto.

Anticipar las condiciones de carrera para cachés con múltiples instancias de aplicaciones es un desafío. La solución óptima en este caso es actualizar los datos de la caché fuera del hilo de la aplicación y utilizar los datos almacenados en la caché en la propia aplicación. En una arquitectura de microservicio, puede proteger la comunicación entre la aplicación y el servicio utilizando nginx, como se describe anteriormente.

Conclusión

Esperamos que este artículo le ayude a comprender y elegir la mejor estrategia para su aplicación. Los encabezados HTTP son lo más simple que puedes y debes configurar para optimizar el almacenamiento en caché de tu aplicación. Utilice también otras estrategias cuando experimente ciertos problemas de rendimiento, pero recuerde que la optimización prematura es la raíz de todos los problemas.

17/04/1999 Phil Keppeler

Se espera que los servidores de caché IP tengan una gran demanda en el mercado empresarial en 1999. A continuación veremos las últimas ofertas de los fabricantes. A diferencia del ancho de banda de las redes globales, la memoria se ha vuelto mucho más barata.

Se espera que los servidores de caché IP tengan una gran demanda en el mercado empresarial en 1999. A continuación veremos las últimas ofertas de los fabricantes.

A diferencia del ancho de banda de las redes globales, la memoria se ha vuelto mucho más barata. Según una investigación de IDC, el nivel general de precios de las redes globales seguirá siendo el mismo o, en el mejor de los casos, disminuirá ligeramente. Mientras tanto, el coste de la memoria disminuye anualmente entre un 31,4% y un 39,8%.

Teniendo en cuenta estos hechos, el almacenamiento en caché de IP se vuelve atractivo para optimizar la utilización del ancho de banda y mejorar la eficiencia de la red. Mantener los archivos a los que se accede con frecuencia más cerca de los usuarios finales reduce los requisitos de ancho de banda empresarial red global o conexiones a Internet y, como resultado, elimina o retrasa la necesidad de costosas actualizaciones. También mejora la productividad del usuario final porque los objetos se entregan a velocidades de LAN.

La comunidad de Internet conocía los beneficios del almacenamiento en caché mucho antes de que Internet se convirtiera en el fenómeno comercial que es hoy. Normalmente, los archivos de archivos para servicios de Internet como ftp, gopher y conferencias se duplicaban en todo el mundo para mantener los archivos populares lo más cerca posible de los usuarios. Con la llegada de HTTP, la duplicación se volvió ineficaz debido al gran volumen, la sensibilidad temporal y la naturaleza aleatoria del contenido solicitado.

Los servidores de caché IP son para HTTP lo que la duplicación fue para los protocolos de archivo. Todos los servidores de caché se basan esencialmente en los mismos principios: interceptan solicitudes de objetos del navegador al servidor web y almacenan los objetos recibidos del servidor en el disco duro antes de transferirlos al navegador. Por lo tanto, en solicitudes posteriores del mismo objeto desde otros navegadores, el servidor de caché devuelve una copia del objeto desde su memoria en lugar de pasar una solicitud al servidor web para obtener el objeto original. Idealmente, tener un servidor de caché que realice solicitudes de objetos debería ahorrar tiempo y ancho de banda. (Más Descripción detallada Las tecnologías de almacenamiento en caché se pueden encontrar en el artículo “El caché pequeño es caro” en LAN No. 3 de este año).

Bajo la presión tanto de los consumidores como de los proveedores de contenidos, los proveedores de Internet se han convertido en los principales usuarios del almacenamiento en caché de IP. Opciones de conectividad más rápidas, como la línea de abonado digital (DSL), IDSN y módems de cable, ofrecen la esperanza de que lo que alguna vez fue el eslabón más débil de la cadena de datos, era un módem telefónico estándar con una velocidad máxima de transferencia de datos de 56 Kbps./s. eliminado. A medida que las conexiones a Internet se aceleran, el volumen de objetos copiados aumentará proporcionalmente, lo que provocará un aumento del tráfico en la red troncal de Internet. Al mismo tiempo, los proveedores de contenidos están migrando a formatos de datos más complejos y de mayor volumen, como la transmisión de audio/vídeo y los subprogramas de Java.

Como resultado de este ataque de ambos lados, los proveedores de Internet se ven obligados a buscar más formas efectivas utilizando su infraestructura para satisfacer las necesidades de los usuarios. El almacenamiento en caché de IP fue y sigue siendo una parte importante de su solución.

Aunque muchos proveedores de Internet reconocen los beneficios del almacenamiento en caché de IP, las empresas aún tienen que implementar la tecnología a gran escala. Según un informe de Collaborative Research de febrero de 1998, alrededor del 80% de los proveedores de Internet en Estados Unidos han anunciado planes para implementar el almacenamiento en caché dentro de los próximos seis meses. Por otro lado, sólo el 56% de las empresas planeaba empezar a utilizar el almacenamiento en caché en el mismo periodo. Sin embargo, como predicen los expertos, en 1999 el almacenamiento en caché tendrá una gran demanda en el mercado corporativo. Según Collaborative Research, se espera que la inversión empresarial en tecnología de almacenamiento en caché supere rápidamente a la de los proveedores de Internet, pasando de 85 millones de dólares en 1998 a más de mil millones de dólares en 2000 (ver tabla).

Mercado mundial de productos de almacenamiento en caché en 1998-2002.
Segmento de mercado	1998	1999	2000	2001	2002
Usuarios corporativos	$85 millones	$421 millones	$1,113 millones	$2.108 millones	$3.157 millones
proveedores de internet	$103 millones	$214 millones	$376 millones	$481 millones	$576 millones
Otro	$19 millones	$63 millones	$149 millones	$259 millones	$373 millones
Total	$207 millones	$698 millones	$1.638 millones	$2.848 millones	$4.106 millones
Fuente: Investigación colaborativa, 1998.

Esta tendencia no ha pasado desapercibida para los fabricantes y están reorientando activamente sus productos hacia los clientes corporativos. Inicialmente producían productos de alta gama para proveedores de Internet, pero los fabricantes comenzaron a incluir ofertas en sus líneas de productos a un precio relativamente bajo y con un nivel de rendimiento suficiente para las empresas. Además, una docena de nuevos proveedores han anunciado o lanzado servidores de caché basados ​​en hardware estándar de la industria y software- por ejemplo servidores en la plataforma Intel con software gratuito de almacenamiento en caché Squid - con el objetivo de ofrecer productos lo más baratos posible.

¿INTERMEDIARIO COMO CACH?

Los primeros servidores de caché se implementaron generalmente sobre la base de servidores proxy. Como tales, actuaban como intermediarios de objetos para un grupo de usuarios, aceptaban todas las solicitudes y las transmitían al destino en Internet. Como punto de acceso común para todos los usuarios, los servidores proxy han demostrado ser extremadamente atractivos para implementar una variedad de servicios adicionales: filtrado de contenido, identificación de usuarios, registro de eventos y almacenamiento en caché de objetos. Junto con un firewall, el servidor proxy hizo posible crear una conexión segura a Internet.

Uno de los primeros intermediarios habilitados para caché fue el servidor de software Harvest Cache, que fue el resultado de un proyecto conjunto financiado en 1994-1996 por la Agencia de Proyectos de Investigación Avanzada (ARPA), la Fundación Nacional de Ciencias, NSF) y la NASA. Desde entonces, al menos una docena de productos se han comercializado como "intermediarios de almacenamiento en caché". En particular, Netscape Communications, Microsoft y Novell tienen servidores proxy con capacidad de caché que están estrechamente integrados con sus otras herramientas empresariales. Además del almacenamiento en caché, sus productos ofrecen una amplia variedad de funciones intermediarias, como autenticación de usuarios, filtrado de contenidos, análisis de virus, seguridad y registro de eventos. El Proxy de Microsoft se ejecuta en Windows NT 4.0; Servidor Proxy de Netscape: basado en la mayoría de las variedades de UNIX, así como en Windows NT; BorderManager FastCache de Novell: en IntranetWare, NetWare 4.11 y NetWare 5.

Otro intermediario de almacenamiento en caché comercial ampliamente utilizado es Squid, una extensión de Harvest Cache desarrollada por el Laboratorio Nacional de Investigación de Redes Avanzada (NLANR). Quizás porque surgió como producto de un esfuerzo colectivo en un entorno donde el software estandarizado y aceptado es bienvenido y ampliamente utilizado, Squid se ha establecido en el mercado de proveedores de Internet y continúa teniendo una base instalada relativamente sólida.

Las configuraciones con servidores proxy de caché tienen dos desventajas principales. Primero, debido a que el navegador de cada usuario debe configurarse para pasar por un intermediario, una falla del servidor hace que todos los usuarios pierdan su conexión a Internet. En segundo lugar, introducir información sobre el intermediario en la configuración del navegador de cada usuario puede resultar laborioso en las grandes empresas y, esencialmente, una tarea imposible para el operador de Internet.

Para evitar estos problemas en configuraciones de intermediario, puede implementar el almacenamiento en caché transparente en su red instalando un enrutador habilitado para políticas o un conmutador de capa 4 para reenviar el tráfico a un servidor de caché o un grupo de servidores. Estos dispositivos interceptan todo el tráfico HTTP en el puerto 80 y lo redirigen al caché. La caché se ejecuta Solicitudes HTTP y devuelve los objetos al navegador. Una solución de almacenamiento en caché verdaderamente transparente debe admitir la escalabilidad equilibrando la carga entre múltiples servidores de caché, así como la conmutación por error a servidores de respaldo si uno o todos los servidores de caché no están disponibles. Ejemplos de dispositivos de conmutación de Capa 4 incluyen ACEdirector de Alteon Networks y ServerIron de Foundry Networks.

El servidor de caché Infolibria de DynaCache adopta un enfoque diferente, proporcionando transparencia sin la necesidad de un conmutador o enrutador independiente. Esto se logra utilizando DynaLink Redirector (DLR), un conmutador de capa 4 dedicado que interactúa con DynaCache. El DLR, una parte integral de la estrategia de almacenamiento en caché de la empresa, reside en la red y envía sólo los errores de caché a Internet. Según la empresa, esta estrategia puede reducir la carga del enrutador en dos tercios.

SOFTWARE CONTRA HARDWARE

En 1997, en un informe titulado "Por qué es importante el almacenamiento en caché", Forrester Research predijo que los proveedores de servicios de Internet y las empresas migrarían de servidores de caché de software a dispositivos de almacenamiento en caché dedicados. Asimismo, Dataquest afirmó en un informe de julio de 1998 que los dispositivos dedicados dominarían el mercado de productos de almacenamiento en caché.

Por lo tanto, no sorprende que más de media docena de fabricantes lanzaran dispositivos de almacenamiento en caché en 1998. Afirman que sus productos ofrecen un mejor rendimiento que sus homólogos de software porque el sistema operativo y el servidor de caché están estrechamente integrados entre sí y optimizados para el almacenamiento en caché. También afirman que sus productos son más fáciles de instalar y configurar y proporcionan plataformas más seguras porque es menos probable que creen agujeros de seguridad debido a errores administrativos o de configuración. Normalmente, las cachés de software, como el proxy de almacenamiento en caché analizado anteriormente, se diseñan con un enfoque de proxy en mente, mientras que las cachés de hardware están diseñadas únicamente para admitir un almacenamiento en caché de alto rendimiento. A pesar de esto, muchos dispositivos de almacenamiento en caché se pueden utilizar en configuraciones de proxy.

Network Appliance fue uno de los primeros en ofrecer un dispositivo de almacenamiento en caché dedicado. Para ello, adaptó el software NetCache al producto de hardware. Network Appliance adquirió el software NetCache (y además adquirió a Peter Danzig, uno de los principales arquitectos del Proyecto Harvest) junto con una pequeña empresa nueva, Internet Middleware.

Otros dispositivos de almacenamiento en caché introducidos en 1998 incluyen Cache Engine de Cisco Systems, CacheFlow de CacheFlow y DynaCache de InfoLibria. Si bien no es estrictamente un dispositivo dedicado, Netra Proxy de Sun Microsystems viene preconfigurado en una computadora UltraSPARC II. Contiene el software de almacenamiento en caché de Sun y está optimizado para estas funciones.

Más recientemente, han aparecido en el mercado dispositivos de almacenamiento en caché relativamente económicos. Se basan en hardware y software estandarizados y son dispositivos de servidor preconfigurados diseñados para hacer que el almacenamiento en caché sea más simple y asequible. Este enfoque puede resultar atractivo para pequeñas empresas o incluso grandes corporaciones que desean aprovechar los beneficios del almacenamiento en caché de grupos de trabajo pero dudan debido al alto costo y la complejidad de las soluciones disponibles. El precio de estos productos ronda los 2.000 dólares, mientras que las soluciones mencionadas cuestan al menos 7.000 dólares.

Tres ejemplos de dispositivos de almacenamiento en caché de bajo costo son WebSpeed ​​​​de Packetstorm Technologies y CacheQube y CacheRaQ de Cobalt Networks. WebSpeed ​​​​se vende por entre $ 2100 y $ 7100, según el tamaño del caché. WebSpeed ​​utiliza procesadores Intel y un sistema operativo gratuito sistema linux, así como el software de almacenamiento en caché Squid. La empresa apuesta a que los clientes apreciarán un dispositivo preconfigurado de bajo coste que puedan instalar en sus redes con el mínimo esfuerzo. CacheQube de Cobalt Network y CacheRaQ montado en bastidor son escalables a través de la capacidad DRAM y Espacio del disco y creando un grupo de varios dispositivos. CacheQube cuesta $1899 y CacheRaQ cuesta $2299 o $2799 dependiendo de la configuración.

En un intento por contrarrestar las predicciones de los expertos de que los dispositivos de almacenamiento en caché dedicados dominarán el mercado, Inktomi lanzó Traffic Server, que la compañía posiciona como una solución de almacenamiento en caché de alto rendimiento dirigida principalmente a proveedores de servicios de Internet y grandes empresas. Por el contrario, otros cachés de software se centran tanto en funciones de mediación y protección como en funciones de almacenamiento en caché. A $30,000 por CPU, Traffic Server también tiene el precio de un producto de nivel de operador.

COMPATIBILIDAD Y NORMAS

El Protocolo de almacenamiento en caché de Internet (ICP), que se remonta a las primeras investigaciones sobre almacenamiento en caché en el Proyecto Harvest, define cómo múltiples servidores de caché IP pueden compartir información sobre la actualidad de los objetos web y cómo recuperan objetos de otros cachés (en lugar de recuperar objetos del original). Servidor web). Con ICP, los administradores del servidor pueden configurar la caché para consultar otros servidores de caché que también admitan ICP para ver si tienen la información más reciente sobre los objetos web. Por ejemplo, una caché local podría preguntarle a una caché ascendente si tiene una copia más reciente de un archivo y, si no la tiene, si ha verificado la antigüedad del archivo en el servidor de origen. Incluso si el servidor ascendente no tiene más nueva versión archivo, podría haber verificado recientemente que el archivo había sido modificado en el servidor de origen. Dependiendo del algoritmo de actualización, la caché local puede usar esta información para recuperar una versión más reciente del objeto del servidor de origen, o usar una copia local en su lugar (ver figura).

El sondeo de la caché ascendente introduce una latencia adicional debido al aumento de la distancia y el tiempo de transmisión; sin embargo, el ahorro de tiempo será bastante significativo en muchos casos, ya que la solicitud no tiene que viajar hasta el servidor con el objeto original. Además, proporcionar objetos desde servidores de comunicación ICP ubicados cerca del destinatario reducirá la carga en la red troncal de Internet, liberando ancho de banda para la comunidad de Internet en su conjunto. Casi todas las soluciones de almacenamiento en caché actuales son compatibles con ICP.

Similar a ICP, el Caching Array Routing Protocol (CARP) es un protocolo para compartir la carga de almacenamiento en caché entre una flota de servidores local. Fue desarrollado por Microsoft y presentado al World Wide Web Consortium (W3C) como propuesta de estándar de Internet. Además de Microsoft, alrededor de una docena de otros proveedores, incluidos Packetstorm Technologies y Sun, han anunciado soporte para CARP.

Para permitir que Cache Engine se comunique con sus enrutadores, Cisco desarrolló el Protocolo de comunicación de caché web (WCCP). Utilizando WCCP, un enrutador Cisco con soporte para iOS intercepta solicitudes HTTP provenientes de navegadores y las redirige a un servidor de caché o dispositivo dedicado. WCCP admite la escalabilidad al distribuir solicitudes entre múltiples servidores de caché según su disponibilidad.

En noviembre de 1998, Cisco comenzó a otorgar licencias de WCCP a otros fabricantes de productos de almacenamiento en caché. Inktomi y Network Appliance han anunciado planes para incluir soporte WCCP en futuras versiones de sus productos.

INDICADORES DE MERCADO

Aunque existe cierta controversia con respecto a las cifras, se espera que el mercado de productos de almacenamiento en caché de Internet crezca significativamente en los próximos cuatro años. Collaborative Research proyecta que el mercado crecerá de 206 millones de dólares en 1998 a más de 4 mil millones de dólares en 2002.

Teniendo en cuenta estas cifras, no sorprende que los principales fabricantes y desarrolladores de software y hardware estén intentando utilizar su posición para penetrar en el mercado del almacenamiento en caché. Por ejemplo, con una gran base instalada de sistemas operativos de servidor, Novell confía en una estrecha integración de BorderManager con sus otros productos para atraer la atención de los clientes corporativos.

Al igual que Novell, Microsoft y Sun compiten por el dominio en el mercado de servidores y software de Internet. Ambos tienen grandes bases instaladas de servidores web y posicionan sus productos (con el arsenal de capacidades intermediarias que los acompañan) como componentes esenciales para un entorno integrado de soporte de aplicaciones web. Con una gran base instalada de dispositivos de red, la estrecha integración de Cache Engine con otros componentes de red de Cisco puede ayudar a impulsar una adopción generalizada.

PRECIO LO QUE NECESITAS

Cuando decide implementar el almacenamiento en caché en su red, puede elegir entre productos que van desde los gratuitos hasta los que cuestan 100 000 dólares o más. En general, cuanto más caro es el producto, más potente es.

En el extremo inferior de la escala de precios, donde recientemente han dominado los servidores de caché de software, ahora se pueden encontrar alrededor de una docena de dispositivos de almacenamiento en caché. Usando producto gratis, como Squid, que está disponible tanto en formato fuente como precompilado, necesitará una computadora para instalarlo. Para evitar gastos innecesarios, puede reutilizar el equipo existente para realizar tareas de almacenamiento en caché.

Netscape, Microsoft y Novell ofrecen potentes servidores de caché de software con una amplia gama de funciones de mediación. Sus productos cuestan alrededor de $1000 por CPU. Al igual que con Squid, el costo total de la solución se puede reducir utilizando el hardware existente. De lo contrario, el costo de compra del equipo deberá incluirse en la parte de gastos.

Phil Keppeler es desarrollador web en una empresa de diseño y programación. Se le puede contactar en: [correo electrónico protegido].

Productos revisados

microsoft Comunicaciones Netscape Laboratorio Nacional de Investigación Avanzada en Red Redes Alteon Director de ACE http://ircache.nlanr.net/Cache/FAQ/ircache-faq-9.html . Brian D. Davidson, Ph.D. de la Universidad de Rutgers, mantiene una página de información sobre recursos de almacenamiento en caché en su servidor http://www.cs.rutgers.edu/~davison/Web-caching/. Contiene novedades sobre el almacenamiento en caché, una lista y tabla de intermediarios de almacenamiento en caché, una bibliografía, etc. Si desea obtener más información sobre el Proyecto Harvest, hay enlaces relevantes a resultados de investigaciones, transcripciones de reuniones y preguntas frecuentes disponibles en: http://www.harvest.transarc.com . CacheNow es una campaña en curso para promover el almacenamiento en caché a gran escala para abordar la escasez de ancho de banda y superar las limitaciones de la infraestructura de Internet. La información al respecto está disponible en http://vancouver-Webpages.com/CacheNow/ .

• Traducción

Una presentación bastante detallada e interesante de material sobre el caché y su uso. Parte 2 .

Del traductor: informe errores tipográficos e inexactitudes en un mensaje personal. Gracias.

Un caché web reside entre uno o más servidores web y un cliente o varios clientes, y monitorea las solicitudes entrantes mientras almacena copias de las respuestas: páginas HTML, imágenes y archivos (conocidos colectivamente como representación(representaciones); aprox. traductor - permítanme usar la palabra "contenido" - en mi opinión, no duele tanto el oído), por propias necesidades. Luego, si llega otra solicitud con una URL similar, el caché puede usar la respuesta previamente almacenada en lugar de volver a preguntar al servidor.

Hay dos razones principales por las que se utiliza la caché web:

1. Tiempo de espera reducido- dado que los datos solicitados se toman del caché (que se encuentra "más cerca" del cliente), se necesita menos tiempo para recibir y mostrar el contenido en el lado del cliente. Esto hace que la Web sea más receptiva.

2. Rechazar tráfico de red - la reutilización de contenidos reduce la cantidad de datos transferidos al cliente. Esto, a su vez, ahorra dinero si el cliente paga por el tráfico y mantiene los requisitos de ancho de banda más bajos y más flexibles.

Tipos de cachés web

Caché de navegador

Si examina la ventana de configuración de cualquier navegador web moderno (por ejemplo, explorador de Internet, Safari o Mozilla), probablemente notarás una opción de configuración de caché. Esta opción le permite seleccionar un área disco duro en su computadora para almacenar contenido visto anteriormente. La caché del navegador funciona según reglas bastante simples. Simplemente verifica si los datos están "actualizados", generalmente una vez por sesión (es decir, una vez en la sesión actual del navegador).

Este caché es especialmente útil cuando el usuario presiona el botón Atrás o hace clic en un enlace para ver la página que estaba viendo. Además, si utiliza las mismas imágenes de navegación en su sitio, se recuperarán de la memoria caché del navegador casi instantáneamente.

Caché de proxy

El caché de proxy funciona según un principio similar, pero a una escala mucho mayor. Los servidores proxy sirven a cientos o miles de usuarios; Las grandes corporaciones y los proveedores de servicios de Internet a menudo los configuran en sus firewalls o los utilizan como dispositivos individuales(intermediarios).

Dado que los proxies no son parte del cliente ni del servidor de origen, pero aún están frente a la red, las solicitudes deben reenviarse a ellos de alguna manera. Una forma es utilizar la configuración de su navegador para indicarle manualmente con qué proxy contactar; Otra forma es utilizar un proxy de interceptación. En este caso, los proxies procesan las solicitudes web que les envía la red sin que el cliente necesite configurarlas o incluso conocer su existencia.

Los cachés proxy son una especie de caché compartido: en lugar de servir a una persona, funcionan con un número grande usuarios y, por lo tanto, son muy buenos para reducir la latencia y el tráfico de red. Principalmente porque el contenido popular se solicita muchas veces.

Caché de puerta de enlace

También conocidas como “cachés de proxy inverso” o “cachés sustitutos”, las puertas de enlace también son intermediarias, pero en lugar de ser utilizadas por los administradores de sistemas para ahorrar ancho de banda, suelen ser utilizadas por los webmasters para hacer que sus sitios sean más escalables, confiables y eficientes.

Las solicitudes se pueden reenviar a las puertas de enlace mediante varios métodos, pero normalmente se utiliza algún tipo de equilibrador de carga.

Las redes de entrega de contenido (CDN) distribuyen puertas de enlace a través de Internet (o parte de ella) y ofrecen contenido almacenado en caché a los sitios web interesados. Speedera y Akamai son ejemplos de CDN.

Este tutorial se centra principalmente en los cachés y servidores proxy del navegador, pero parte de la información también es relevante para aquellos interesados ​​en las puertas de enlace.

¿Por qué debería usarlo?

El almacenamiento en caché es una de las tecnologías más incomprendidas en Internet. Los webmasters, en particular, temen perder el control de su sitio porque los servidores proxy pueden “ocultar” a sus usuarios, lo que dificulta el seguimiento del tráfico.

Desafortunadamente para ellos (los webmasters), incluso si el caché web no existiera, hay demasiadas variables en Internet para garantizar que los propietarios de sitios puedan obtener una imagen precisa de cómo los usuarios interactúan con el sitio. Si esto es un gran problema para usted, esta guía le enseñará cómo obtener las estadísticas que necesita sin que su sitio "odie el caché".

Otro problema es que la caché puede almacenar contenido desactualizado o caducado.

Por otro lado, si diseñas tu sitio web de manera responsable, un caché puede ayudarte con más carga rapida y mantener la carga en el servidor y la conexión a Internet dentro de los límites aceptables. La diferencia puede ser dramática: un sitio sin caché puede tardar unos segundos en cargarse; mientras que los beneficios del uso del almacenamiento en caché pueden hacer que parezca instantáneo. Los usuarios apreciarán el rápido tiempo de carga del sitio y podrán visitarlo con más frecuencia.

Piénselo de esta manera: muchas grandes empresas de Internet gastan millones de dólares en instalar granjas de servidores en todo el mundo para replicar contenido con el fin de que el acceso a los datos sea lo más rápido posible para sus usuarios. El caché hace lo mismo por usted y está mucho más cerca del usuario final.

Las CDN, desde esta perspectiva, son un desarrollo interesante porque, a diferencia de muchos cachés proxy, sus puertas de enlace están alineadas con los intereses del sitio web que se almacena en caché. Sin embargo, incluso cuando utilice una CDN, debe considerar que habrá un proxy y un almacenamiento en caché posterior en el navegador.

En resumen, se utilizarán servidores proxy y caché del navegador, le guste o no. Recuerde, si no configura su sitio para el almacenamiento en caché correctamente, utilizará la configuración de caché predeterminada.

Cómo funciona el caché web

Todos los tipos de cachés tienen un conjunto específico de reglas que utilizan para determinar cuándo tomar contenido del caché si está disponible. Algunas de estas reglas las establecen los protocolos (HTTP 1.0/HTTP 1.1), otras las establecen los administradores de caché (usuarios del navegador o administradores de proxy).

En términos generales, estos son los más reglas generales(No te preocupes si no entiendes los detalles, se los explicaremos a continuación):

1. Si los encabezados de respuesta le dicen al caché que no los guarde, no los guardará.
2. Si la solicitud está autorizada o es segura (es decir, HTTPS), no se almacenará en caché.
3. El contenido almacenado en caché se considera "nuevo" (es decir, se puede enviar al cliente sin verificarlo desde el servidor de origen) si:
   • Tiene una hora de vencimiento u otro encabezado que controla la vida útil y aún no ha expirado.
   • Si el caché verificó recientemente el contenido y fue modificado hace bastante tiempo.
   El contenido nuevo se toma directamente del caché, sin verificarlo desde el servidor.
4. Si el contenido no está actualizado, se le pedirá al servidor de origen que lo valide o le indique al caché si la copia existente todavía está actualizada.
5. En determinadas circunstancias (por ejemplo, cuando está fuera de línea), la memoria caché puede conservar respuestas obsoletas sin consultar con el servidor de origen.

Si la respuesta no tiene un validador (ETag o encabezado Última modificación) y no contiene ninguna información de actualización explícita, el contenido generalmente (pero no siempre) se considerará no almacenable en caché.

Frescura(frescura) y validación(validación) son las formas más importantes en las que opera la caché sobre el contenido. El contenido nuevo estará disponible instantáneamente desde el caché; El contenido válido evitará el reenvío de todos los paquetes si no se ha modificado.