Facebook & Memcached

Facebook

Facebook

Hace tiempo que tengo ganas de meterme a investigar un poco sobre memcached. Todavía no he tenido mucho tiempo, pero el otro día se estuvo hablando bastante del tema porque Facebook, uno de los mayores usuarios de memcached, estuvo haciendo algunas modificaciones a nivel performance y publicó el código, con el objetivo de que sus cambios sean agregados al trunk de memcached.

Originalmente la nota la vi en Barrapunto, pero luego estuve leyendo el artículo publicado por Paul Saab en Facebook. Como dice allí, Facebook tiene más de 800 servidores con más de 28 TB de memoria dedicada a memcached.

La arquitectura de Facebook es algo que me resulta sumamente intrigante (no he leído mucho al respecto), pero es uno de los sitios desarrollados en PHP de mayor tráfico últimamente. Quienes tengan alguna idea del funcionamiento de PHP, sabrán que si bien tiene un excelente rendimiento, en soluciones a gran escala tiene algunas complicaciones, porque realmente no está pensado para funcionar en el entorno de un application server. Sin embargo, con los avances de la web 2.0, el cloud computing, etc. se están encontrando nuevas formas de encarar los problemas que resultan bastante interesantes. De todas formas, y en mi total desconocimiento de la arquitectura de Facebook, me da escalofríos pensar en tener 800 servidores dedicados solamente a memcached. Sobre todo con el pésimo funcionamiento de Facebook. Cualquier usuario de Facebook habrá experimentado de primera mano lo mal que funciona. Fuera de la pésima calidad de las aplicaciones de terceros, y de las peligrosas formas que tiene Facebook de compartir información privada con terceros, el sitio realmente anda mal. A menudo se encuentran bugs que es inconcebible que lleguen a producción. Los servidores de contenido estático deben estar colapsadísimos, porque 2 de cada 3 veces que intento ver fotos de mis amigos, las fotos no cargan y mi browser se queda esperando información de static.facebook.com.

Más allá de todas mis críticas, sigue siendo un sistema muy popular y me parece interesante que hagan contribuciones al mundo del open source. El artículo de Saab es interesante, porque da cuenta de ciertos descubrimientos que hicieron en la forma en que el kernel de Linux maneja las conexiones de red cuando dispone de múltiples cores, y cambios interesantes a nivel interno del funcionamiento de memcached. Estos cambios, que fueron publicados independientemente hasta que memcached acepte incluirlos en el trunk, lograron aumentar en 50,000 los requests UDP por segundo que estaban pudiendo manejar.

En cuanto tenga un poco más de tiempo trataré de ponerme a investigar un poco sobre memcached, su arquitectura, instalación, configuración, etc. y escribiré algo al respecto. Mientras tanto dejo este otro artículo que da un pantallazo general sobre su arquitectura y varios links interesantes.

Comentar

3 Comentarios.

  1. La verdad que da azco lo mal que anda facebook, y saber que tiene tantos servidores da a sospechar que el problema es la arquitectura, y el codigo debe ser una cagada, nose si es buena publicidad para Memcache

  2. Sí, da para sospechar eso la verdad.
    Pero bueno, las cosas que hicieron para memcached están copadas. Por lo menos desde ese lado creo que vale la pena.

Comentar


[ Ctrl + Enter ]

Trackbacks y Pingbacks: