Buscando más información sobre Varnish (sigo averiguando sobre el) he encontrado en un blog el siguiente artículo[0], que he encontrado no solo instructivo, sino ameno. Lo he traducido (lo mejor que he podido) para que también puedan disfrutarlo, pues hay muchos que no dominan el inglés y/o no tienen acceso a internet.
En fin, ahi les va, Saludos, Hugo [0] http://seankelly.tv/blog/blogentry.2007-03-02.4768602564 -------- Harto de Squid Me encanta el calamar, la paella cargada de calamar, e incluso el sushi de ika (calamar). Pero el acelerador HTTP y gestor de caché Squid [calamar] está fuera de mi menú a partir de ahora. ¡NO MAS SQUID, JAMÁS! Entre mi trabajo para la NASA y el Instituto Nacional del Cáncer, escribir artículos para Developer.com, y ayudar a los sitios de varios intereses locales, también he estado trabajando para una importante revista online para el teatro en casa. Nunca antes me había involucrado en sitios de alto volumen, de manera que ha sido una experiencia enormemente educacional. Verán, la buena gente de Alcoholics.com pensó que mis videos[1] eran bastante interesantes y me contactaron para que les asistiese en la transición de su viejo sistema gestor de contenidos a Plone[2]. Dado lo fácil que es desarrollar nuevas y convincentes aplicaciones web con Plone y su servidor de aplicaciones subyacente, Zope[3], para no mencionar el sumamente ágil lenguaje de programación Python[4], pensé que sería pan comido. Y lo fue, hasta que intentaron salir al aire con el nuevo sistema. En el Ploniverso parece que el proxy y acelerador HTTP Squid[5] se considera generalmente como una de las "mejores prácticas" cuando se trata de sitios de alto volumen. Tu CMS puede tardar mucho componiendo una página, pero una vez que todo está armado, no cambia tanto. Seguro, los pequeños "portlets" a los lados pueden actualizarse, pero el pollo del arroz con pollo aún es el mismo, de manera que cachear la página ya armada para que la consuma una audiencia hambrienta directamente de la cache al navegador es una buena idea. Y de no ser Squid, siempre está el /mod-proxy/ del Apache, o incluso una combinación de Squid y Apache. Al menos si crees en el conocimiento comunitario, y tienes la paciencia necesaria para lograr que todo funcione. La cual pensé que tenía. Eso fue hasta que el sitio intentó salir al aire, /múltiples veces, /con la instalación de Squid - sólo para descubrir que su confusa configuración e impenetrables archivos de log mostraron que casi no ofrecía beneficio alguno. Incluso después de que obtuvimos la ayuda de un experto[6] en Plone, Squid simplemente se rehusaba a jugar limpio. También se rehusó a hacer solicitudes round-robin a múltiples servidores Zope después de que el sitio decidió hacer algunas inversiones de envergadura en hardware. Ahora bien, generalmente soy una persona paciente, y muchos de mis colegas saben bien cuánto golpeo mi cabeza contra un archivo de configuración hasta lograr que algo funcione. No obstante, con Squid siento como si luchara literalmente con un leviatán gigante de las profundidades, un gigantesco calamar monstruoso emergido de las profundidades oceánicas para luchar conmigo, que me balanceo en vano en un minúsculo bote zarandeado por el fiero oleaje. Luché con el calamar. Y ganó. Mi cuerpo hinchado y maltrecho, cubierto de verdugones por las ventosas de la bestia, fue arrastrado hacia alguna costa perdida. Apenas capaz de respirar y moverme, me arrastré del vívido mar, para encontrar al mismo experto recomendando que ahora probara Varnish[7]. ¿Varnish? Nunca he oído hablar de él -- lo cual no dice mucho sobre los nombres de los paquetes de software libre, que han renunciado a mostrar siquiera la más leve de las sugerencias en relación a cual podría ser su funcionalidad. Considere: Siege [asedio] (un sistema de pruebas de regresión), Spring [primavera/resorte] (framework de aplicaciones web), Scarab [escarabajo] (rastreador de problemas), Cantus (etiquetador de archivos multimedia), Azureus (cliente P2P), Fink (framework de paquetes Mac), y así sucesivamente. Pero cualquier cosa debe ser mejor que el Squid. Y esto es exactamente lo que es Varnish. Y no solo esto, sino que está /años-luz/ delante del Squid. Ahora bien, Squid ciertamente intenta ser mucho más que un acelerador HTTP, que es lo que quería para este cliente, de modo que debo perdonarlo por esto. Excepto que al intentar ser tantas cosas (proxy saliente, proxy FTP, proxy transparente, distribuidor de carga, y proxy inverso) resultó realmente difícil que hiciera sencillamente la única tarea que necesitaba hacer. Squid también viene con un archivo de configuración que pesa cerca de 4000 líneas. De acuerdo, hay mucha documentación en ese archivo, pero es esencialmente una página de manual incrustada; quita todos los comentarios y son aún más de 250 líneas de configuración. Peor aún, tanto la última versión estable como la versión actualmente en desarrollo, 3.0, tenían buena documentación en línea. ¡Pero la versión estable actual, 2.6, /no la tiene/! ¿Se supone que con Squid uno debe o bien navegar por el filo cortante o contemplar el pasado? Aparentemente, ambos. Por ultimo, a pesar de mis pobres intentos con la configuración y las correcciones de los expertos, Squid es simplemente lento. Observemos por qué. Squid, cuando actúa como acelerador HTTP y proxy inverso, toma la petición de una página y busca si ya la tiene en la caché de memoria o de disco. Si no está en ninguna de estas ubicaciones, pedirá al sistema gestor de contenidos que componga la página, en cuyo punto la cacheará en la memoria con la esperanza optimista de que alguien más la solicitará pronto nuevamente. Después de todo, la memoria es rápida. Si después de un tiempo no hay otras peticiones de esta página, la escribirá al disco para el caso menos optimista de que posteriormente llegue alguna petición. Después de todo, el disco es más lento que la memoria. Tristemente, esta estrategia anula el propósito de la memoria virtual paginada bajo demanda que proporcionan los sistemas operativos modernos. Es tarea del sistema operativo abstraer la memoria de manera que una aplicación no tenga que preocuparse por ello. Squid, al preocuparse activamente por ello, arruina la capacidad del sistema de ofrecerle a la aplicación alguna ventaja. Tomemos el caso donde Squid tiene un objeto cacheado en memoria y el sistema operativo se percata antes que Squid de que la página de memoria no ha sido referenciada en un rato. El sistema operativo, transparentemente y sin conocimiento del Squid escribe la página al disco. Luego los temporizadores del Squid se disparan y decide escribir ese mismo objeto al disco. ¡Entonces obliga al sistema operativo a /volverlo/ a paginar en la memoria sólo para que el propio Squid pueda escribirlo /nuevamente/ en el disco! Los sistemas operativos modernos basados en Unix tienen la llamada de sistema /mmap/ que hace tales travesuras totalmente innecesarias. Disco o memoria, ¡todo es lo mismo en estos días! De hecho Varnish simplemente mapea un enorme archivo en la memoria y lo trata como caché. Administrarlo es tarea del S.O., cosa que hace muy bien, sea que uno esté en Linux, FreeBSD, u otro. La caché de disco del Squid consiste en cientos de archivos en docenas de directorios, obligando al subsistema a hacer docenas de vueltas de carnero para rastrear los inodes, las páginas de memoria y otros metadatos. La caché de Varnish es sólo un gran trozo de archivo que puedes preubicar con /dd,/ minimizando la fragmentación y aumentando la velocidad. Observemos qué mas hace Squid que resulta lento y contraproducente [el término original es intraducible]: Squid toma el archivo de configuración y lo utiliza para establecer todo tipo de condiciones en memoria, cuyo código debe analizar a fin de figurarse qué hacer. ¡Varnish en cuanto se ejecuta toma la configuración y la compila en código de máquina ejecutable! Squid loguea en archivos, ocasionando I/O de disco prácticamente todo el tiempo. Varnish escribe a un área de memoria compartida con round-robin. Ya había visto esta técnica una vez, cuando trabajaba para una compañía que hacía servidores de video digital de altas prestaciones. Tuvimos dos miembros del equipo del núcleo de FreeBSD trabajando allí, y utilizaron la misma técnica: el logueo era absolutamente vital para depurar aquel sistema, y sin embargo era más liviano que el aliento de un hada. Supongo que no por gusto el principal arquitecto de Varnish es también miembro del equipo del núcleo de FreeBSD: Poul-Henning Kamp. Este es definitivamente un software /ingenioso/. Utilice Varnish. /sbin/fsck SQUID! [1] http://seankelly.tv/videos/ [2] http://plone.org/ [3] http://zope.org/ [4] http://python.org/ [5] http://squid-cache.org/ [6] http://www.enfoldsystems.com/ [7] http://varnish-cache.org/ _______________________________________________ Cancelar suscripción https://listas.softwarelibre.cu/mailman/listinfo/linux-l Buscar en el archivo http://listas.softwarelibre.cu/buscar/linux-l
