Interesante y detallada comparativa de rendimiento de frameworks web
Hace poco más de un mes la empresa TechEmpower publicó en su página web una comparativa de rendimiento de varios framework web que usan múltiples lenguajes: Java, Ruby, Python, PHP… Los test de rendimiento se realizarón tanto en la nube (una instancia de EC2) como en una máquina dedicada i7. Este post original incluía aproximadamente un par de docenas diferentes de framework web.
Además, la empresa publicó todo el código fuente empleado en todos los benchmark en GitHub, y animó a todo el mundo a enviarles pull request con mejoras para los test de rendimiento, ya que su objetivo era que cada framework/lenguaje de programación tuviese un rendimiento óptimo en los test. También invitó a la gente a enviar nuevo código fuente de nuevos framework que ellos no habían medido originalmente.
La comunidad ha respondido, y a las aproximadamente dos docenas de framework web que originalmente incluían se han añadido muchos otros, llegando sumar casi un ciento de frameworks web incluidos en la comparativa de rendimiento.
Java queda bastante bien en general, en especial el framework Gemini de la fundación Eclipse, emplear Servlets directamente, Wiket y Spring, quedando éstos siempre en el top 10 de todas las pruebas. Una de las cosas curiosas de las pruebas de rendimiento que han ejecutado es que hay algunos framework que tienen un mejor rendimiento en la nube (al menos en la de Amazon) pero después tienen un peor rendimiento al tener la máquina dedicada. Es el caso de, por ejemplo, Go, el lenguaje de programación de Google.
Comentando algunos resultados más relacionados con Java, Grails tiene un rendimiento aproximadamente igual a la cuarta parte del rendimiento de las mejores soluciones como Gemini o Servlets directamente, y el framework Play corriendo sobre Scala también tiene menos de la mitad de rendimiento que estas soluciones; Play corriendo sobre Java en vez de Scala tiene un rendimiento pésimo, muy inferior al de Grails y aproximadamente igual a la tercera parte del que tiene corriendo sobre Scala.
Aquí tenéis los resultados completos del benchmark. Es interesante filtrarlos mediante el panel que está en la parte alta de la página.
Reader Comments (13)
So interesting
Good morning chavales
Sin casarme plenamente con los resultados, a los que siempre hay que evitar considerar como sagrados (aunque han repetido como cuatro veces el benchmark con mejoras dando más o menos los mismos resultados), es muy interesante para poner números en vez de berborrea, especulación y "creencias".
Por otra parte, aunque no he encontrado algo tan básico como es la configuración de pools de hilos, es interesantísimo ver que el mito del mono-hilo mágico de altísimo rendimiento y escalabilidad promovido por tecnologías tal y como Node.js y Vert.x sigue sin tener benchmarks que lo respalden, aunque en estos resultados hay una base de datos por medio que desvirtúa este aspecto.
En favor del benchmark "con Spring" hay que decir que más bien es "Hibernate con Spring", el lugar que ocupa en la tabla de resultados no necesariamente hay que achacarlo a Spring, Hibernate es muy práctico para el programador pero tiene un precio.
"casi un ciento de frameworks"??? será una centena ;)
Por otra parte, me hubiera gustado ver JSF y Struts 1/2
Buena comparativa. Yo igual que Roberto, echo de menos Struts 2
Pues si alguien echa de menos algo (JSF, Struts o lo que sea) que se arremangue los brazos y a contribuir el código al proyecto de GitHub :)
"Play corriendo sobre Java en vez de Scala tiene un rendimiento pésimo, muy inferior al de Grails y aproximadamente igual a la quinta parte del que tiene corriendo sobre Scala."
En la última versión (Round 4) no veo eso ni por asomo. Play sobre java tiene un rendimiento que es aproximadamente la mitad que con Scala
@golthiryus
Supongo que depende de los datos que se mire, de los que hablaba desde la imagen que he puesto sobre el rendimiento en el i7; play-scala: 22.3%; pla-java: 7.2%. Y sí, es la tercera, no la quinta parte, según estos datos. Lo he corregido.
Un tutorial de gemini?
Muy interesante.
Ahora, tengo la siguiente duda:
¿A que se refieren con "servlet"? Supongo que es que hacen todo 'a mano' sin frameworks y a eso va la pregunta.
¿No se supone que la base es esa?
Los frameworks le añaden una capa al servlet pelado, por lo cual todo framework podría ser considerado para la 'categoría' servlet.
No sé si se entiende mi razonamiento. Pero la idea sería que gemini (que no lo conozco) se podría pensar como un 'servlet mas complejo'.
Alguien que me pueda iluminar un poco que no termino de entender.
Bueno, y ahora todos los que hablan y han hablado de "java para la web es muy lento" q van a decir?
Abraham, si tú me regalas el i7 yo hago la de Struts. Es totalmente ilógico, que en una comparativa tan extensa no esté Struts 2.
los frameworks son para lamers.
amigo @Mario no es necesario que tengas una i7, basta con que colabores con el código y ellos lo agregan a sus pruebas.