Tux, barniz o calamar?

Question

Necesitamos un acelerador de contenido web para las imágenes estáticas que se sientan delante de nuestros servidores front-end web Apache

Nuestro socio de hosting anterior utilizado Tux con gran éxito y me gusta el hecho de que es parte de Red Hat Linux, que estamos usando, pero su última actualización fue en 2006 y parece que hay pocas posibilidades de desarrollo futuro. Nuestro ISP recomienda que usemos Squid en función de proxy de caché inverso.

¿Alguna idea entre Tux y Squid? La compatibilidad, la fiabilidad y el soporte futuro son tan importantes para nosotros como el rendimiento.

Además, he leído en otros temas aquí sobre Barniz; ¿Alguien tiene alguna experiencia real de Varnish en comparación con Squid y/o Tux, obtenida en entornos de mucho tráfico?

Saludos

Ian

UPDATE: Estamos probando ahora calamar. Usando ab para obtener la misma imagen 10,000 veces con una concurrencia de 100, tanto Apache por sí mismo como Squid/Apache grabaron rápidamente las solicitudes. Pero Squid hizo solo una solicitud a Apache para la imagen y luego les sirvió a todos de la memoria RAM, mientras que Apache solo tuvo que bifurcar a una gran cantidad de trabajadores para poder servir las imágenes. Parece que Squid funcionará bien para liberar a los trabajadores de Apache para que manejen páginas dinámicas.

Answer 1

Tanto Squid como nginx están específicamente diseñados para esto. nginx es particularmente fácil de configurar para una granja de servidores, y también puede ser una interfaz para FastCGI.

Answer 2

Solo he usado squid y no puedo compararlo. Utilizamos Squid para almacenar en caché todo un sitio en un servidor en los EE. UU. (Todos los datos se extraen de una máquina en Alemania). Fue muy fácil de configurar y funciona muy bien. He encontrado que la documentación es deficiente, a menos que ya sepas qué buscar.

Answer 3

Estamos a punto de desplegar un servidor de barniz 2.01 frente a una instalación de IIS 6. Las únicas advertencias que hemos tenido fue con nuestro SSL (ya que barn no puede manejar SSL). Así que también hemos instalado Nginx para manejar esas solicitudes.

En todas nuestras pruebas, hemos demostrado un aumento del 66% en la cantidad de tráfico que el sitio puede manejar.

Mi única queja es que el barniz no maneja bien las cookies, y la documentación aún está un poco dispersa.

Answer 4

En mi experiencia, el barniz es mucho más rápido que el calamar, pero igualmente importante es que es mucho menos negro que el calamar. Varnish le da acceso a registros muy detallados que son útiles cuando se resuelven problemas. Su lenguaje de configuración también es mucho más simple y mucho más potente que el de Calamar.

Answer 5

Utilizamos barniz sobre http://www.mangahigh.com y han sido capaces de escalar desde alrededor de 100 pre-barniz simultánea a más de 560 post-barniz concurrente (carga del servidor se mantuvo en 0 en este punto, por lo que hay mucho espacio para crecer!). La documentación para el barniz podría ser mejor, pero es bastante flexible una vez que te acostumbras.

El barniz está destinado a ser mucho más rápido que Squid (nunca habías usado Squid, no puedo decirlo con certeza) - y http://users.linpro.no/ingvar/varnish/stats-2009-05-19 muestra Twitter, Wikia, Hulu, perezhilton.com y un buen número de otros nombres importantes también usándolo

Answer 6

@Daniel, @MKUltra, para explicar los supuestos problemas de Varnish con las cookies, en realidad no existen.Es completamente normal no almacenar en caché una solicitud si devuelve una cookie con ella. Las cookies están destinadas principalmente a ser utilizadas para distinguir las diferentes preferencias de los usuarios, por lo que no creo que sea deseable almacenarlos en caché (¡especialmente si incluyen alguna información secreta, como una identificación de sesión o una contraseña!).

Si su servidor envía cookies con sus archivos .js e imágenes, es un problema en el lado del servidor, no en el de Varnish. Como hace referencia @Daniel (enlace proporcionado), puede forzar el almacenamiento en caché de estos archivos de todos modos, gracias al lenguaje/DSL realmente genial integrado en Varnish ...

Answer 7

Por lo que vale, recientemente configuré nginx como proxy inverso frente a Apache en un servidor web de baja potencia de 6 años de edad (que ejecuta Fedora Core 2) que estaba bajo un leve ataque DDoS (10K req/seg). La carga de páginas fue rápida (< 100ms) y la carga del sistema se mantuvo baja en alrededor del 20% de utilización de la CPU y muy poco consumo de memoria. El ataque duró 1 semana, y los visitantes no vieron efectos nocivos.

No está mal para más de medio millón de visitas por minuto sostenido. Solo asegúrese de iniciar sesión en/dev/null.

Answer 8

Si está buscando impulsar imágenes estáticas y muchas de ellas, le recomendamos que consulte primero algunos conceptos básicos.

Su aplicación debe garantizar que se pasen todos los encabezados correctos, Cache-Control y Expires por ejemplo. Esto debería dar como resultado que los navegadores de los clientes guarden en caché esas imágenes localmente y reduzcan el recuento de solicitudes.

Utilice un CDN (si está dentro de su presupuesto), esto acerca las imágenes a sus clientes (generalmente) y les proporcionará una mejor experiencia de usuario. Para que CDN sea una inversión productiva, deberá asegurarse de que todos los encabezados de almacenamiento en caché necesarios estén configurados correctamente, según el punto que hice en el párrafo anterior.

Después de todo eso, si todavía va a utilizar un proxy inverso, le recomiendo usar nginx en modo proxy, en Varnish y squid. Sí Varnish es rápido, y tan rápido como nginx, pero lo que estás queriendo hacer es realmente simple, Varnish entra en acción cuando quieres hacer un caché complejo, y ESI. Así que manténlo simple, estúpido. nginx hará su trabajo muy bien de hecho.

No tengo experiencia con Tux, así que no puedo comentar sobre lo siento.

Answer 9

Como ya tiene apache para el contenido estático y dinámico, le recomiendo que vaya con Varnish.

De esta manera puede usar su apache para entregar el contenido estático y usar barniz para guardarlo en caché. Varnish es muy flexible y le ofrece funciones de almacenamiento en caché y equilibrio de carga para hacer crecer su sitio web de la mejor manera.

Answer 10

Nadie menciona que Squid sigue el HTTP specification al pie de la letra (o al menos lo intentan) mientras que el barniz no lo hace. En mi opinión, esto significa que Varnish es más adecuado para el almacenamiento en caché de sitios individuales (ajustando ampliamente Varnish) y Squid es mejor para el almacenamiento en caché de muchos sitios (cada uno tendrá que hacer que su contenido sea "cachable" según spec).

Answer 11

Es interesante que nadie ha mencionado el tráfico del servidor Apache (anteriormente, Yahoo! tráfico del servidor) http://trafficserver.apache.org/

Por favor, tienen una mirada en ella, funciona muy bien.