Buenas,
en la empresa tenemos una instancia de Amazon de las grandes y nos lleva el sitio sobrada.
El problema es que lanzamos boletines y a lo largo de la semana solemos tener un par de día con un pico bastante fuerte. Para solventarlo hemos decidido, como primera medida de choque, poner Varnish.
El caso es que lo monté y lo configuré, pero, pese a que el servidor ahora responde mucho mejor a los picos, creo que me cachea poco, me gustaría que cacheara un poco mas para quitarle aun mayor parte al Apache.
Para que os hagáis una idea, esto es lo que arroja el varnishstat tras un día de funcionamiento en pleno pico:
Como podéis ver está cacheando sólo un 10%
Destacar que en pruebas anteriores arrancaba el Varnis con 1G de disco en el varnish_storage.bin y tenía muchos «nukes» así que le he puesto 6G y parece perfecto.
Para no floodear el foro, si alguien tiene interés tengo el default.vcl que uso en http://paste.jabbim.cz/5316
Como veréis en el fichero, estoy cacheando totalmente varias views que son las mas visitadas. Por lo que debería cachear la mitad del trafico del sitio, no sólo un 10% :-(
¿Alguna idea?
Comments
Varios problemas
Asumiendo que utilizáis Drupal 7 o PressFlow (ya que si no hay que cambiar el planteamiento de partida)...
Lo habitual con una buena configuración es que Varnish se haga cargo de un 80 a un 90% de las peticiones. A primera vista:
Podéis intentar tracear el problema añadiendo a vuestro VCL:
//SB IT MEDIA NO PARA PRODUCCION, basado en: http://www.stewsnooze.com/content/what-stopping-varnish-and-drupal-press...sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Varnish-Cache = "HIT";
}
else {
set resp.http.X-Varnish-Cache = "MISS";
set resp.http.X-Varnish-Cookie = req.http.Cookie;
}
}
Deberíais tratar también los errores y la codificación (http://varnish-cache.org/wiki/FAQ/Compression)
Espero que la información os sea de ayuda, si necesitáis un análisis más en profundidad quizá os interese contactar con mi empresa (perdón por el spam) o buscar algún especialista en Varnish.
Salu2
una cosa
Se me olvidó decir que usamos Drupal 6, no 7 ni PressFlow .
La versión de varnish que usamos es 2.1
No se si esto cambia mucho tus recomendaciones.
Por otro lado, comentando tus consejos, creo que lo de no cerrar los pipe nos interesa; ya que tenemos un formulario de compra en varios pasos (el form va por POST) y creo que no nos interesa cachear nada de este proceso, por lo que entiendo que no cerrar las conexiones pipe nos conviene mas. Ojo, que esto es lo que entiendo yo, igual estoy equivocado :)
En cualquier caso, gracias por tu comentario
Drupal 6
Precisamente por eso puse en negrita al comienzo de mi comentario, por que cambian las cosas si es un Drupal 6 "tal cual".
Casi todos los usos que verás documentados en Internet del cocktail Drupal+Varnish se basan en tener un drupal que no genere cookies de sesión para los usuarios anónimos, esto es importante porque en la mayoría de los casos se opta por guardar las peticiones hash-eadas por la cookie (como en vuestro VCL).
A mi entender (de nuevo harían falta más análisis in-situ), lo que os está sucediendo (tomando el ejemplo de una imagen ya guardada en caché de Varnish, sin cookie por la linea
remove beresp.http.Set-Cookie;):sub vcl_hash), como no los encuentra los obtiene del backend y vuelve a guardarlos en caché sin cookie.Y esto asumiendo que el resto de posibles cookies del dominio sean filtradas de forma apropiada en la linea
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+)=[^;]*", "");Yo desde luego como mínimo haría un unset de la cookie en el
vcl_recvpara las peticiones de imágenes (salvo que tengáis imágenes solo visibles para registrados o para ciertos roles).En cuanto al pipe, creo que no has entendido bien el enlace que te puse... el problema no es hacer pipe de una petición, sino que subsiguientes peticiones continuarán saltando a Varnish (y adolecerán de posible falta de cabeceras como X-Forwarded-For). Deberíais incorporar algo del estilo a:
sub vcl_pipe {set req.http.connection = "close";
}
Con eso se garantiza que, cuando el backend conteste, la conexión será cerrada y cualquier nueva petición deberá volver a pasar por toda el proceso de filtrado (en caso contrario se queda una rendija abierta por la que cabe un elefante).
Eso si de verdad necesitáis devolver por pipe en lugar de por pass, cosa que yo solo he hecho en casos muy puntuales donde buscábamos que PHP tratase las cabeceras HTTP pedidas por el cliente
Por último (y como recomendación general), visto el uso que le queréis dar a Varnish... yo optaría por:
Espero, esta vez sí, haberte sido de más ayuda.
Salu2
me queda mucho mas claro :)
ahora creo que si he entendido!
muchas cosas (como lo del pipe) las tenía preconcebidas exactamente al revés :D
vamos a seguir tus indicaciones y ya comentaré el resultado.
lo de servir las imágenes estáticamente con nginx era algo que ya barruntábamos,
pero lamentablemente no tenemos ahora aquí a nadie de sistemas. en fin, se hará lo que se pueda.
de nuevo, gracias por el cable :)
-Leandro
Cuesta hacerse
Con Varnish no puedes dar nada por sentado :(... tienes que leerte toda la documentación y luego probar empíricamente que se comporta como esperas.
Espero que simplemente con el unset de la cookie ganareis bastante en % de hits... con los posibles problemas de purgado de caché que van indisolublemente asociados.
Servir estáticamente con Nginx contenido teniendo Varnish ya operativo... lo veo complicar el sistema sin obtener beneficio, con la configuración que os sugiero Varnish serviría las imágenes casi en cualquier caso.
En cuanto a lo de gente de sistemas... últimamente los sysadmins somos el patito feo de la profesión, todo es cloud y lentejuelas en el país de la gominola y nadie necesita entender como interactuan las partes.
Suerte y si necesitas alguna orientación más no dudes en pedirla!