linux - Tux, barniz o calamar?
apache squid (11)
Necesitamos un acelerador de contenido web para que las imágenes estáticas se ubiquen frente a nuestros servidores web front-end de Apache
Nuestro anterior socio de hosting usó Tux con gran éxito y me gustó 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, leo en otros hilos 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?
Aclamaciones
Ian
ACTUALIZACIÓN: estamos probando Squid ahora. 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.
Como ya tiene apache para el contenido estático y dinámico, le recomiendo que vaya con Varnish.
De esta forma, puede usar su apache para entregar el contenido estático y usar barniz para almacenarlo 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.
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.
Es interesante que nadie mencionó Apache Traffic Server (anteriormente, Yahoo Traffic Server) http://trafficserver.apache.org/
Por favor, échale un vistazo, funciona muy bien.
Estamos a punto de desplegar un servidor 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.
Nadie menciona que Squid sigue la especificación HTTP al pie de la letra (o al menos lo intentan) mientras que Barn no lo hace. En mi opinión, esto significa que Varnish es más adecuado para el almacenamiento en caché de sitios individuales (mediante el ajuste exhaustivo de barniz) y Squid es mejor para el almacenamiento en caché de muchos sitios (cada uno tendrá que hacer que su contenido sea "cachable" según las especificaciones ).
Por lo que vale, recientemente configuré nginx como un proxy inverso frente a Apache en un servidor web de baja potencia de 6 años de antigüedad (ejecutando Fedora Core 2) que estaba bajo un leve ataque DDoS (10K req / seg). La carga de páginas fue rápida (<100 ms) y la carga del sistema se mantuvo baja con una utilización de CPU de alrededor del 20% 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.
Si está buscando insertar imágenes estáticas y muchas de ellas, primero le recomendamos que consulte algunos conceptos básicos.
Su aplicación debe asegurarse de que se pasen todos los encabezados correctos, Cache-Control y Expira 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.
Use un CDN (si está dentro de su presupuesto), esto acercará las imágenes a sus clientes (generalmente) y dará como resultado una mejor experiencia de usuario para ellos. Para que el CDN sea una inversión productiva, nuevamente 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 usar 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 lo siento.
Solo he usado calamar y no puedo comparar. 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.
Usamos Varnish en http://www.mangahigh.com y hemos podido escalar de aproximadamente 100 pre-barnices concurrentes a más de 560 post-barniz simultáneos (la carga del servidor permaneció en 0 en este momento, 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.
Varnish está destinado a ser mucho más rápido que Squid (nunca habías usado Squid, no puedo decir 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 grandes nombres también lo usan.
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.
@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. 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, eso 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 ...