20-22 junio 2013 Madrid

ESCALABILIDAD Y ALTO RENDIMIENTO CON SYMFONY2Ricard Clau

deSymfony

¡muchas gracias a nuestros patrocinadores!

deSymfony

RICARD CLAUTwitter @ricardclau / Gmail ricard.clau@gmail.com

Emigrante en LondresA veces doy charlas

Y de vez en cuando me aceptan PR en Github

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!

CONCEPTOSEscalabilidad, Disponibilidad, Balanceo, Sharding

Millones de Usuarios en

todo el mundo24x7x365

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

DISPONIBLES 24X7X365Debemos podernos levantar rápido de cualquier problema

BALANCEO DE CARGAPermite hacer cambios sin dejar de dar servicio

SHARDINGLlega un momento en que hay que hacerlo...

¡Y puede ser muy doloroso!

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

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

MANOS A LA OBRA¿Por dónde empezamos?

CUIDAD EL FRONTENDMinimizad las peticiones y su tamaño

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

ESCALANDO PHPFacebook, Wikipedia, WordPress, YouPorn, ...

Softonic, Emagister, Privalia, LetsBonus, SocialPoint, Tuenti, ...

¿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

VIDA MÁS ALLA DE LAMP

• Servidores web ligeros para los assets

• Usad reverse proxy cache como Varnish 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

PERFORMANCE PHPOpcode caches, composer, quick wins

Actualizar a PHP5.4 acelerará un 15-30%

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

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

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 :)

ESTADO DE OPCACHERasmus en estado puro :)

(https://github.com/rlerdorf/opcache-status)

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!

APC VS ZEND OPCACHEhttp://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-

benchmarks-with-symfony2/

APC VS ZEND OPCACHEhttp://www.ricardclau.com/2013/03/apc-vs-zend-optimizer-

benchmarks-with-symfony2/

Comparativa Requests / segundo

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

PROFILINGDiagnosticando cuellos de botella

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

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

HELLO WORLD PHP y los frameworks...

Y las comparativas entre cosas que no tienen nada que ver

¿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 Performance Tests!

• ¡Nadie sabe más que la inteligencia colectiva!

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

GUARDANDO DATOSUsa la herramienta correcta para el trabajo

Ninguno soluciona todos los problemas

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

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

SISTEMAS DE COLASCasi nada tiene por qué ser REAL-TIME

¿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!

PHP A VECES NO BASTAO no es la mejor herramienta para lo que necesitamos

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

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!

EL VIRUS 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!

SYMFONY2Es suficientemente rápido para lo que quieres hacer

¿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

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! :)

POWERED BY SYMFONY2Y creciendo...

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

¿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