Escalabilidad y alto rendimiento con Symfony2

5,073 views

Published on

En esta charla se pretenden tocar todas las cosas que debemos tener en cuenta para sacar el máximo rendimiento y poder escalar usando Symfony2.

Se toca desde parámetros de configuración de PHP y APC, optimización de Composer, dónde optimizar, quick wins varios, cómo hacer profiling correctamente, BBDD NoSQL vs SQL y por supuesto lecciones aprendidas en mis anteriores trabajos

Published in: Technology

Escalabilidad y alto rendimiento con Symfony2

  1. 1. 20-22 junio 2013MadridESCALABILIDAD YALTO RENDIMIENTOCON SYMFONY2Ricard ClaudeSymfony
  2. 2. ¡muchas gracias a nuestrospatrocinadores!deSymfony
  3. 3. RICARD CLAUTwitter @ricardclau / Gmail ricard.clau@gmail.comEmigrante en LondresA veces doy charlasY de vez en cuando me aceptan PR en Github
  4. 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. 5. CONCEPTOSEscalabilidad, Disponibilidad, Balanceo, ShardingMillones deUsuarios entodo el mundo24x7x365
  6. 6. ESCALANDO¿Qué modelo creéis que es mejor y más sostenible?
  7. 7. DISPONIBLES 24X7X365Debemos podernos levantar rápido de cualquier problema
  8. 8. BALANCEO DE CARGAPermite hacer cambios sin dejar de dar servicio
  9. 9. SHARDINGLlega un momento en que hay que hacerlo...¡Y puede ser muy doloroso!
  10. 10. NO NOS PRECIPITEMOS...• Evitad optimizaciones prematuras• Las microoptimizaciones nosirven para nada• Foco a cosas de impacto• Mejoras incrementales• Si no se factura, no sirve de nada
  11. 11. NI ESPEREMOS AL DESASTRE...• Monitorizad servidores: Ram,CPUs, Disco, red, procesos idle...• Intentad implicar a negocio• Cuando algo esté a la mitad desu capacidad, preparad plan B• Morir de éxito es fatal
  12. 12. MANOS A LA OBRA¿Por dónde empezamos?
  13. 13. CUIDAD EL FRONTENDMinimizad las peticiones y su tamaño
  14. 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. 15. ESCALANDO PHPFacebook,Wikipedia,WordPress,YouPorn, ...Softonic, Emagister, Privalia, LetsBonus, SocialPoint,Tuenti, ...
  16. 16. ¿ESCALAR ES FÁCIL?• PHP bootstrapea todo en cada Request, y escalar es tanfá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 storagepero 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. 17. VIDA MÁS ALLA DE LAMP• Servidores web ligeros para los assets• Usad reverse proxy cache comoVarnish si podéiscachear 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 sesolucionan mejor con bases de datos NoSQL
  18. 18. PERFORMANCE PHPOpcode caches, composer, quick winsActualizar a PHP5.4 acelerará un 15-30%
  19. 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. 20. ESTADO DE APChttp://svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup
  21. 21. ZEND OPCACHE• Será incluido en distribución estándar de PHP5.5 (válidodesde 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. 22. ESTADO DE OPCACHERasmus en estado puro :)(https://github.com/rlerdorf/opcache-status)
  23. 23. COMPOSER AUTOLOAD• Usáis todos Composer, ¿no?• Autoload costoso ya que se suele accedermucho al FileSystem• composer.phar install --optimize-autoloader (-o) genera ClassMap• Mismo rendimiento con apc.stat a Off queApcUniversalClassLoader y muchasmenos claves en APC!
  24. 24. APC VS ZEND OPCACHEhttp://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-benchmarks-with-symfony2/
  25. 25. APC VS ZEND OPCACHEhttp://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-benchmarks-with-symfony2/Comparativa Requests / segundo
  26. 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. 27. PROFILINGDiagnosticando cuellos de botella
  28. 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 enproducció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. 29. XHPROF (DEV VS PROD)https://github.com/jonaswouters/XhprofBundle
  30. 30. HELLO WORLDPHP y los frameworks...Y las comparativas entre cosas que no tienen nada que ver
  31. 31. ¿FRAMEWORKS == LENTOS?• Existe la creencia de que un framework propio escritodesde 0 será mucho mejor que coger uno existente• También que los frameworks grandes consumen mucho. (ZF1y 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. 32. TECHEMPOWER BENCHMARK• Symfony2 queda mal clasificado• La comparación con otros FW PHP es algo injusta. Secargan 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. 33. GUARDANDO DATOSUsa la herramienta correcta para el trabajoNinguno soluciona todos los problemas
  34. 34. BBDD RELACIONALES• Tecnologías maduras y buena performance• Transacciones: Atomicidad, Consistencia, aIslamieto, Durabilidad• Podemos usarlas como NOSQLs clave-valor usandocampos BLOB con objetos serializados en el interior• Soportan integridad referencial, Joins, querys complejas• Millones de registros sin problemas
  35. 35. SOLUCIONES NOSQL• Soluciones a algunos problemas concretos• Teorema CAP (Consistencia, Disponibilidad,Tolerancia aparticionamiento). 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. 36. SISTEMAS DE COLASCasi nada tiene por qué ser REAL-TIME
  37. 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. 38. PHP A VECES NO BASTAO no es la mejor herramienta para lo que necesitamos
  39. 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 conpeticiones no cacheables• Threading, Forking
  40. 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 yestá por ver la evolución de Node.JS• Y siempre seguirán siendo necesarios lenguajescompilados como Go, C, C++ o Java para algunas cosas• ¡Aprender otros lenguajes nos hace mejores!
  41. 41. ELVIRUS ERLANG• Es muy diferente a PHP.Además es divertido• Problemas complejos solucionados hace más de 20años por ingenieros de Ericsson• Creemos que el futuro de Internet pasa por un usomasivo de Erlang en todas partes• No os perdáis la charla de Jordi Llonch y MarcosQuesada en unos instantes!
  42. 42. SYMFONY2Es suficientemente rápido para lo que quieres hacer
  43. 43. ¿POR QUÉ ELEGIR SYMFONY2?• Symfony2 NO es el framework más rápido para Hello Worldpero es muy rápido para APIs y aplicaciones web• Usar un framework tan grande es bueno, porque permiteprobar cualquier tecnología en 5 minutos• Crear tu framework tiene costes y riesgos muy elevados!• Tiene un roadmap de releases LTS, proyectos grandes enproducción y una comunidad, madurez, número debundles, y estabilidad envidiable
  44. 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. 45. POWERED BY SYMFONY2Y creciendo...
  46. 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. 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

×