Como 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.
Hay que recordar además que Facebook publicó su versión modificada de memcached, después de haber publicado parte de su código. También recordar que hace poco más de un mes que Facebook ha adquirido Friendfeed.
Más comentarios en Facebook publica Tornado, servidor web usado en FriendFeed en barrapunto
Mostrando entradas con la etiqueta Facebook. Mostrar todas las entradas
Mostrando entradas con la etiqueta Facebook. Mostrar todas las entradas
sábado, septiembre 12, 2009
sábado, diciembre 13, 2008
Facebook publica su versión modificada de memcached
[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 por aquí de memcached en Un vistazo al interior de memcached.
Actualización: Olvidé mencionar que habían toqueteado el kernel :/ JAM hace muy bien resumen de esos apaños
Parece relevante también comentar lo que dicen en High Scalability sobre el memcached de Facebook y las conclusiones que se pueden sacar:
La misma entrada y más comentarios en Facebook publica su versión modificada de memcached en barrapunto
Actualización: Olvidé mencionar que habían toqueteado el kernel :/ JAM hace muy bien resumen de esos apaños
Parece relevante también comentar lo que dicen en High Scalability sobre el memcached de Facebook y las conclusiones que se pueden sacar:
A summary of potential strategies:
- Profile everything. Problems are always specific. The understanding of the problem must be specific. The fix must be specific.
- Burn profiling into your regression tests. Detect when and where performance tanks as a regular part of your build.
- Use resources in proportion to what grows slowest. This requires multiplexing, but at least your resource usage is more predictable and bounded.
- Batch work. When you have the CPU do all the work you possibly can in the quantum or the whole system grinds to a halt in processing overhead.
- Do work and maintain resources per task. Otherwise locking for shared resources takes more and more time when there's less and less time to do the work that needs to be done.
- Change algorithms. Sometimes you simply need to do things differently. Tweaking will only get you so far.
La misma entrada y más comentarios en Facebook publica su versión modificada de memcached en barrapunto
Etiquetas:
cache,
caché,
escalabilidad,
Facebook,
memcache,
memcached,
programación,
rendimiento,
TCP,
UDP
Suscribirse a:
Entradas (Atom)
