Download - Softonic Labs - Web Escalable
Mejorando el rendimiento en aplicaciones web
12/2008
Web Escalable
• Breve Introducción
• Cacheando contenidos
• Contenido en las nubes (cloud computing)
• Peticiones de datos paralelas
• Near Time Processing
• Particionar los datos
• Buenos consejos a seguir
• Conclusiones
Presentación basada en el workshop de Joe Stump (Digg) en el FOWA
Resumen – Softonic Labs
Resumen
• 47.026.736 usuarios únicos
• 69.745.943 Visitas
• 351.747.621 Páginas vistas
• Más de 100 servidores entre frontends y backends
Datos de Google Analytics en Softonic para Diciembre 2008
Introducción – Softonic Labs
Introducción : Datos de Softonic
• 1 servidor
• Todas las aplicaciones en la misma máquina
• Cuello de botella único
• Punto de fallo único
1. Nacimiento
Introducción – Softonic Labs
Introducción : Fases de un proyecto
2. Juventud
3. Madurez
• n servidores
• Distribuir aplicaciones en distintas máquinas
• Alta disponibilidad
• Múltiples Mysql, múltiples frontends…
• Aplicación distribuida en distintos hostings (arround the world)
• Hay desarrolladores disponibles?
• Está bien soportado?
• Tiene una comunidad detrás?
• Te hace feliz?
Como seleccionar un lenguaje de programación
Introducción – Softonic Labs
Introducción : Lenguaje Programación
Aspectos técnicos
• El rendimiento del lenguaje no importa.
• PHP no es escalable
• Ejemplo : Comparando PHP vs Ruby tenemos un 3% de diferencia.
Introducción : ¿Como se puede escalar?
Scaling Up Scaling Out
• Más CPU
• Más memoria
• Más máquina
• Sencillo
• Muy limitado
• Más máquinas
• Distribuir
• Descentralizar
• Complicado
• Es el camino a seguir
ServidorServidor
Servidor Servidor Servidor
ServidorServidor
Introducción : CAP Theorem
• Strong Consistency : Sin fallos
• High Availability : Que aguante
• Partition Tolerance : Divisible
Los tres puntos principales a tener en cuenta
• No compartir. Tener servidores separados para cada servicio
• Descentralizar. Repartir aplicaciones entre distintas máquinas
• Esperar fallos. Tarde o temprano el Hard o el Soft van a fallar
• Añadir más máquinas. Para crecer es suficiente con añadir Hardware.
¿Cómo lograrlo?
Cacheando : Opciones
• En disco– Fácil– Barato– No compartido– Lento
• En memoria– APC (No comartido, datos estáticos)– Memcached (distribuído)
• In the clouds– Datos estáticos no volátiles : ficheros, imágenes, videos…– OMG Files (Mogile FS)– MemcacheDB– Amazon S3
Cacheando : ¿Dónde?
• En la aplicación (FrontEnd)– Librerías de acceso a caché (PHP. Python…)– El más barato
• Por software– Varnish– Squid– Precio intermedio
• Por Hardware– Dispositivos especializados– Mucho más caro
Cacheando : Buenas técnicas - 1
• Que la caché nunca expire. Borrar desde software cuando exista una modificación en los datos
• Hacer flush del total o de partes determinadas modificando un prefijo en el identificador del caché ( A_cache_id B_cache_id ). Los datos antiguos ya caducarán cuando les toque.
• Utilizar multi-get (hacer fetch en diferentes servidores memcached) . Ganancias de hasta el 400%
• Expiración explícita. Cachear módulos por separado con tiempos de expiración distintos.
• Utilizar una cadena de responsabilidad según objetos a cachear:Ejemplo : 1- APC, 2-Memcached, 3-Siguiente cadena…
Cacheando : Buenas técnicas - 2
• Agrupamiento inteligente. Ageupar aquellos datos que puedan expirar a la vez
• Tiempos de expiración puestos time+random para evitar la expiración simultánea de datos
• Distintos Pool de Memcached (opción de compilación) optimizados según el tamaño de los objetos a cachear
• Tener las variables de Session en Memcached
Contenido en las nubes - 1
• Cloud Services : Amazon S3– Fácil de implementar– Sin Hardware adicional– Razonablemente barato– http://aws.amazon.com/s3/
• Network File System (NFS)– Fácil de implementar– Necesita Hardware– No es escalable (Single Point of Failure)– No es una solución a largo plazo– http://es.wikipedia.org/wiki/NFS
Contenido en las nubes - 2
• MogileFS– Muy complejo de instalar y mantener (mínimo 3 servidores)– Escala sin problemas– Soporte para WebDAV y PHP– Utilizado en SixApart, Digg, LiveJournal…– http://www.danga.com/mogilefs/
• CDN– 100% Outsourced– Muy caro– Escala sin problemas– http://www.cdn.com
Contenido en las nubes – 3
• GlusterFS– Más fácil de instalar y mantener– Posix 100%– Escala sin problemas– http://www.glusterfs.org/
• Crea tu propio sistema especializado– Sólo si el almacenamiento es tu negocio– Muy complejo– Personalizable
Peticiones de datos paralelas
• Lanzar peticiones HTTP en paralelo y de forma asíncrona.
- Abrir sockets, realizar consultas y bloquear hasta recibir todas las respuestas.- PHP (5.2+) curl_multi : http://www.somacon.com/p537.php- Mover modelos (MVC) a web services- Abrir API de consulta (interna o externa)
• Gearman
- Consultas Paralelas- Asíncrono- Fork() distribuído- http://www.danga.com/gearman/
Near Time Processing
• Acciones que no requieren respuesta inmediata
• Procesamiento de acciones en tiempo “casi” real
• Eventualmente consistente
• Asíncrono
• Paralelo
Near Time Processing – Opciones - 1
• Cron
– Muy sencillo– Bueno para trabajos en background– No descentralizado
• Gearman– Balanceador de carga de llamadas a funciones– Sencillo– Escala bien– Descentralizado– Sin Garantías (si el proceso falla no es el fin del mundo)– Reintentos por parte del cliente
Near Time Processing – Opciones – 2
• Sistema de colas
– Grid Engine de SUN : http://gridengine.sunsource.net/– Starling : http://rubyforge.org/projects/starling/– MemcacheQ : http://memcachedb.org/memcacheq/– Beanstalk : http://xph.us/software/beanstalkd/– Gearman/Schwartz (con garantía de éxito y reintentos)
• EC2 de Amazon– Casi ilimitado– No se puede compartir– Utilizado para Bots, Crawlers…
Particionar los datos – Horizontal
• La misma tabla en distintos masters
• Evita cuellos de botella de escritura
• Es distribuido
• Permite tener tablas más pequeñas y manejables (ALTERS)
• El criterio de partición es distinto en cada proyecto (país, empresa, departamento...)
Usuarios
192.68.0.1
Usuarios
192.68.0.2
Usuarios
192.68.0.3
Particionar los datos – Vertical
• Separar distintas tablas en distintos masters
• Distribuyes la carga entre servidores
• Evita que largos alters de tablas saturen el servidor
Usuarios
192.68.0.1
Preferencias
192.68.0.2
Items
192.68.0.3
Particionar los datos – Herramientas
• MemcacheDB- Memcache + BDB- 28.000 escrituras/seg- Alta disponibilidad y replicación- Datos desnormalizados.- http://code.google.com/p/memcachedb/
• IDDB- Sistema propio de Digg- Permite particiones elásticas- Eventualmente consistente- Tipos de particiones variables
Buenos consejos a seguir
• Reducir peticiones HTTP
• Evitar CSS y JS inline
• Compresión y minificación
• Aprovechar ventajas de HTTP/1.1
Conclusiones
• No compartir, desnormalizar
• Cachear y poner en cola
• Reducir, reciclar y reutilizar