El documento presenta una charla sobre escalabilidad y rendimiento en Symfony2, abordando temas como optimización, almacenamiento, y balanceo de carga. Se discuten técnicas para mejorar el rendimiento, como el uso de cachés y perfiles, y se enfatiza la importancia de un correcto diseño arquitectónico y la monitorización. Además, se presentan ejemplos de implementación y el futuro de la tecnología en el contexto de la programación web.

1. 20-22 junio 2013
Madrid
ESCALABILIDAD Y
ALTO RENDIMIENTO
CON SYMFONY2
Ricard Clau
deSymfony

2. ¡muchas gracias a nuestros
patrocinadores!
deSymfony

3. RICARD CLAU
Twitter @ricardclau / Gmail ricard.clau@gmail.com
Emigrante en Londres
A veces doy charlas
Y de vez en cuando me aceptan PR en Github

4. VAMOS A HABLAR DE...
• Performance y escalabilidad
• Profiling y optimización
• Storage: SQL vs NoSQL
• ¡Basado en hechos reales!
• Casi todo sirve también en entornos sin Symfony2
• Symfony2 es suficientemente rápido. ¡De verdad!

5. CONCEPTOS
Escalabilidad, Disponibilidad, Balanceo, Sharding
Millones de
Usuarios en
todo el mundo
24x7x365

6. ESCALANDO
¿Qué modelo creéis que es mejor y más sostenible?

7. DISPONIBLES 24X7X365
Debemos podernos levantar rápido de cualquier problema

8. BALANCEO DE CARGA
Permite hacer cambios sin dejar de dar servicio

9. SHARDING
Llega un momento en que hay que hacerlo...
¡Y puede ser muy doloroso!

10. NO NOS PRECIPITEMOS...
• Evitad optimizaciones prematuras
• Las microoptimizaciones no
sirven para nada
• Foco a cosas de impacto
• Mejoras incrementales
• Si no se factura, no sirve de nada

11. NI ESPEREMOS AL DESASTRE...
• Monitorizad servidores: Ram,
CPUs, Disco, red, procesos idle...
• Intentad implicar a negocio
• Cuando algo esté a la mitad de
su capacidad, preparad plan B
• Morir de éxito es fatal

12. MANOS A LA OBRA
¿Por dónde empezamos?

13. CUIDAD EL FRONTEND
Minimizad las peticiones y su tamaño

14. COSAS FÁCILES DE APLICAR
• La request más rápida es la que no se hace
• Iconos en base64 dentro del CSS
• CSS y JS minificados, imágenes con jpegoptim, pngcrush, ...
• Usad cabeceras HTTP para poder cachear
• La latencia de red importa más de lo que parece
• Se puede ganar muchísimo en experiencia de usuario

15. ESCALANDO PHP
Facebook,Wikipedia,WordPress,YouPorn, ...
Softonic, Emagister, Privalia, LetsBonus, SocialPoint,Tuenti, ...

16. ¿ESCALAR ES FÁCIL?
• PHP bootstrapea todo en cada Request, y escalar es tan
fácil como añadir máquinas tras un Load Balancer
• Pero eso provoca peor rendimiento que otros lenguajes
• Hay cosas a compartir como las sesiones o el storage
pero frameworks como Symfony nos lo ponen muy fácil
• Es una tecnología probada por sitios MUY grandes
• Los primeros problemas suelen estar en las BBDD

17. VIDA MÁS ALLA DE LAMP
• Servidores web ligeros para los assets
• Usad reverse proxy cache comoVarnish si podéis
cachear páginas (o trozos, con ESI) durante un cierto tiempo
• Cachead todo lo que podáis (APC, Memcached, Redis, ...).
Caché 10 segundos -> ¡ Sólo 6 peticiones por minuto!
• MySQL aguanta MUCHO. Pero hay problemas que se
solucionan mejor con bases de datos NoSQL

18. PERFORMANCE PHP
Opcode caches, composer, quick wins
Actualizar a PHP5.4 acelerará un 15-30%

19. APC: NUESTRO MEJOR AMIGO
• Si no sabes qué es, nunca te has preocupado del rendimiento
• apc.stat -> Off (Apache reload para ver cambios)
• apc.serializer -> igbinary (compact_strings a Off)
• apc.shm_size -> Ajustar a las necesidades
• apc.write_lock -> Evita problemas con caches frías
• Revisad http://www.php.net/manual/en/apc.configuration.php

20. ESTADO DE APC
http://svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup

21. ZEND OPCACHE
• Será incluido en distribución estándar de PHP5.5 (válido
desde 5.2) y se evitarán problemas como PHP5.4+APC
• Mejor rendimiento que APC en todos los tests
• README https://github.com/zendtech/ZendOptimizerPlus
• APC Cache + Upload Hooks seguirán existiendo en APCU
(https://github.com/krakjoe/apcu)
• En @EmagisterTech lo tienen en producción hace meses :)

22. ESTADO DE OPCACHE
Rasmus en estado puro :)
(https://github.com/rlerdorf/opcache-status)

23. COMPOSER AUTOLOAD
• Usáis todos Composer, ¿no?
• Autoload costoso ya que se suele acceder
mucho al FileSystem
• composer.phar install --optimize-
autoloader (-o) genera ClassMap
• Mismo rendimiento con apc.stat a Off que
ApcUniversalClassLoader y muchas
menos claves en APC!

24. APC VS ZEND OPCACHE
http://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-
benchmarks-with-symfony2/

25. APC VS ZEND OPCACHE
http://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-
benchmarks-with-symfony2/
Comparativa Requests / segundo

26. EXPRIMIENDO SYMFONY2
• Con Apache, app/console router:dump-apache
• SwiftMailer pesa bastante, intentad delegarlo a daemons
• Si podéis, usad SubRequests con ESI y Varnish
• Probad la extensión de Twig
• Podéis implementar incluso un Cache Warmer

27. PROFILING
Diagnosticando cuellos de botella

28. HERRAMIENTAS PROFILING
• ¿Cuánto tiempo dedicáis a hacer profiling?
• Existen xDebug (Derick Rethans) y XHProf (Facebook)
• Es muy conveniente tener alguna (o ambas) instaladas en
producción y poderlas activar unos minutos
• En local también podemos ver muchas cosas
• Algunas cosas sólo pueden reproducirse con tráfico real

29. XHPROF (DEV VS PROD)
https://github.com/jonaswouters/XhprofBundle

30. HELLO WORLD
PHP y los frameworks...
Y las comparativas entre cosas que no tienen nada que ver

31. ¿FRAMEWORKS == LENTOS?
• Existe la creencia de que un framework propio escrito
desde 0 será mucho mejor que coger uno existente
• También que los frameworks grandes consumen mucho. (ZF1
y Symfony2 funcionan con memory_limit 32M)
• Si ese es realmente tu problema, PHP tampoco es la solución
• ¡No os fiéis de los Hello World PerformanceTests!
• ¡Nadie sabe más que la inteligencia colectiva!

32. TECHEMPOWER BENCHMARK
• Symfony2 queda mal clasificado
• La comparación con otros FW PHP es algo injusta. Se
cargan muchas cosas innecesarias (PR#229 de @beberlei)
Hay incoherencias (frameworks PHP >> PHP)
• PHP nunca será más rápido que un lenguaje compilado
• Un buen acceso a los datos y cachear igualan las cosas
• Está en el roadmap intentar optimizar performance

33. GUARDANDO DATOS
Usa la herramienta correcta para el trabajo
Ninguno soluciona todos los problemas

34. BBDD RELACIONALES
• Tecnologías maduras y buena performance
• Transacciones: Atomicidad, Consistencia, aIslamieto, Durabilidad
• Podemos usarlas como NOSQLs clave-valor usando
campos BLOB con objetos serializados en el interior
• Soportan integridad referencial, Joins, querys complejas
• Millones de registros sin problemas

35. SOLUCIONES NOSQL
• Soluciones a algunos problemas concretos
• Teorema CAP (Consistencia, Disponibilidad,Tolerancia a
particionamiento). Solo se pueden tener 2.
• Inmadurez en muchas de ellas. Problemas escalando.
• ¿Big Data? 100 millones de registros NO lo es.
• Redis, Cassandra, Riak y Solr funcionan muy bien

36. SISTEMAS DE COLAS
Casi nada tiene por qué ser REAL-TIME

37. ¿REAL-TIME? ¿ES NECESARIO?
• Intentad delegar todo lo que podáis a procesos en lote
• Ejemplos: Envío de mails, peticiones a APIs externas,
redimensionado de imágenes, estadísticas, ...
• El 99% de estadísticas no hace falta que sean real-time
• ¡60 segundos de decalaje es real-time a todos los efectos!
• ¡Podemos usar varios lenguajes para maximizar rendimiento!

38. PHP A VECES NO BASTA
O no es la mejor herramienta para lo que necesitamos

39. ESCENARIOS MALOS PHP
• Aplicaciones con daemons CLI corriendo 24x7
• Cálculos matemáticos, procesados masivos de datos,
concursos de programación
• Escenarios de alta concurrencia de usuarios con
peticiones no cacheables
• Threading, Forking

40. LOOKING BEYOND PHP
• El futuro es la interacción continua cliente-servidor.
• JavaScript será el rey en cliente
• En el servidor, Erlang y Go cada vez tienen más presencia y
está por ver la evolución de Node.JS
• Y siempre seguirán siendo necesarios lenguajes
compilados como Go, C, C++ o Java para algunas cosas
• ¡Aprender otros lenguajes nos hace mejores!

41. ELVIRUS ERLANG
• Es muy diferente a PHP.Además es divertido
• Problemas complejos solucionados hace más de 20
años por ingenieros de Ericsson
• Creemos que el futuro de Internet pasa por un uso
masivo de Erlang en todas partes
• No os perdáis la charla de Jordi Llonch y Marcos
Quesada en unos instantes!

42. SYMFONY2
Es suficientemente rápido para lo que quieres hacer

43. ¿POR QUÉ ELEGIR SYMFONY2?
• Symfony2 NO es el framework más rápido para Hello World
pero es muy rápido para APIs y aplicaciones web
• Usar un framework tan grande es bueno, porque permite
probar cualquier tecnología en 5 minutos
• Crear tu framework tiene costes y riesgos muy elevados!
• Tiene un roadmap de releases LTS, proyectos grandes en
producción y una comunidad, madurez, número de
bundles, y estabilidad envidiable

44. DRAGONCITY: NÚMEROS
• ~7 millones de usuarios diarios (Facebook + iOS)
• ~300 millones de usuarios registrados
• Cientos de millones de registros diarios para analítica
• MySQL (32x2 + Analytics), Redis (~30), Cassandra (3)
• Las requests son tu partida -> No se puede cachear
• Y sí, casi todo el código es Symfony2! :)

45. POWERED BY SYMFONY2
Y creciendo...

46. CONCLUSIONES
• PHP y Symfony2 sirve para la mayoría de proyectos
• La estrategia de caching nos ayudará
• Podemos mejorar el rendimiento con buen profiling
• La BBDD suele ser el primer cuello de botella al escalar
• Un buen diseño de arquitectura es lo más importante
• PHP no es la mejor solución para algunos problemas

47. ¿PREGUNTAS?
• Twitter: @ricardclau
• E-mail: ricard.clau@gmail.com
• Github: https://github.com/ricardclau
• Blog de PHP y Symfony2: http://www.ricardclau.com
• Por favor, comentad en http://joind.in/talk/view/8845