Symfony ficha a uno de los mayores expertos PHP en mejora de rendimiento
Las discusiones sobre el rendimiento de Symfony son casi tan antiguas como el propio framework. Aunque es cierto que Symfony es lento si no se utiliza ninguna caché, cuando se activan todas sus cachés y se utilizan todas sus funcionalidades, las aplicaciones Symfony pueden escalar hasta varios millones de usuarios.
En cualquier caso, mejorar el rendimiento sigue siendo la obsesión de toda la comunidad Symfony. Cuando hace unos meses Fabien Potencier preguntó en la lista de correo de programadores cuáles eran las características más deseadas para la futura versión 2.4, la mejora del rendimiento fue una de las más solicitadas.
Además de las mejoras en el código PHP del framework, desde el ecosistema de Symfony se han probado otras técnicas para mejorar el rendimiento, como pasar parte del enrutamiento al servidor web Apache o ejecutar las plantillas de Twig mediante una extensión de PHP programada en C.
La buena noticia es que pronto todas estas iniciativas podrían recibir un gran impulso debido al flamante fichaje del programador Julien Pauli por parte de SensioLabs, la empresa que está detrás del proyecto Symfony. El propio Julien lo anunciaba en su cuenta de twitter:
I will join @sensiolabs in November to work on Symfony's future, performance, PHP's development, trainings and more.
Julien trabaja actualmente en la popular web para compartir coche BlaBlaCar (que por cierto, también está programada con Symfony2), aunque es más conocido por ser el release manager de todas las versiones de PHP 5.5.x. Además, es un habitual del desarrollo del core de PHP y echando un vistazo a sus gists en GitHub, verás que está completamente obsesionado con el rendimiento de PHP y sus internals. De hecho, sus commits más recientes en GitHub están relacionados con la extensión OPCache de PHP, que es la caché que sustituye a APC en las nuevas versiones de PHP.
Debido a su historial como programador, algunos usuarios de Twitter ya se han lanzado a pedirle que transforme todo Symfony en una extensión de C, para multiplicar exponencialmente su rendimiento (tal y como hace el framework phalcon). Aunque es prácticamente imposible convertir un código tan gigantesco como Symfony en una extensión, sí que se podría utilizar la misma estrategia de Twig y convertir en una extensión solamente aquellas partes de Symfony que más veces se ejecutan o que más recursos consumen.
Por el momento Julien no ha querido confirmar ni desmentir nada de esto, aunque este otro mensaje suyo en Twitter deja entrever que pronto tendremos noticias interesantes sobre la mejora del rendimiento de Symfony:
Let me start my job and you'll get some news guys. I cannot say anything ATM, but the ideas are here.
Comentarios
-
#1
Buenísimo fichaje. Yo más que tirar por el camino de modularizar en c ciertas extensiones lo sentaría al lado del tipo de Doctrine y cerraría con llave puertas y ventanas :P
También habrá que ver como reacciona a OPCache aka Zend Optimizer+ en symfony, espero que aunque 2.3 es LTS se cuente con ello antes de los 3 añitos ... Hay cosas de una importancia que creo que deben pesar aún siendo LTS, y si es verdad esos test de que se gana casi un 25% según leí no hace mucho sobre APC ...
-
#2
Pongo el enlace, me sale entre 5% y 20% según escenario: wiki.php.net/rfc/optimizerplus
-
#3
@Gonzalo, gracias por el enlace. Por rendimiento no hay comparación posible entre ZendOptimizer+/OPCache y APC. El primero es muchísimo mejor y cuando lo activas, Symfony vuela (y Silex se vuelve instantáneo).
De todas formas, quizás pronto sea innecesario utilizar este tipo de cachés, ya que Facebook se está tomando muy en serio hacer una máquina virtual que pueda ejecutar cualquier tipo de código PHP. Han prometido que pronto se podrá ejecutar Symfony y otras aplicaciones complejas en su máquina virtual y entonces sí que el rendimiento será estratosférico.
Respecto a Doctrine, preferiría que alguien les hablara de la importancia de documentar bien los proyectos ;)
-
#4
@Javier Documentar es de cobardes :P ¿Qué hay más divertido que ver tu code dentro de 6 meses y no acordarte por qué haces las cosas?
-
#5
Hola, muy buena noticia que el esfuerzo por el rendimiento sea la prioridad para la proxima version. Pero si se crean estas soluciones como extensiones de C para PHP ¿que pasara con las personas que tengan servidores compartidos?. Al igual que Phalcon ¿se estara obligado a usar un servidor dedicado para las aplicaciones en Symfony2?.
-
#6
@Omar symfony ya 'no es apto' ahora mismo para hosting compartido ya simplemente por la dependencia de apc.
-
#7
Hola @Gonzalo tener instalado el APC tengo entendido es una recomendacion mas no un requerimiento y ahora con PHP 5.5 menos, particularmente tengo aplicaciones con Symfony2 en servidores compartidos y no he tenido problemas hasta el momento.
Saludos cordiales.
-
#8
"@Javier Documentar es de cobardes :P ¿Qué hay más divertido que ver tu code dentro de 6 meses y no acordarte por qué haces las cosas?"
@Gonzalo eso es de valientes :P
@Javier, excelente post, con esto estamos mas enterados de las noticias que ocurren.
Gracias.
-
#9
@Omar si no has tenido 'problemas' has tenido suerte en el hosting (tener las dependencias completas + shell ) y pocas visitas porque en cualquier hosting barato metes symfony y a ellos mismos no les compensa por la cantidad de recursos, sobre todo de i/o que se comsumen sin apc. Otro tema es irte a mediatemple o servergrove que son empresas enfocadas a desarrolladores.
-
#10
Gracias @Gonzalo por tu respuesta pero mi pregunta era referida a la informacion del post de Javier y no sobre empresas de hosting.
Si se van a pasar funcionalidades de Symfony a Extenciones eso hara que sea mucho mas rapido pero dependera de tener acceso total a la configuracion del servidor para instalarlas. Yo no creo que sea el unico que alguna vez a usado servidores compartidos, muchas veces no depende de uno esa eleccion si no del cliente.
Se que existe la forma de cargar .dll o .so en tiempo de ejecucion pero no se si es seguro.
Saludos.
-
#11
@Omar y tendrían que hacer las extensiones para todas las versiones de php debido a que las distros no cambian de versión, parchean.
En 5.5 te pueden ir bien porque si no me equivoco trae cache de serie no se si activado por defecto ... Symfony sin cache opcode no se mueve y mucha culpa la tiene doctrine.
Puedes comprobar si tienes cache con phpinfo() o la propia barra dev de symfony.
Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente
unos meses después de su publicación para asegurar que estos sigan
siendo relevantes.
Proyectos Symfony destacados
La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más
Síguenos en @symfony_es para acceder a las últimas noticias.