Thursday, April 14, 2011

Play! vs Spring MVC - View / Controller performance

Subbu Allamaraju posted an excellent article about Node.js vs Play! for Front-End Apps.

Play! is an excellent Web framework which is quite similar to Spring MVC on the view/controller aspect and is using Groovy as the view technology.

Spring usual views (JSP, JSTL, Freemarker, Velocity) are quite outdated and I do not understand why Spring does not improve them and why Matt Raible set their as a "pro" in his comparaison.

I believe in using the Grails View as the Spring MVC View. See my previous article about the "How To" and according to the Spring MVC roadmap, Grails View support will be added to Spring 3.1.

Let's benchmark Play! vs Spring MVC with Grails View. This microbenchmark will focus only on the view/controller performance.


Test setup

Computer

  • Core 2 Duo @ 3Ghz
  • 6GB RAM
  • Windows 7

Frameworks used

  • Play! 1.2 (standard configuration, production)
  • Spring 3.1.0 M1 (production)
  • Tomcat 7.0.12 (standard configuration, BIO) launch with CATALINA_OPTS equals to "-server -Xmx1024m"

Scenarii

The scenarii are the following :
  1. An empty controller rendering a simple view
  2. A parametrized controller with validation rendering a simple view. I reused a Play! controller from their Yabe tutorial
  3. A search controller rendering a complex view. I reused the Subbu benchmark sources

I run the Spring webapp on Tomcat 7 and I run the Play! webapp on Tomcat 7 and on the embeded server. I used the Apache HttpComponents toolkit to request the servers.

Project

The Spring project is available on github.

Empty controller

Spring Controller


Play Controller


The view


Result



Parametrized controller

Spring Controller


Play Controller


The view


Result



Search controller

"results" is a Json object loaded at startup. This Json contains the results of an Ebay search request. See the Subbu's article for more info.

Spring Controller


Play Controller


The view

I reused the view template of the Subbu project . The Grails View is quite similar.

Result




Conclusion

  • Play! is 25% ahead of Spring on the empty controller test.
  • Spring is 20% ahead of Play! as soon as there is request's parameters.
  • Spring is 70% ahead of Play! on the search test. The gap is quite important.

The most revelant test is the last one. Grails template engine is definitively more optimized than Play! template engine. As Play! and Grails used both Groovy, Play! template engine can clearly be improved.

Another interesting fact is that Play! with Tomcat (BIO) performs better than Play! embedded server ie. Netty (NIO). I don't know why, explanations are welcome!

17 comments:

  1. A rather important things you left undisclosed: your actual benchmarking scripts, jvm arguments, component making the requests.

    These benchmarks sure sound like the perfect ones for blocking IO connector (BIO). Also, was Connection: keep-alive used? The reason I think these are perfect for BIO is that you have a very short "actual logic part", whereas if your code would do database lookups, anything requiring even more blocking it might have beneffited the jetty NIO.

    Is the "thread" parameter of your graphs the server or client side threads? If client side, what kind of was the server side configuration?

    ReplyDelete
  2. I used the standard Tomcat configuration which is available here (The maxKeepAliveRequests is set to 100). I do not modify Play! configuration too.

    The component making the request used Apache HttpComponents with a simple "start time, request, end time, compute the delta" pattern.

    I can put the source on github on demands.

    Note : Play! used Netty not Jetty anymore.

    ReplyDelete
  3. what's the load generator and at what concurrency?

    ReplyDelete
  4. Very nice - thanks for this!

    Could you open source what you used to test this or even better do the same with a simple grails setup

    would love to see how that performs vs this mix.

    ReplyDelete
  5. I have put the project on Github.

    The Play! project will follow after my vacation.

    ReplyDelete
  6. Nice article , you have indeed covered topic in details with sample code and graphics, its indeed a topic which require a deeper understanding than many other java topics.

    Javin
    How Garbage collection works in Java

    ReplyDelete
  7. Grails 1.4 brings a lot of performance tweaks : compile-time injection, GSP optimization to statically calls output methods, singleton scoped controllers, use of methods instead of closures... I hope to see better results for this test and similar ones by using the Grails groovy controllers.

    Interesting way of use by the way.

    ReplyDelete
  8. Thanks pred for this information.

    I will test with Grails 1.4 GSP and with Grails controllers.

    ReplyDelete
  9. I like both grails as well as play, but I started working with play more coz when I check the memory footprint, I realize with grails I will have to pay atleast 6 times more than play framework. Although play view is little slower, it is more easier to work with than grails gsp. I also remember the initial days of grails when it was getting slammed from every quarter for the slowness of GSP, I hope play will get better in this area in upcoming releases.

    ReplyDelete
  10. Hi,

    with the new scala template system (can be ported to java in future release) there is no performance penalty now because of groovy templating. If you benchmark it with this new system there probably be huge speed improvements.
    http://groups.google.com/group/play-framework/browse_thread/thread/cab3a12178bea69c

    ReplyDelete
  11. Hi Anonymous,

    I will update as soon as Grails 1.4 will be updated.

    Grails 1.4 will contain GSP improvment.

    ReplyDelete
  12. Here is another benchmark for template rendering performance of Play! :
    http://code.google.com/p/cambridge/wiki/UsingWithPlayFramework

    ReplyDelete
  13. I'd love to see these benchmarks again using Play 2.0 (which uses Scala compiled templates)! Should be considerable speed increases seen here (and the integrated web server, providing it's running in prod mode, should speed things up further)

    ReplyDelete
  14. As soon as content comes to the seen, long term objects make gc tasks dificult. Play static controllers are a "easy" "hack" for concurrency problems and reflection performance but all that comes with a heavy price app mem foot print becomes way to big. You can easly check this if you check the early versions of play you would see multiple concurrency problems. Play is nice idea but not somethin you use for real projects.

    ReplyDelete
  15. Real Trainings is provides all IT-Training and Non-IT Training Institutes information in Hyderabad, Bangalore, Chennai and Corporate Trainings Companies information and Real time Trainers information at one place. In Real Trainings Students can Compare all Institute's Courses with all detailed information.

    ReplyDelete