by 
¿Qué es un benchmark?
Según Wikipedia, técnica utilizada para medir el rendimiento de un sistema o componente del mismo …
Anteriormente ya publicamos benchmarks con diferentes frameworks php en el blog y wiki, pero ya son antiguos. Esta vez usaremos los datos de una comparativa independiente, que emplea versiones actualizadas de los frameworks.
Estos datos de rendimiento son resultado de un trabajo serio y bien hecho de Kenjis en Github. En el link pueden encontrar todo el código, ejecutarlo en sus propios ordenadores y ver las gráficas interactivas con mucha información. Además encontrarán los datos del equipo que se usó, incluyendo notas. Finalmente pueden aportar pasando un pull request o indicando un error.
Resultados del benchmark de Kenjis, realizado el 14 de febrero de 2017.
Comparativa de velocidad de los frameworks php
| Framework PHP | Respuestas por segundo | Relativo | Uso de memoria | Relativo |
|---|---|---|---|---|
| siler-0.6 | 2,069.69 | 20.3 | 0.25 | 1.0 |
| kumbia-1.0-dev | 1,753.60 | 17.2 | 0.29 | 1.2 |
| staticphp-0.9 | 1,665.28 | 16.3 | 0.27 | 1.1 |
| phalcon-2.0 | 1,618.39 | 15.9 | 0.26 | 1.1 |
| tipsy-0.10 | 1,376.97 | 13.5 | 0.32 | 1.3 |
| fatfree-3.5 | 965.16 | 9.5 | 0.41 | 1.7 |
| codeigniter-3.0 | 753.09 | 7.4 | 0.42 | 1.7 |
| nofuss-1.2 | 667.24 | 6.5 | 0.40 | 1.6 |
| slim-3.0 | 550.43 | 5.4 | 0.61 | 2.5 |
| bear-1.0 | 502.52 | 4.9 | 0.73 | 3.0 |
| lumen-5.1 | 415.57 | 4.1 | 0.85 | 3.5 |
| yii-2.0 | 410.08 | 4.0 | 1.32 | 5.4 |
| zend-expressive-1.0 | 403.34 | 4.0 | 0.75 | 3.1 |
| cygnite-1.3 | 369.12 | 3.6 | 0.71 | 2.9 |
| fuel-1.8 | 344.26 | 3.4 | 0.63 | 2.6 |
| silex-2.0 | 342.81 | 3.4 | 0.78 | 3.2 |
| phpixie-3.2 | 267.24 | 2.6 | 1.25 | 5.1 |
| aura-2.0 | 233.54 | 2.3 | 0.88 | 3.6 |
| cake-3.2 | 174.91 | 1.7 | 1.95 | 7.9 |
| zendframework-3.0 | 133.87 | 1.3 | 2.24 | 9.1 |
| symfony-3.0 | 131.50 | 1.3 | 2.18 | 8.9 |
| laravel-5.3 | 101.94 | 1.0 | 2.83 | 11.5 |
Las diferencias de velocidad son más grandes
Como muy bien indica Kenjis, hay 2 notas debajo de la tabla de resultados de velocidad de los frameworks:
Nota 1: Estos resultados son con la extensión Phalcon.so
Si no cargas «phalcon.so», las respuestas por segundo aumentarán un poco excepto para phalcon.
¿Cuánto exactamente? Phalcon hace php y cualquier framework php, aproximadamente un 10% más lento. Ver issue #8. Así que todos los demás frameworks php, tienen una desventaja de ~10%.
Nota 2: Este benchmark está limitado por la velocidad de ab
El Apachebench es suficientemente rápido para los frameworks más lentos, sin embargo se queda corto con los más veloces. Ver issue #62. En este caso, la herramienta wrk es una excelente opción para realizar bechmarks, pues es moderna y multihilo, lo cual no marca mucha diferencia con los frameworks más lentos, pero sí en los más rápidos, que tienden a disparar exponencialmente sus tiempos de respuestas por segundo.
Hola mundo benchmark
Hay mucha polémica sobre los benchmarks que sólo usan una salida de «Hola mundo!». (Aquí tenéis una buena discusión sobre este tema.)
Que si no tienen nada que ver con una aplicación real, que no usan cache ni templates, que para eso se usa php puro, en fin, existen mil excusas y características a analizar.
Entre ellas, que los micro frameworks (siler, slim, lumen, silex,..) tienen ventajas en estos tests sobre los full stack frameworks (symfony, laravel, kumbiaphp, cakephp,…), y en parte tienen razón, pues este tipo de benchs no miden la aplicación ni la velocidad de la cache, así que estos serían otros bechmarks a realizar.
Esta comparativa mide el máximo rendimiento posible del framework sin cachear, de lo contrario sería un bench de la cache, que todos tienen y pueden usar. De todas formas para crear la cache de un «Hola mundo!», requerirán el tiempo y memoria que se indica en esta comparativa. Además es necesario crear la cache e invalidarla, esto añade complejidad en partes de tu aplicación que no lo necesitan. Incluso en algunas aplicaciones, no se puede usar cache eficientemente.
Solución de algunos frameworks a estos datos: si quito este componente y este otro, será más rápido. Si no necesita ese componente, ¿Por qué se ejecuta? Hace mucho tiempo que usamos autoload en php, para cargar las clases cuando se necesitan. ¿Fallo de diseño o exceso de ingeniería?
Estamos de acuerdo que un «hola mundo» solamente, no es suficiente, se deben hacer más benchmarks, y aunque como veremos más adelante, las diferencias de velocidad se suelen mantener en otros tipos de benchmarks, no se puede negar que esto dice mucho sobre un framework.
Ejemplo: Framework A -> hola mundo: 1.000 r/s | complejo: 400 r/s, Framework B -> hola mundo: 500 r/s | complejo: 400 r/s. ¿Qué framework es más eficiente?
Otros benchmarks de frameworks
Crear benchmarks correctos es todo un arte y se necesitan conocimientos específicos, para lograr comparar en igualdad de condiciones o como se dice en el argot popular, comparar manzanas con manzanas y no con peras.
Hemos visto de todo durante estos años, desde uno que el más rápido era porque no recibía más que un error 500 del servidor, hasta otros que uno sólo enviaba «Hola mundo!» y otros todo un template con css incluido y dentro el «Hola mundo!». Alguno de estos casos, se han visto en los más que discutibles benchs propios de phalcon y symfony.
TechEmpower benchmark (Actualización)
Un gigante benchmark muy completo y serio, que mide el rendimiento más parecido a una aplicación real es de TechEmpower. Compara el rendimiento de web frameworks de cualquier lenguaje, usando acceso a base de datos y wrk, con PHP5, PHP7 y HVMM. Este benchmark también es completamente abierto para que la gente colabore, y necesitan ayuda para mantener los más de 250 frameworks. Curiosamente el ratio de velocidad es muy parecido a este de Hola mundo (no se fíen de los datos del round 13).
Queríamos añadir KumbiaPHP a este bench (y lo haremos en breve), pero vimos fallos de configuración en el código para PHP. Así que comprobamos los datos de php5-raw con 1 consulta a la base de datos, round #12: 116,628 r/s y round #13: 40,046 r/s (8\). Enviamos los commits de corrección, del php.ini y del nginx (aun se puede mejorar más esta configuración) y también se ha realizado el cambio para que cada fw tenga su propio php.ini. En el próximo round #14 verán brillar otra vez a PHP frente a otros lenguajes.
Las mejoras a la configuración de PHP fueron aceptadas, logramos agregarlo y en el round 16 hemos aparecido en el top: Round 16 results – TechEmpower Framwework Bechmarks
Publicaremos otro artículo en añadir KumbiaPHP, y explicaremos las notas de este benchmark, que son individuales para cada framework.
Kenjis y ORM benchmarks
Kenjis tiene otros bechmarks de php muy interesantes: User Agent Parser y PHP ORM . François Zaninotto php-orm , es un fork más actualizado y con más ORMs. Si unimos un framework lento con un ORM lento, será siempre una mala combinación. Hoy en día casi todos los frameworks permiten usar cualquier ORM. Próximamente añadiremos el nuevo ActiveRecord de KumbiaPHP a estas comparativas (rapidísimo y sin uso de memoria prácticamente).
Esperamos que Kenjis use wrk y separe el php.ini, para el próximo. Sino crearemos un fork para que se aprecien bien las diferencias. Siempre nos fijamos en las r/s, pero hay otro dato muy importante, que añadiremos. La transferencia de datos, en esta comparativa usando wrk los más rápidos con ~6 Mb/s y los más lentos con ~130 Kb/s. :P
Conclusión
Los datos hablan por si solos, saquen sus conclusiones. No se fíen de cualquier benchmark que vean. Estas comparativas no son una competición entre frameworks php, son una gran herramienta de ayuda para mejorar todos los frameworks. Es normal que un framework que hace más cosas sea más lento, 2 – 3 veces más lento pero no 25.
La velocidad de un framework es muy importante para muchas aplicaciones. Pero hay más detalles a tener en cuenta, en el momento de elegir uno: la curva de aprendizaje, facilidad de uso, comunidad, entre otros. Tengan en cuenta todos los factores, pero también recuerden que después no podrán hacer su framework más rápido.
Para terminar, espero que no se queden callados y nos dejen conocer sus opiniones y comentarios.
Hasta la próxima.
Corrección de estilo por: Alejandra Morales
