1. Alto rendimiento y
escalabilidad
en plataformas Rails
Daniel Blanco Luis Bosque Fernando Blat
daniel.blanco@the-cocktail.com luis.bosque@the-cocktail.com blat@lacoctelera.com

2. ¿Pero esto podemos
hacerlo con Rails?

3. YES, WE CAN!
Foto: Peter Yang para Rolling Stone

4. ¿Cómo?

5. • Logs
Monitorización! • Gráficas

6. Logs
• Repositorio común de logs (Data mining)
• syslog-ng
• Generación de Informes
• production_log_analyzer
• SlowQueries

7. Análisis de gráficas
• Identificación de patrones de
comportamiento
• Reconocer síntomas

8. Crisis? What Crisis?

9. Reconociendo Síntomas
• Carga Elevada

10. Reconociendo Síntomas
• Elevado número de conexiones

11. Reconociendo Síntomas
• Slow Queries

12. Reconociendo Síntomas
• IOstat

13. Reconociendo Síntomas
• Uso intensivo de CPU

14. Reconociendo Síntomas
• Swap

15. Capa Web

16. Capa Web
• Primero fue Lightp(httpd) con FastCGI
• Luego Apache + Mongrel
• El módulo mod_proxy_balancer de apache no hace
balanceo inteligente: round-robin
• Aparece HAProxy
• Entre Apache y Mongrels
• Distribuye las requests en base a las encoladas por los
mongrels

17. • fair_proxy_balancer
• Se mantiene en memoria el nivel de
ocupación de los backends
• Balanceo inteligente

18. Capa Web
• Alta disponibilidad entre servidores web
• Failover
Virtual IP

19. Capa Web
• Para aprovechar la máquina:
• Varios Dominios
• Instancias Virtuales
• Importante: Configuración del servidor web
para entrega de estáticos

20. Capa de
Aplicación

21. Compartiendo Estáticos
• Almacenamiento en red
• SAN / NAS
• S3

22. Caché, Caché, Caché!!!!!

23. Capa de Datos

24. Capa de Datos
• Máquinas dedicadas
• Esquemas Maestro/Esclavo
• Tablas InnoDB:
• Evitar Bloqueos
• Busquedas:
• Eliminar FULL TEXT KEYS
• Indexado con Sphinx
• Importante: Ajuste parámetros de configuración

25. Capa de Datos
• Replicación MySQL no es suficiente
• Failover manual
• Cluster MySQL
• Muy escalable, pero configuración compleja y procesos
manuales
• MySQL Proxy
• Replicación DRBD + Replicación MySQL
• Configuración sencilla. Failover automático. Escalable (salvo
aplicaciones con muchas consultas de escritura)

26. Capa de Datos
• Escalado
Virtual IP
Sencillo Texto
• Failover
Automático Activo Pasivo
• Balanceo de
Consultas
Esclavos

27. Entonces, podemos
tener alta redundancia
para la base de datos?

28. Web
Mongrel Cluster Mongrel Cluster Mongrel Cluster
App
+ + +
Virtual IP
Activo Pasivo Datos
Esclavos

29. Infraestructura

30. • Memcached
• Virtualización

31. Memcached
• Sistema de almacenamiento de objetos en
memoria de forma distribuida.
• Fundamental para escalar:
• Sesiones
• Fragmentos
• Consultas lentas
• NGINX + Memcached

32. Query Memcached
• almacenar resultado de una consulta a base de
datos en Memcached
• cada tabla tiene un número de versión y dicha
versión se añade a la query y se genera un MD5
como clave de Memcached
• expirar ese número de versión al ejecutar
cualquier query que no sea un SELECT

33. Virtualización
• Mayor aprovechamieno de los recursos de
hardware.
• Fácil migración en caso de fallo de una
instancia.
• Arranque bajo demanda
• Redundancia y tolerancia a fallos hardware si
la instancia se almacena en red

34. Amazon S3
• Servidores Europa vs USA
• MD5 en nombre de fichero o ETAG para
cachear sin tiempo de expiracion.
• http://lcp.s3.amazonaws.com/blat%2Ff
%2F5e3d6c54c094b0cfe15d3021dc17fe1e

35. Amazon EC2
• Máquinas bajo demanda
• Gestión remota con Elastic Cloud y gema
Amazon EC2

36. EC2: evitando regenerar
imágenes
• Todo está en modo RO, excepto /usr/local,
que es un repositorio de GIT
• enlaces simbólicos donde haga falta
• al arrancar la máquina hace un git pull y se
ejecuta un script
• una rama por feature, y merges de ramas
para combinar features

37. Merb
• Comunicación por HTTP y claves para
asegurar la autenticidad de los datos.
• No cargamos ningún modelo de
ActiveRecord para evitar inconsistencias
(DRY!!) y el monothreading

38. Rompiendo
convenciones

39. Sistemas de colas
• Evitar ralentizar la respuesta al usuario:
Importante: cuidado con observers,
sweepers, envíos de email, notificaciones
remotas...
• Flickr Engineers Do It Offline
• Algunos sistemas:
• Delayed Jobs
• Starling
• ActiveMQ + Ruby Stomp

40. Datos en memoria
• Carga anticipada de datos
• Base de datos + buffer de datos (Memcached):
• inserción de datos en memoria
• datos más frecuentes en memoria

41. Renderizado en segundo
plano
• el renderizado es una de las tareas más pesadas,
superado el cuello de la base de datos
• Erubis: implementación en C puro de ERB con
algunas características interesantes: caché,
preprocesado, fácil de extender, sintaxis 100%
compatible, rápido
• Renderizar en segundo plano y guardar en caché
• Combinar este renderizado con la carga de datos
anticipada

42. Paginación
• Sólo interesan los primeros resultados
• Evitamos mostrar el total exacto de páginas
• Precargamos la página actual y las N
siguientes
• Cuando estamos en la N - 1 cargamos la N
+ 1 y las siguientes

43. Recursos, referencias y
bla, bla ,bla...

44. • Erubis: http://www.kuwata-lab.com/erubis/
• Flickr Engineers Do It Offline: http://
code.flickr.com/blog/2008/09/26/flickr-
engineers-do-it-offline/
• Query Memcached: http://github.com/
ferblape/query_memcached/tree/master
• ActiveMQ: http://activemq.apache.org/
• Stomp: http://github.com/grempe/stomp/
tree/master

45. • New Relic: http://www.newrelic.com/
• Query Reviewer: http://code.google.com/p/
query-reviewer/
• Mongrel Proctitle: http://purefiction.net/
mongrel_proctitle/
• Production log analyzer: http://rails-
analyzer.rubyforge.org/
• syslog-ng: http://www.balabit.com/network-
security/syslog-ng/opensource-logging-
system/

46. • Nginx and Memcached, a 400% boost!: http://
www.igvita.com/2008/02/11/nginx-and-
memcached-a-400-boost/
• MySQL Proxy: http://forge.mysql.com/wiki/
MySQL_Proxy

47. ¡Gracias!

48. no, en serio..
¡¡Muchas gracias!!

49. ¿Quieres trabajar en
The Cocktail?
Envíanos tu C.V. a info@the-cocktail.com
http://www.the-cocktail.com