Solución de problemas de elementos de caché en la versión 2.0 o posterior de ARR

Se aplica a: Internet Information Services

Información general

En este tutorial, puede aprender a realizar un seguimiento de una solicitud a medida que pasa a través de ARR y se envía a un servidor de nivel siguiente y examina la información que se puede adquirir para determinar dónde se envió la solicitud y desde dónde se ha servido.

Herramientas usadas en este solucionador de problemas

• Asistente de ARR
• Seguimiento de solicitudes con error (FREB)
• Advanced Logging de IIS
• Monitor de red

Descripción de la arquitectura de la granja

El primer paso es comprender la arquitectura del entorno, incluido lo siguiente.

• Topología de la granja de ARR (cuántos servidores, cómo se configura el enrutamiento, otros dispositivos)
• Reglas de reescritura de direcciones URL en su lugar

En este tutorial, puede usar la siguiente configuración para realizar un seguimiento de una solicitud.

Configuración de caché de disco

El siguiente fragmento de código muestra una unidad local con un tamaño máximo de 100 GB configurado.

<diskCache> 
<driveLocation path="E:\temp$\arrcache" maxUsage="100" />            
</diskCache>

Reglas de control de caché global

Esta regla se define como caché durante 60 minutos cuando no existe ninguna directiva de control de caché.

<rule name="ARR_CacheControl_b5aec65d-6327-407f-a28c-b34e48c5cda2" enabled="true" patternSyntax="Wildcard"> 
     <match url="*" />     
       <serverVariables>        
         <set name="ARR_CACHE_CONTROL_OVERRIDE" value="0,max-age=3600" />         
       </serverVariables>
</rule>

Creación de un plan de recopilación de datos

Esta sección le guiará a través del flujo de aciertos y errores de caché a medida que transitan a través de ARR e identificará las herramientas o registros que puede usar para investigar las solicitudes. En los pasos siguientes se describe el flujo de solicitud para el contenido que no se ha almacenado previamente en caché mediante la configuración proporcionada como referencia y las herramientas que se usan en cada paso.

• El contenido solicitado no se encuentra localmente (ni en memoria ni en disco en el nodo secundario).

  • Registros de FREB
  • Registro integrado de IIS
  • Monitor de red

• La solicitud se reenvía al siguiente nodo de caché de nivel (nodo primario).

  • Registros de FREB
  • Módulo de registro avanzado de IIS
  • Registro integrado de IIS
  • Monitor de red

• El contenido solicitado no se encuentra en el siguiente nodo de caché de nivel (ni en memoria ni en disco). Repita el punto 2 tantas veces como corresponda en función de la jerarquía de caché.

• La solicitud se reenvía al servidor de origen.

  • Registros de FREB
  • Registro integrado de IIS
  • Monitor de red

Recopilación de los datos

El contenido solicitado no se encuentra localmente (ni en memoria ni en disco)

Aquí puede identificar una acierto o error de caché en los registros de IIS o en los registros freb. Los registros de FREB proporcionan detalles adicionales, como dónde se enruta la solicitud, lo que es importante si hay varios servidores de nivel descendente.

Entrada de registro de IIS: encontrará las siguientes entradas en el campo cs-uri-query que identifica la memoria caché Hit o Miss y el GUID de la solicitud, que se puede usar para identificar la solicitud en servidores de nivel descendente.

X-ARR-CACHE-HIT=0

0 =  Cache miss, 1 = Cache hit

X-ARR-LOG-ID=62a3161c-b4f5-408e-9ce7-55d25c018aea

Guid identifying this request. This can be used to track as the request is passed to Parent nodes.

Entrada de registro freb: la entrada ARR_DISK_CACHE_GET_FAILEDencuentra la falta de caché.

Identifique el servidor al que se enruta la solicitud. Observe la solicitud que se envía al servidor W2K8WEBSERVER2, que será el siguiente servidor de nivel para la revisión de datos.

Los siguientes encabezados se agregan a la solicitud de reenvío. Si algunos nombres son diferentes de los nombres predeterminados, como X-Forwarded-For, X-ARR-ClientCerty X-ARR-LOG-ID, los nombres se han personalizado en la configuración del proxy de granja de servidores.

La solicitud se reenvía al siguiente nodo de caché de nivel (nodo primario)

En el paso anterior, había identificado este servidor como W2K8WEBSERVER2. En este paso, puede examinar los siguientes datos en este servidor. Hay varios puntos de datos que se pueden usar. Con X-ARR-LOG-ID, puede identificar si la solicitud alcanzó este servidor.

Registros freb: la solicitud se puede identificar mediante el X-ARR-LOG-ID enviado desde el nodo secundario. fe9d20da-a571-4451-8ef3-0e7faf1a463a se identificó en el paso anterior.

Advanced Logging de IIS Módulo: mediante el registro avanzado, puede agregar campos de registro personalizados basados en los encabezados X-Forwarded-For yX-ARR-LOG-ID, a continuación, usar el filtrado para registrar solo cuando estos encabezados estén presentes.

#Software: IIS Advanced Logging Module
#Version: 1.0
#Start-Date: 2009-10-16 18:42:51.494
#Filter: ((ARRLogID isPresent ) || (xforward isPresent ))
#Fields:  date time cs-uri-stem cs-uri-query s-contentpath sc-status s-computername cs(Referer) sc-win32-status sc-bytes cs-bytes X-ARR-LOG-ID X-Forwarded-For

2009-10-16 18:51:29.983 /iisstart.htm - "C:\inetpub\wwwroot\iisstart.htm" 200 "W2K8WEBSERVER2" - 0 1680 219 "fe9d20da-a571-4451-8ef3-0e7faf1a463a" "127.0.0.1:62489"

Network Monitor : use el seguimiento para identificar y X-ARR-LOG-ID X-Forwarded-For si desea realizar un seguimiento de una solicitud determinada.

Asistente de ARR: este módulo agrega el X-Forwarded-For encabezado al C-IP campo y el X-ARR-LOG-ID encabezado al cs-uri-query campo de los registros de IIS predeterminados.

Repita los pasos 1 y 2 para varios niveles de caché.

Si el nodo W2K8WEBSERVER2 primario del servidor está configurado con las características de ARR y almacenamiento en caché, es posible que tenga que comprobar IISLOGS o FREB para ver si se produjo una acierto o error de caché y decidir dónde continuar según el estado de entrada de esa caché.

La solicitud se reenvía al servidor de origen

Este paso se puede tratar como una solicitud HTTPS normal y se puede realizar un seguimiento con las siguientes herramientas:

• Monitor de red: captura seguimientos en el servidor de origen para comprobar la recepción de la solicitud.
• Registros de IIS: comprueba los registros de IIS en busca de códigos de respuesta HTTP para el contenido que está trazando.
• Registros freb de IIS: si la solicitud se encontró en el seguimiento de red y el código de respuesta HTTP no era 200, es posible que quiera volver a usar FREB para solucionar el problema.

Solución de problemas de errores de caché

Comprobación de encabezados de control de caché

Compruebe los encabezados cache-Control recibidos del cliente. Esto se puede hacer junto con la comprobación de las reglas de control de caché, ya que los encabezados se pueden configurar para invalidar los encabezados.

Revisión de las reglas de control de caché en ARR

Compruebe las reglas de control de caché en ARR para comprobar si el almacenamiento en caché de ARR está habilitado.

Comprobación de la configuración de HTTP.SYS

Para obtener más información sobre por qué el contenido no se almacena en caché HTTP.sys en el kernel, consulte Instancias en las que HTTP.sys no almacena en caché el contenido.

Errores de caché de disco

ARR registra eventos en el registro de eventos de la aplicación cuando se producen errores de disco y marca el disco como incorrecto.

Log Name: Application 
Source: Application Request Routing 
Date: 11/2/2009 5:26:59 PM 
Event ID: 1006 
Task Category: None 
Level: Warning 
Keywords: Classic 
User: N/A 
Computer: 
Description: Drive with path '\?\E:\temp$\arrcache\' is being marked unhealthy. The data contains the error code. 
Event Xml: 

Más información

• El contenido de las razones no se almacena en caché HTTP.sys en el kernel
• Monitor de red