Publicité
Publicité

Contenu connexe

Publicité
Publicité

Sitios web de alto rendimiento y alta disponibilidad

  1. Sitios web de alto rendimiento y disponibilidad IIG. Iván G. Campaña N. @icampana
  2. Qué es un sitio web de alto rendimiento Un sitio que recibe desde miles a millones de visitas por segundo. Va asociado a sitios con un flujo alto de información (medios de comunicación, páginas de entidades de gobierno, sitios de famosos, etc...). Los visitantes esperan poder acceder al contenido en cualquier momento y sin interrupciones. El tiempo fuera de línea puede implicar pérdidas monetarias o daño de imagen para la empresa. Título de la presentación
  3. Qué es un sitio web de alto rendimiento Sitios nacionales configurados con infraestructura para soporte de alto número de visitas: ● El Universo (eluniverso.com) ● Ecuavisa (ecuavisa.com) ● Revista Estadio (estadio.ec) Ejemplos internacionales ● La casa blanca (www.whitehouse.gov) ● The Economist (economist.com) Requieren no sólo de infraestructura, sino también de una estrategia de optimización muy específica enfocado en los servicios que se quiere prestar . Uno de los puntos de quiebre a nivel nacional (30S 2010), a nivel internacional Tsunami de Japón Título de la presentación
  4. ¿Cómo se maneja normalmente un proyecto web?
  5. Desarrollo común de una app web Título de la presentación Somos presa fácil
  6. Desarrollo común de una app web Título de la presentación
  7. Normalmente nos encontramos con... Título de la presentación
  8. Desarrollo común de una app web Título de la presentación ● En las versiones iniciales de una app, se enfoca en el desarrollo de funcionalidades en un ambiente controlado. ● Se trabaja en base a la experiencia de sistemas transaccionales tradicionales. ○ Colas de espera / Respuesta síncrona ● No se toma en cuenta pruebas de estrés (de la aplicación). ● Se piensa más en diseño que en rendimiento. ● Los problemas de rendimiento aparecen en ambiente de producción. El planeamiento de crecimiento por niveles debe incluirse desde la partida.
  9. ¿Qué buscamos con alto desempeño? ● Tiempos de respuesta bajos ● Escalabilidad ○ Poder agregar componentes a la infraestructura sin que esto implique tiempo fuera de línea (downtime). ○ Reaccionar ante el aumento de la demanda de manera transparente. ● Optimizar el consumo de recursos. Título de la presentación
  10. Problemas comunes ● Distribución de contenido ● Manejo de archivos de gran tamaño (videos, multimedia, etc…) ● Búsquedas en archivos históricos ● Servicios a usuarios ● Cantidad de usuarios con una sesión activa Además: ● PHP es lento ○ Necesita re-compilar el código en cada ejecución. ● BDs son lentas ● Lectura/escritura en disco es lenta (cuello de botella) ● Incrementar infraestructura no siempre es posible Título de la presentación
  11. ¿Qué se necesita para hacerlo? Título de la presentación ● Conocimientos :) ● Recursos :(
  12. Título de la presentación ¿La aplicación se cayó, quien lo arregla? ( O Quien apaga el incendio)
  13. Aparece un nuevo concepto Devops ● Los problemas no son exclusivos de Desarrollo ● Ni tampoco son exclusivos de Operaciones (Infraestructura) ● Es un trabajo conjunto / con un equipo especial dedicado (DEVOPS). Título de la presentación
  14. ¿La solución? ● No existe una fórmula mágica. ● Se necesita planificación y adaptar el sitio para poder responder a la demanda. ● Nos podemos basar en fórmulas, pero pesa mucho la experiencia. ● Hay que pensar en software y hardware ● Integración de servicios de distribución y balanceo de carga ● Mejorar acceso a recursos lentos (Sistema de archivos, BD, Red, E/S en general) ● Redundancia. ● Se puede pensar en utilizar servicios en la nube (cloud SAS). Título de la presentación
  15. ¿La solución? ● Más infraestructura sin optimización = Desperdicio de dinero. ● Establecer un mínimo y un máximo de visitantes esperados. ● ¿Qué puedo lograr con mis recursos? ● Identificar qué características del sitio requieren atención especial: ○ Ej: Contenido altamente dinámico, llamadas AJAX, número de usuarios logueados concurrentemente. Título de la presentación
  16. Cómo hacer pruebas de rendimiento Se deben realizar en ambiente de QA o Staging. ● En casos en los que no contemos con un área de QA, realizar las pruebas sobre producción de forma controlada (para obtener mejores mediciones). ● jMeter ○ Pruebas con los tipos de usuarios que se van a manejar ○ Páginas estáticas ○ Páginas con bloques de contenido dinámico. ○ Páginas que varían dependiendo de parámetros: ■ Por Rol ■ Por Usuario ■ Por variables Título de la presentación
  17. Cómo hacer pruebas de rendimiento ● Apache Benchmark ○ Pruebas básicas ○ Simulación de usuarios concurrentes ○ Se puede enviar cookies y parámetros para simular sesiones de usuario. ○ Se maneja a nivel de scripting o en consola ● New Relic ( http://newrelic.com/ ) ○ Permite identificar cuellos de botella en el rendimiento del sitio o la infraestructura. ○ Integración directa con drupal (servicio pro) ○ Monitoreo constante durante las pruebas de rendimiento ● BlazeMeter ( http://blazemeter.com/ ) Título de la presentación
  18. Estructura genérica de un sitio web ● Título de la presentación
  19. Herramientas de caché ● Herramientas disponibles bajo esquema open source: ○ Memcached ○ APC ○ Wincache ○ Varnish ○ Redis ○ Cache de BD ■ Integración de ADODB con alguno de los motores anteriores. Título de la presentación
  20. Motores de base de datos ●Estándar: ○ Mysql ○ PostgreSQL ●Versiones modificadas (especializadas): ○ MariaDB ○ Percona SQL ●MongoDB (NOSQL) Título de la presentación
  21. Errores comunes en BD ● Bloqueo a nivel de fila ● Bloqueo de tablas ● Índices lentos ● Búsquedas secuenciales ● Fragmentación ● Concurrencia y escritura Casos específicos: ● PostgreSQL.- Soporte limitado dependiendo de los proveedores de hosting. ● MySQL.- problemas en consultas que necesitan índices inversos (soporte experimental) Título de la presentación
  22. Capas de caché ● Caché de MySQL / BD en general ● Caché de OPCode (PHP) ● Caché interno de la aplicación web ● HTTP Caché (Proxy reverso) ● Caché del cliente ● Caché de HTML5 (Modo desconectado) Título de la presentación
  23. Optimización de nivel básico ● Caché en los navegadores ○ e-tags ○ Fecha de expiración de archivos ○ Usar dominios sin cookies ○ Usar una red CDN ■ (Se puede crear un CDN falso con un servidor secundario) ○ Proxy inverso (Varnish, nginx) ○ Agregación CSS/JS ● Primera forma de evaluación: ○ Google Page Speed ○ Yahoo YSlow Título de la presentación
  24. Optimización de nivel básico ● Forma de evaluación: ○ Yahoo YSlow http://developer.yahoo.com/yslow/ ○ Google Page Speed https://developers.google.com/speed/pagespeed ● Mantener las funcionalidades personalizadas modulares, pero compactas. ○ Desagregar el código para reducir la cantidad de espacio utilizado en memoria ○ Cada bloque de memoria se debe multiplicar por la cantidad de usuarios conectados Título de la presentación
  25. ●Caché de código ○ Mantiene el código cargado en memoria ○ Se precompila cada vez que hay un cambio. ○ Evita hacer “hits” al disco por cada archivo ■ Una instalación de una aplicación web (Orfeo / Quipux) incluyendo los módulos contribuidos puede tener cerca de 2,855 archivos de código. ■ Cada archivo debe ser recompilado y ejecutado. ● Caché de variables y consultas ○ Memcached con múltiples “espacios” ○ Caché de bloques y de páginas ● Opciones: APC, Zend Optimizer Optimización de nivel medio Título de la presentación
  26. ●Caché de código Optimización de nivel medio Título de la presentación
  27. ● La herramienta utilizada por defecto es Memcached. ○ Requiere soporte de módulo de PHP ○ Se pueden definir múltiples instancias para los diferentes componentes del sitio. ○ Se mantiene el resultado en memoria RAM. ○ Permite reemplazar caché estándar, así como caché de sesiones y de bloqueo (lock) Optimización de nivel medio Título de la presentación
  28. Reemplazar servidor Web. ● Servidore compatibles: ○ Apache.- Opción por defecto, estable aunque con mayor consumo de recursos. ○ Nginx.- Mejor rendimiento con archivos estáticos y opción de habilitar microcaché. ■ Microcaché permite almacenar temporalmente la página renderizada. ○ Lighttpd.- Funciona en modo fast-cgi consumo de recursos bajo (hay que configurar el número de listeners de acuerdo a las características del equipo físico). Optimización de nivel medio Título de la presentación
  29. Optimización de nivel avanzado ● Proxy inverso ○ Varnish 3.0 ○ Permite almacenar todo el contenido de la página en caché ○ Integración con ESI para contenido dinámico ■ Edge Side Includes ● Podemos establecer reglas específicas de expiración (necesita soporte de la aplicación). ○ Establecer reglas para eliminar caché en momentos específicos ● Integrar búsquedas a través de Apache Solr Título de la presentación
  30. Búsquedas con Apache Solr ● Uno de las áreas más explotadas de un sitio web ○ Búsqueda de contenidos. ● La búsqueda en base de datos es costosa. ○ Consume un alto porcentaje de CPU y memoria. ○ Bloquea la respuesta del webserver hasta obtener respuesta de la BD. ○ El caché de usuarios anónimos es pobre o ineficiente. ● Apache Solr es un motor de búsqueda configurable. ○ Se integra fácilmente con cualquier app web ○ Podemos personalizar los resultados. ○ Eliminamos la carga de búsqueda a la BD. ● Se puede hacer uso de facets para filtrar los resultados de búsquedas ● Permite exponer contenidos “relacionados” Título de la presentación
  31. Nivel avanzado de optimización ● Varnish 3.0 es la opción más utilizada (no es la única). ● Permite reducir el número de hits que llegan al servidor web. ● Maneja archivos de scripting para evaluar cómo se debe manejar las solicitudes. ● Permite hacer balanceo de carga entre múltiples servidores. ● Podemos configurar un “fallback” en caso de que el pool de servidores web no responda. ● Puede alterar las cabeceras de respuesta para eliminar o agregar elementos. Título de la presentación
  32. Optimización en base a SaS ● Utilizar herramientas de balanceo de carga, proxy inverso, CDN ○ Emplear herramientas de terceros para reducir carga (opcionales): ■ Cloudflare ■ Apache Mahout Título de la presentación
  33. ¿Qué es ESI? ● Edge Side Includes (http://en.wikipedia. org/wiki/Edge_Side_Includes) ● Generación de contenido dinámico en base a páginas estáticas. ● Se integra con Varnish, Akamai, Squid y NginX ○ Permite integrar contenido dinámico para usuarios logueados disminuyendo el consumo de recursos. ○ Necesita desarrollo de partes de la aplicación con soporte ajax. Título de la presentación
  34. Optimización en base a terceros ● Servicios de terceros ● Redes CDN ○ Akamai ○ Amazon ○ Cloudflare ○ Rackspace ● CDN Falso ○ Enlace de comunicación separado para ese servidor ○ Distribuye parte del contenido ○ Soporta los métodos Pull y Request Título de la presentación
  35. Mejoras para PHP ●Optimización del código a través de precompilado: ○ Xcache ○ APC ○ Zend Optimizer Título de la presentación
  36. Cloudfare (opcional) Título de la presentación
  37. Cloudflare ● CDN.- Content Delivery Network ○ Distribuye copias del contenido estático dentro de su red (javascript, imágenes, css). ○ Tiene servidores distribuidos dentro de diferentes zonas geográficas. ● Opción de optimizar el contenido ○ Minimizar js, css. ● Firewall de aplicación (Servicio Pro) ○ Protección contra ataques. ● Proxy inverso ● Utilizando scripts se puede forzar la limpieza del caché de archivos de cloudflare de manera selectiva. Título de la presentación
  38. Manejo de cambios (Sine qua non) ● Se debe contar con espacios de desarrollo, pruebas y producción. ● Permite optimizar los recursos necesarios para cada espacio y función. ● Reduce la carga operativa en producción. ● Se puede tener la opción de manejar el contenido desde un sitio “réplica” y sincronizar la información en el sitio real. ● Mantener la mayor cantidad de funcionalidades en forma de código exportable (sin utilizar features). Título de la presentación
Publicité