Help

Built with Seam

You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.

Framework profiling is an important aspect of providing an enterprise ready application. This page describes the plans, procedures, and eventually results used in profiling the Seam framework. Most of the profiling will be done through existing Seam examples so it can also provide insight into how to profile your own application.

Tracking of current activities and issues will be through the Seam Jira page with references here as appropriate. TODO perm link to jira performance search.

This is a living document and will be updated as possible with more detailed information.

First Iteration

The first step of this profiling effort will revolve around deploying Seam 2.0.X example applications to JBoss AS 4.2.2. This will provide a baseline of functionality and will hopefully highlight any obvious issues. This will be done using different methods, but will include JProfiler, SeamTest, and JSFUnit where appropriate.

More to come

Second Iteration

An analysis of the existing Seam examples will be made to identify gaps in functionality and community concerns. Where needed additional examples will be created that can help to isolate and focus on specific functionality.

More to come

Release process integration

More to come

Container specific performance

  • JBoss AS 5
  • IBM Websphere
  • BEA Weblogic
  • Glassfish
  • Tomcat (with and without embedded EJB)

More to come

Automation

Eventually appropriate aspects of performance profiling will be automated and added to the continuous integration builds. This will provide rapid feedback to users and contributers on changes in performance. Hopefully this will include build by build trending of changes in key performance metrics. At first this will likely be limited to JSF lifecycle timings on a few key integration tests.

More to come

Specific Concerns

  • <s:convertEntity /> - Performance of EntityConverter
  • Stateless scoped components - we should look into somehow pooling stateless component instances for re-use to improve performance. Case in point - org.jboss.seam.core.Events - changing the scope of this component from STATELESS to EVENT resulted in a massive decrease in the object instances created per request, from between 500-600 instances (about 4k of memory allocation) down to just 5 instances (40 bytes).
  • implementation of the Map in org.jboss.seam.international.Messages

More to come

Tools

  • JSFUnit JBoss project to help with unit and integration testing of JSF applications.
  • SeamTest internal testing with testNG
  • JProfiler will be used for the majority of application profiling. Thanks to ej-technologies for providing open source licenses.
  • TBD
3 comments:
 
27. Apr 2008, 07:02 CET | Link
mgrouch

Just wanted to throw in some ideas:

  1. You can profile using Eclipse TPTP
  2. You can check code with findbugs, it gives performance related tips
  3. Use 'final' keyword everywhere where possible (and static for methods where appropriate)
  4. Avoid reflection at all cost
  5. Some API calls for dealing with annotations are slow. Cache results of reading annotations.
  6. There are many scopes in Seam so during EL evaluation Seam is doing lookups in through many of them (repeatedly)
  7. At render phase there is some reformatting done. This should be avoided. It should be responsibility of the UI component library to produce correct output in the first place.

It seems to achieve decent performance with JSF you have to improve it bit by bit everywhere.

ReplyQuote
 
16. Jun 2008, 17:32 CET | Link
mgrouch wrote on Apr 27, 2008 07:02:
Just wanted to throw in some ideas:
  1. You can profile using Eclipse TPTP

No, you cannot profile using Eclipse TPTP.

 
Please don't forget to rate

I believe that imagination is stronger than knowledge -- myth is more potent than history -- dreams are more powerful than facts -- hope always triumphs over experience -- laughter is the cure for grief -- love is stronger than death.

ReplyQuote
27. Apr 2008, 07:11 CET | Link
mgrouch

I remember (it was a while ago) that EntityConverter needs to figure out Id value from passed bean object. This is done via reflection and reading annotations for @Id. Instead we allowed user to override this on converter level (so yes we had converter class per entity), but it did improve performance of EntityConverter dramatically.

ReplyQuote
Post Comment