performance - control - js no cache header

Obteniendo ETags correctos

Question

He estado leyendo un libro y tengo una pregunta en particular sobre el capítulo ETag. El autor dice que los ETags pueden dañar el rendimiento y que debe sintonizarlos o deshabilitarlos por completo.

Ya sé qué son ETags y entiendo los riesgos, pero ¿es tan difícil conseguir ETags, verdad?

Acabo de hacer una aplicación que envía un ETag cuyo valor es el hash MD5 del cuerpo de respuesta. Esta es una solución simple, fácil de lograr en muchos idiomas.

• ¿Está usando mal el hash MD5 del cuerpo de respuesta como ETag? Si es así, ¿por qué?

• ¿Por qué el autor (que obviamente me supera en muchos órdenes de magnitud) no propone una solución tan simple?

Esta última pregunta es difícil de responder a menos que seas el autor :), así que estoy tratando de encontrar los puntos débiles de usar un hash MD5 como un ETag.

Answer 1

Al no haber leído el libro, no puedo hablar sobre las preocupaciones precisas del autor.

Sin embargo, la generación de ETags debería ser tal que una ETag solo se genera una vez cuando una página ha cambiado. La generación de un hash MD5 de una página web le cuesta a los procesadores el poder y el tiempo en el servidor; si tiene muchos clientes conectados, podría comenzar a causar problemas de rendimiento.

Por lo tanto, necesita una buena técnica para generar ETags solo cuando sea necesario y almacenarlos en caché en el servidor hasta que cambie la página relacionada.

Answer 2

ETag es similar al encabezado Last-Modified. Es un mecanismo para determinar el cambio por parte del cliente.

Podría decirse que un ETag que SÓLO SUCEDE como la última fecha de modificación (es decir, el mismo texto) cumple con todos los criterios necesarios para un ETag. Simplemente necesita ser un valor único que represente el estado de un recurso. No es único en todo el dominio de recursos, simplemente dentro del recurso.

Ahora, técnicamente, un ETag tiene una resolución "infinita" en comparación con un encabezado Last-Modified. Last-Modified solo cambia con una granularidad de 1 segundo, mientras que un ETag puede ser sub segundo.

Puede implementar ETag y Last-Modified, o simplemente uno u otro (o ninguno, por supuesto). Si Last-Modified no es suficiente, entonces considere un ETag.

Tenga en cuenta que no establecería ETag para "cada" recurso. Básicamente, no lo configuraría para nada que no tenga expectativas de ser almacenado en caché (contenido dinámico notablemente). No tiene sentido en ese caso, solo trabajo desperdiciado.

Editar: veo tu edición y aclaro.

MD5 está bien. El único inconveniente es calcular MD5 todo el tiempo. Ejecutar MD5 en, digamos, un archivo PDF de 200K, es costoso. Ejecutar MD5 en un recurso que no tiene ninguna expectativa de ser almacenado en caché es simplemente un desperdicio (es decir, contenido dinámico).

El truco es simplemente que sea cual sea el mecanismo que uses, debería ser tan barato como lo es típicamente Last-Modified. Last-Modified es, de nuevo, típicamente, una propiedad del recurso y, por lo general, es de acceso muy económico.

ETags debe ser similarmente barato. Si está utilizando MD5, y puede almacenar en caché / almacenar la asociación entre el recurso y el hash MD5, entonces esa es una buena solución. Sin embargo, volver a calcular el MD5 cada vez que se necesita ETag es básicamente contrario a la idea de utilizar ETags para mejorar el rendimiento general del servidor.

Answer 3

Estamos usando etags para nuestro contenido dinámico en instela.

Nuestra estrategia está al final de la salida generando el hash md5 del contenido a enviar y si existe el encabezado if-none-match, comparamos el encabezado con el hash generado. Si los dos valores son los mismos, enviamos el código 304 e interrumpimos la solicitud sin devolver ningún contenido.

Es cierto que consumimos un poco de CPU para actualizar el contenido, pero finalmente estamos ahorrando mucho ancho de banda.

Tenemos una página principal de estilo de suministro de noticias de Facebook que tiene contenido diferente para cada usuario. Como el contenido del suministro de noticias cambia solo 3-4 veces por hora, las actualizaciones de la página principal son muy eficientes para el lado del cliente. En la era móvil, creo que es mejor gastar un poco más de tiempo de CPU que gastar ancho de banda. El ancho de banda es aún más caro que la CPU, y es una mejor experiencia para el cliente.

Answer 4

Creo que el perceived problem con ETAGS es probablemente que su navegador tenga que emitir y analizar una solicitud / respuesta (simple y pequeña) para cada recurso en su página para verificar si el valor de etag ha cambiado en el lado del servidor.

Personalmente, considero que estos pequeños viajes de ida y vuelta al servidor son aceptables para imágenes a menudo cambiantes, css, javascript (el servidor no necesita volver a enviar el contenido si el etag del navegador es actual) ya que el mecanismo hace que sea bastante fácil marcar contenido "actualizado".