Barniz versus otros proxys inversos

Estoy trabajando con una organización que ha implementado Varnish como un proxy inverso de almacenamiento en caché para todo su tráfico web. Su tráfico se compone de muchos sitios web dinámicos generados por los clientes, con la colección habitual de activos estáticos colgando a un lado.

Si bien estoy tratando de que me guste el barniz (creo que tiene una arquitectura bastante buena, en principio), tengo algunos problemas para administrarlo y solucionar problemas a medida que surgen, por lo que me pregunto si realmente es la opción correcta. He usado squid en el pasado como proxy inverso, pero no en el mismo tipo de rol, por lo que no tengo una base clara para la comparación.

Mi pregunta está dirigida a personas que han implementado barniz en producción o lo han evaluado seriamente con respecto a las alternativas: ¿se quedó con el barniz o terminó utilizando otro proxy inverso? ¿Cuáles fueron sus puntos clave para quedarse con él o cambiar, y si usó algo más, qué terminó usando?

Bueno, estoy ejecutando Varnish en mis servidores web, principalmente por razones de rendimiento, aunque sus características de equilibrio de carga también son útiles.

Mi caso de uso es el almacenamiento en caché frente a sitios web basados ​​en Django , y hace maravillas por el rendimiento de carga de la página. Puedo servir la mayoría de las páginas directamente desde el caché y manejar una avalancha de visitantes con pocos problemas.

La razón por la que elegí Varnish fue principalmente rendimiento / escalabilidad. Los puntos principales:

• Barniz permite que el kernel administre la memoria virtual, donde Squid intenta mantener el disco y las memorias caché separadas, puede hacer que el kernel y Squid se peleen un poco sobre lo que se debe paginar en el disco.
• Varnish usa VCL, su propio lenguaje de configuración específico de dominio, que se compila en código de máquina a través de C. Ese es un beneficio de rendimiento muy real si tiene más que un poco de lógica en su configuración: eliminación de encabezado condicional, etc.

En mi experiencia, Varnish funciona un poco mejor que Squid en la mayoría de los casos, y mucho mejor en picos de tráfico. Por otro lado, configurar Varnish correctamente requerirá un poco de rastreo de la lista de correo, ya que no hay tanta documentación lista para usar para su caso de uso específico que fluye por la red como hay para Squid, principalmente debido a que Varnish es un proyecto bastante joven en comparación.

Pasé mucho tiempo tratando de hacer que Varnish 1.x fuera estable en el hardware linux / dell estándar de bog, siempre se colgaría de una manera extraña y su perro guardián lo reiniciaría. Lo cual estaba bien, excepto por el caché ganado con esfuerzo que no se conservaba en ningún otro lugar ...

Dicho esto, ¿realmente estás usando la herramienta adecuada para el trabajo? Si desea un proxy inverso que almacene en caché los resultados de la solicitud (suponiendo que proporcione encabezados de caché de buena calidad), el barniz es una buena opción. Esperemos que sea más estable en la versión 2.0

Sin embargo, si está ejecutando un sitio * onRails y desea equilibrar la carga en varios servidores de fondo, entonces HAProxy o Nginx pueden ser el camino a seguir. Si no necesita ninguna lógica de URL complicada (redireccionamientos, coincidencias de expresiones regulares para reescribir URL antiguas, etc.), entonces HAProxy se ajustará a la factura. Si necesitas algo más capaz, entonces prueba nginx.