Historias
Slashboxes
Comentarios
 

FaceBook publica su versión modificada de memcached

Entrada escrita por mig21 y editada por rvr el 14 de Diciembre 2008, 07:00h   Printer-friendly   Email story
desde el dept. escalando-el-monte-improbable
Vía reddit. Facebook acaba de publicar su versión de memcached, el sistema de cachés genéricas más usado en aplicaciones web, tras hacer modificaciones para afrontar sus necesidades de rendimiento y escalabilidad. Las modificaciones principales han sido entre otras la eliminación de un 'buffer' por conexión en favor de un 'pool', reducción de bloqueos innecesarios para un mejor rendimiento en máquinas 'multicore' y el uso intensivo de UDP. El resultado final ha sido la posibilidad de gestionar 200.000 peticiones UDP por segundo con una latencia media de 173 microsegundos. Han subido los cambios a GitHub: facebook-memcached y esperan que los cambios sean incorporados al memcached oficial. Curiosamente hemos hablado recientemente bastante de memcached en Barrapunto: Un vistazo al interior de memcached y Cómo afrontar el efecto /. usando memcached.

Historias relacionadas

[+] Un vistazo al interior de memcached 5 comentarios
Leo en El valle del Viento Helado un artículo acerca de la arquitectura interna de memcached. memcached es un sistema de cachés genéricas muy usado en aplicaciones web. En el artículo se repasa tanto la elección de libevent como sistema de gestión de eventos sobre descriptores de fichero, el uso de funciones de entrada/salida no bloqueantes y sobre todo una gestión de memoria basada en un slab allocator. Contiene además enlaces con más información sobre el tema aunque como siempre la información última está en el código fuente.
[+] Cómo afrontar el efecto /. usando memcached 19 comentarios
Resulta común que los sitios con pocas visitas si de repente le llegan muchas de golpe por el efecto Barrapunto, éstos no esten preparados y se produzca una degradación del servicio o incluso la caída del sitio. Para mitigar este efecto se puede usar el modulo mod_memcache_cache (en desarrollo) para usar una caché de contenido en memoria que se comparta entre todos los frontales web. De esta forma se puede superar "el bache" para luego concentrar los esfuerzos en mejorar el código de la aplicación web, que es quien realmente tiene todos los números de tener alguna deficiencia.
[+] Pregunta a /.: La identificación en línea 6 comentarios
Un pobrecito hablador nos cuenta: «Hace unos 10 días que se presentaron públicamente y fuera de beta dos de las varias formas de ver la identificación en línea por parte de Google y Facebook. Me refiero a Google Friend Connect y Facebook Connect. Desde mi punto de vista tienen mucho ganando a alternativas como OpenID. Me gustaría saber la opinión de los barrapunteros acerca de estas opciones, sobre el futuro y la viabilidad de las mismas, pues desde mi punto de vista creo que son unas opciones muy muy jugosas. A ser posible dejemos fuera de debate el hecho de que los datos pertenezcan a Facebook, o Google o la que sea, simplemente discutamos las posibilidades y capacidades de estos métodos de autentificación. ¡Saludos!» Error500 realizó una comparativa entre Google Friend Connect y FaceBook Connect, servicios en principio destinados a añadir funcionalidades de redes sociales a cualquier sitio web y por tanto no directamente comparables a OpenID.
[+] ciberderechos: Sobre la privacidad en Facebook 11 comentarios
unf escribe: «Yo soy de esos insensatos que se preocupa de la privacidad por Internet más bien poco. Pero por una entrada bastante estúpida de un blog que han enviado a menéame me he puesto a mirar la "configuración de privacidad" de mi perfil. He descubierto algo que sabía a medias: que estoy repartiendo multitud de información a todo el que la quiera, pero en una medida que desconocía. Veamos un par de puntos que no me han hecho especial gracia: por defecto, cualquier persona que se conecte a Facebook puede encontrar mucha información sobre ti sin ni siquiera tener una cuenta. Como es obvio esta información aparece tabulada de la misma forma para todo el mundo, así que es carnaza perfecta para bots». Recientemente, El País publicó un reportaje sobre la privacidad en las redes sociales.
[+] Software Libre: Facebook publica Tornado, servidor web usado en FriendFeed 15 comentarios
Cuentan en LWN: Facebook ha anunciado el lanzamiento de su servidor web Tornado bajo la licencia Apache. Tornado es un servidor Web no bloqueante escrito en Python, diseñado para gestionar miles de conexiones simultáneas, lo que lo hace ideal para servicios Web de "tiempo real". Tornado es la pieza central de la infraestructura de "tiempo real" de FriendFeed, que tienen previsto mantener activamente. Tornado es similar a "frameworks" Web ya existentes (Django, webapp de Google, web.py) pero se centra en la velocidad y en manejar grandes cantidades de tráfico simultáneo. El código se puede obtener de tornadoweb.org.Lo comentan también en reddit, Slashdot y Hacker News entre otros.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Obvio

    (Puntos:3, Interesante)
    por pobrecito hablador el Sábado, 13 Diciembre de 2008, 21:55h (#1108040)
    Han hecho una modificación importante a memcached y quieren que se incorpore al proyecto principal para que sean los de memcached los que se ocupen a partir de ahora de mantenerla.

    No creáis que lo hacen por amor al arte. Lo cual no quiere decir que sea algo malo, sino al contrario.
    • Re:Obvio de unf (Puntos:2) Sábado, 13 Diciembre de 2008, 23:16h
    • Re:Obvio

      (Puntos:4, Inspirado)
      por idcarlos (25596) el Domingo, 14 Diciembre de 2008, 17:42h (#1108163)
      Si no liberan código, mal y si lo hacen son unos interesados...
      Que añadan sus modificaciones a la rama oficial del proyecto es algo secundario (aunque interesante para Facebook).
      Esté o no en la rama oficial seguro que Facebook seguirá de cerca el desarrollo de memcached, si no corren el riesgo de que sus modificaciones no se actualicen/evolucionen correctamente.
      [ Padre ]
    • Re:Obvio de pobrecito hablador (Puntos:1) Domingo, 14 Diciembre de 2008, 20:53h
    • Re:Obvio de triturator (Puntos:2) Lunes, 15 Diciembre de 2008, 07:23h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • Con cambios importantes en el kernel

    (Puntos:1, Informativo)
    por pobrecito hablador el Sábado, 13 Diciembre de 2008, 22:59h (#1108050)
    No han conseguido ese rendimiento sólo con memcache
    • Re:Con cambios importantes en el kernel de JAM (Puntos:1) Domingo, 14 Diciembre de 2008, 15:15h
      • Re:Con cambios importantes en el kernel de JAM (Puntos:2) Domingo, 14 Diciembre de 2008, 20:24h
        • Re:Con cambios importantes en el kernel

          (Puntos:5, Informativo)
          por JAM (999) el Domingo, 14 Diciembre de 2008, 21:04h (#1108206)
          ( http://barrapunto.com/ )
          Ale ya lo leí. Interesante, de UDP no modifican nada a nivel de kernel, simplemente reimplementan su protocolo para que use un socket UDP por hilo en lugar de un socket compartido.

          Se pone interesante con lo de las interrupciones de las tarjetas de red. Comentan que todas las interrupciones de las tarjetas llegan a un sólo core y como tienen tantísimas eso puede saturarlo, así que lo solucionan implementando una operación de "polling" (hacer que los otros cores "pregunten" a las tarjetas si tienen algo pendiente en lugar de esperar que las propias tarjetas sean las que notifiquen) y haciendo que el kernel llame a ese polling desde el bucle "idle" (el que se ejecuta cuando no hay trabajo, algo que no creo que pase mucho en sus servidores) y cuando se entra en el código de red por ejemplo para envíar un paquete; en este segundo caso imagino que habrán implementado algún tipo de cola para almacenar las interrupciones. Esto lo veo un poco ñapa, lo ideal sería hacer un manejador de interrupciones muy ligero que le pasase el marrón a otro core aunque la interrupción la recibiese uno sólo; pero quizás en el caso de Facebook puede que ni así vaya bien, así que puede que sea una ñapa necesaria en casos extremos; sería interesante ponerla como opción de compilación.

          Sobre el netdevice comentan que la cola de paquetes "por envíar" que meten los drivers de las tarjetas y vacía la capa IP funciona "paquete a paquete", es decir, pone el cerrojo a la cola, quitan un paquete, quita el cerrojo y lo envía, pone otro cerrojo, quita otro y lo envía... ellos lo que comentan que han hecho es que la capa IP al poner el cerrojo saca varios paquetes de la cola, quita el cerrojo y luego envía ese conjunto de paquetes (en otra cola interna sin cerrojo, imagino.) Esto si que es probable que fuera una mejora general interesante para ser incorporada en el kernel normal.

          Con todo esto consiguen multiplicar el rendimiento de su protocolo basado en UDP por cuatro.

          No intente todo esto con Windows ;-)
          [ Padre ]
        • Re:Con cambios importantes en el kernel de JAM (Puntos:2) Domingo, 14 Diciembre de 2008, 21:11h
      • 1 respuesta por debajo de tu umbral de lectura actual.
  • Ortografía

    (Puntos:1)
    por Zudaka (41310) el Lunes, 15 Diciembre de 2008, 12:35h (#1108314)
    ( http://www.frikipedia.es/friki/bengatio )
    El nombre es Facebook, no FaceBook como dice el título en estos momentos. Curiosamente el texto del artículo tiene la ortografía correcta.
  • 1 respuesta por debajo de tu umbral de lectura actual.