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:

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

Un vistazo al interior de memcached

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.

La misma entrada y más comentarios en Un vistazo al interior de memcached en barrapunto

Enlaces varios (V)

Ración de enlaces que amenazaban con desbordar los marcados Keep New en bloglines, por si alguien les puede sacar utilidad:

• Chaotic Perspectives en Adding Simplicity. De como hay que renunciar a alguna de las letras de ACID si se quiere sistemas muy pero que muy escalables. Me ha recordado, por el tema a Transactionless de Martin Fowler, a Building a high volume app without a RDMS or Domain objects comentado en Thoughts on Scaling Without a Database y a como hacen otros, como bloglines o flickr para manejar grandes cantidades de datos. Ah y por contrastar y por controversia Getting Your Priorities Straight. Scalability and Performance are the Least of your Worries
• Una gran noticia que ha pasado casi desapercibida: GCC 4.2 ya soporta OpenMP. ¡Enhorabuena a los premiados!
• En thinking parallel acabaron con las entrevistas a los gurús de la programación paralela y postean una interesante lista de blogs y enlaces sobre programación paralela y similares que aún no he sido capaz de procesar
• Un artículo muy bonito de Matias Capeletto, el Camino de un ciclo. Describe con una sencillez envidiable la evolución de de C++, desde C hasta C++09, con sólo el ejemplo de un bucle. Actualización: vía lambda the ultimate me encuentro con un papel de Bjarne Stroustrup en el que repasa lo mismo, pero en 59 páginas. Por lo que cuentan toca además de temas técnicos temas políticos, así que debe estar bastante entretenido... Evolving a language in and for the real world: C++ 1991-2006 (pdf)
• De como en Electronic Arts se crearon su propia STL para cubrir sus necesidades Quién pudiera dedicarse a reinventar ruedas más bonitas :)

Enlaces Varios (V) en barrapunto

Twitter, RoR, escalabilidad y flames

Ha sido imposible escapar al contrahype: un desarrollador de twitter, el servicio webdospuntocero de moda (¿o ya no está de moda?, no sé, a mi que no me pregunten, que yo en estas cosas estoy muy démodé), Alex Payne, declaró que Ruby on Rails no escala, que tiene un cuello de botella en la base de datos (comentado en barrapunto en Entrevista con Alex Payne, uno de los desarrolladores de Twitter) y se desató el multiflame. Debido a la relevancia y al ruido conseguido por los fans de RoR parece que se les tenía ganas... El hecho es que se ha levantado una polvareda de bytes bastante importante, lo que en estos tiempos significa una conversación fragmentada de post cruzados en muchísimos blogs y alguna lista de correo, que aún quedan :)

Tengo que reconocer que me gustan los flames, sobretodo si no me tocan de cerca, porque en general y con un poco de suerte, de tanto ruido se puede extraer información interesante...

Aunque, debo confesar, esta vez me ha sorprendido que la onda expansiva ha llegado hasta la blogosfera hispana, cosa que no suele ser usual... Primero pues, los enlaces en castellano. Ah, seguro que me dejo algo, se admiten sugerencias de enlaces interesantes :)

• Ricardo Galli: Los problemas de Twitter (y la escalibilidad)
• Un muy reciente La polémica sobre la escalabilidad de Rails (tan reciente que lo ha escrito mientras yo redactaba esto y que es un buen resumen y además apunta posibles soluciones...) de Sergio Gil (porras), aunque ya dejó algún mensaje interesante en barrapunto: La escalabilidad de Rails
• rvr ya hizo referencia hace casi un año a un artículo, Does Rails Scale Down? que pone de manifiesto el posible peligro.
• "Los dolores de Ruby on Rails" en la lista de correo ror-es

Ahora en inglés. De David Heinemeier Hansson:

• Twitter trouble. Primera reacción de DHH (Parodiada en DHH translation con mucha acidez. Puro flame.)
• Scaling to multiple databases with Rails Solución rápida a la conexión a distintas bases de datos con rails

Ha habido respuesta de diversa índole, pero se pueden rastrear fácilmente. Solo voy a resaltar alguna que se va por las ramas, que son las que más me interesan ;)

• Is platform selection premature optimisation? ¿cuando se empieza a optimizar? Dice el dicho, comentado ahora mismo en la bitácora de fernand0, que Primero haz que funcione, segundo hazlo elegante y después hazlo que sea rápido Y estoy completamente de acuerdo, pero a twitter el tercer paso le vino demasiado rápido, me temo... O sea ¿cuando llega el momento de optimizar?
• Twitter and Rails brouhaha Sobre la conveniencia de evaluar lenguajes y frameworks separadamente
• Actualización: Me olvidé de poner uno interesante "Reddit: Language vs. Platform" en Coding Horror, en el que se recuerda el caso reddit con interesantes lecturas también...

Dice Juan Lupión en "sobre railes" que permanezcamos a la escucha. Desde luego, un flame es un flame ;)

Twitter, RoR, escalabilidad y flames en barrapunto