Alto rendimiento y escalabilidad en plataformas Rails: Casos prácticos. Soluciones y trucos.
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
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
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
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
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