Qué cosas se deben tomar en cuenta al momento de pensar en crear o mejorar una aplicación web que va a ser utilizada por miles de usuarios... por segundo. Enfocado principalmente en proyectos basados en PHP

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