10 Replies Latest reply on Aug 4, 2010 4:54 PM by maricool

    Seam Performance vs other Frameworks

    rowan

      I am currently testing the viability of using Seam for a web application and a major factor for the app is performance under high load.
      Has anyone conducted performance studies or have performance metrics to compare Seam to say, Spring MVC?


      I am interested in using Seam to cut down on development time, yet the performance overhead of the framework cannot be too burdensome.

        • 1. Re: Seam Performance vs other Frameworks
          asookazian

          I am unaware of performance benchmarks and/or comparisons with Spring MVC.  Spring offers the JdbcTemplate which Seam does not have so typically we use JPA with Hibernate as persistence provider or JDBC (legacy stored procs).  Spring MVC is also somewhat complicated with the DispatcherServlet and various other servlets used as controllers.  There is no front controller in JSF.  In Seam, a JSF page invokes a method directly on a backing bean class.  You are comparing a stateless framework (Spring) vs. a stateful framework (Seam).


          There is overhead associated with using JSF with Seam.  There is a very good article on performance optimizations here:


          http://jsfcentral.com/articles/speed_up_your_jsf_app_1.html


          You may get better performance using one of the alternative view technologies like GWT, Flex or Wicket, for example, but I have not seen any case studies on this yet.


          Seam makes very heavy use of interception and proxying to facilitate bijection, for example.  In some cases, you may need to use @BypassInterceptors as a performance optimization.


          It also matters whether or not (and how) you use caching strategies like Hibernate 2nd level cache and the <s:cache> page caching tag.  The long-running conversation and PersistenceContext are also part of the caching technologies in Seam.


          You will need to write an app (or use the booking project example) and run load tests to get some benchmarks on transaction throughput, etc. 


          Seam 3 will be targeting JSF 2.0 and JPA 2.0 so you may want to stay tuned for that as well (currently in alpha).  Most likely there will be performance optimizations in that version as well.

          • 2. Re: Seam Performance vs other Frameworks
            asookazian

            And don't forget that with heavy use of SFSBs, you need to consider your question in context of a cluster or stand-alone JBoss AS.  State replication amongst the nodes for SFSBs and HttpSession can cause some performance degradation as well, I'd imagine...

            • 3. Re: Seam Performance vs other Frameworks
              rowan

              Thanks for your reply Arbi.



              Arbi Sookazian wrote on Aug 11, 2009 06:43:


              You will need to write an app (or use the booking project example) and run load tests to get some benchmarks on transaction throughput, etc. 



              This is along the lines of what I was hoping someone had already done, with the results compared to other frameworks.


              This is the type of information that solution architects are very concerned about and I understand it depends quite a bit on configuration however in order to make informed decisions some kind of performance comparison study would be very helpful.


              • 4. Re: Seam Performance vs other Frameworks
                jeanluc

                My experience of several months with Seam is that there are some inherent speed bumps introduced by JSF and bijection. For UI controls with many elements (tables, dropdown boxes), the bottleneck is not at all the database (even without 2nd level caching), but the time spent by Seam during the RenderResponse phase. The heavy use of bijection and events (see, for instance, org.jboss.seam.core.MethodContextInterceptor.aroundInvoke() which sets 5 context variables, each creating 2 events) has a visible impact on the page rendering time and we found it is hard to reduce it. There are only a few tools: bypassing interceptors, use <s:cache> and rethink the UI interaction to have lazy loading of data in UI controls or have autosuggestions instead of populating lists. It is somewhat frustrating to constantly have this conflict between using the framework for its features and avoiding the framework for its slowness. I don't know if I can ever make the app really snappy (say, have responses back in less than 100ms).


                • 5. Re: Seam Performance vs other Frameworks
                  asookazian

                  Jean Luc wrote on Aug 11, 2009 16:24:


                  My experience of several months with Seam is that there are some inherent speed bumps introduced by JSF and bijection. For UI controls with many elements (tables, dropdown boxes), the bottleneck is not at all the database (even without 2nd level caching), but the time spent by Seam during the RenderResponse phase. The heavy use of bijection and events (see, for instance, org.jboss.seam.core.MethodContextInterceptor.aroundInvoke() which sets 5 context variables, each creating 2 events) has a visible impact on the page rendering time and we found it is hard to reduce it. There are only a few tools: bypassing interceptors, use <s:cache> and rethink the UI interaction to have lazy loading of data in UI controls or have autosuggestions instead of populating lists. It is somewhat frustrating to constantly have this conflict between using the framework for its features and avoiding the framework for its slowness. I don't know if I can ever make the app really snappy (say, have responses back in less than 100ms).




                  These are all very good and valid points.  There are some Seam shops which are not using bijection at all except for injection of SMPC, for example. 


                  To describe this in more detail using an example, you can get the FacesMessages instance two ways:


                  @In FacesMessages facesMessages;



                  or...


                  FacesMessages.instance();



                  The first way is dynamic injection which means the injection happens before any business method invocation.  The second way happens when it needs to happen in the actual business method itself.  This means that there is no excessive injection and refreshing of the instance variable happening in methods that do not use the FacesMessages instance (which is a performance hit).


                  I have submitted a JIRA: https://jira.jboss.org/jira/browse/JBSEAM-4349 to give us the ability to do static injections in Seam component if desired via the addition of a type element in the @In annotation.


                  But if you think about it, how many Fortune 500 companies are using Seam for high transaction, external-facing apps?  Most of these are .NET or Spring/Hibernate or even RoR with Scala (e.g. Twitter).


                  In any event, it would be nice, at a minimum, if JBoss did a benchmark using Seam 3.x and JBoss 5.x with JSF 2.x vs. the current stack (JSF 1.2 and Seam 2.x and JBoss 4.x) to see what the performance increases, if any, are.


                  I'm not sure that a benchmark or performance analysis exists for Seam 1.x and Seam 2.x.


                  The bottom line is this: are you developing highly scalable (thousands of simultaneous clients) and highly transactional applications?  If so, you need to understand the JSF life cycle and Seam interceptor stack and how you can optimize it.  Otherwise, you may want to look at Wicket/Seam integration.


                  Like Jean Luc stated, Seam has many added features that other stacks do not have, but as far as performance is concerned, it may not be the most performant which may be one reason why its adoption in the JEE industry is limited even after 3 years of the initial release.


                  Seam 3 will have Web Beans as its core, so things will be changing a lot.


                  This is a very good topic to discuss but unfortunately, the Seam core devs do not post a lot in this forum nowadays...

                  • 6. Re: Seam Performance vs other Frameworks
                    jeanluc

                    This is a very good topic to discuss but unfortunately, the Seam core devs do not post a lot in this forum nowadays...

                    Indeed - and I saddened by this after having worked with Spring and even Tapestry (whose author is very active on the forums). Sometimes I wonder if Seam is not seen as just by RedHat as a fringe project with no revenue potential and thus of little priority. In contrast, Spring had SpringSource behind it which was actively interested in promoting Spring and getting revenue out of it through consultancy and training. I wonder if Seam is not going on simply through the passion of its (not many, I guess) developers and the related efforts with WebBeans...

                    • 7. Re: Seam Performance vs other Frameworks
                      asookazian

                      Jean Luc wrote on Aug 11, 2009 17:53:


                      Sometimes I wonder if Seam is not seen as just by RedHat as a fringe project with no revenue potential and thus of little priority.


                      Well that if you think about the fact that most Seam projects are deployed (I'm assuming) on either JBoss or Tomcat, that would mean additional EAP support contracts for Redhat.  If customers use the dev stack (esp. in production deployments) there is the big possibility of conulting engagements and potentially lucrative support contracts.


                      So the more Seam apps are deployed in prod, the better for Redhat, no?


                      (sorry, this has nothing to do with the performance topic)


                      Redhat/JBoss needs to spend much more time and money on marketing/sales for Seam, otherwise it's the great integration framework that nobody ever used in production.  There are only about max 30 guys on this forum every day...

                      • 9. Re: Seam Performance vs other Frameworks
                        boomerbrian.brian.abston.featurenotbug.com

                        Seam just doesn't appear to have the Evangelists spreading the word like in the Rails community. I started using Seam a few months ago and I am loving it. It has some really nice features that has been missing in the Java world but you just don't see many people talking about it and promoting it. The community almost feels dead whereas the Rails community feels very alive. You can find several podcasts, blogs, and video casts on Rails but there just isn't much there about Seam.

                        • 10. Re: Seam Performance vs other Frameworks
                          maricool

                          Hi,
                          On my blog I present several solutions to optimize. Far is not enough, because I do not have time to add, but soon complement deficiencies: JBoss Seam performance