Performance Profiling with JBoss Seam – Part 1


So, I decided I had had enough of looking at 400-600ms server prep times for Seam pages on a project we’re working on. It just didn’t seam right – could the Seam framework really have this much of an impact on performance?

I did some digging, and I came up with some interesting baseline stats. These were done by actually just adding a new webpage to an existing app (kind of, let’s see how fast we can make this app go approach).

I tried initial testing between a simple page and a page that used a <ui:composition> and found no difference in performance, so all the tests below use a simple XHTML page that is a composition with a backing template and a single region insertion. The page uses a single <h:outputText> component that displays a value from a message bundle for the HTML title.

I tested out the following scenarios, here there are with my results:

1. Basic Page

  • 32.898ms mean request time across 1000 requests with 4-threads
  • ~30.4 tps

2. Basic Page with 12 <h:outputText> components on it that call a simple method on a stateless POJO Seam component

  • 33.048ms mean request time across 1000 requests with 4 threads
  • ~30.3 tps

3. Basic Page with 12 <h:outputText> components on it that call a simple method on a stateful (Conversation scope) POJO Seam component

  • 44.142ms mean request time across 1000 requests with 4 threads
  • ~22.7 tps

4. Basic Page with 12 <h:outputText> components on it that call a simple method on a Stateful EJB (Conversation scope) component

  • 51.981ms mean request time across 1000 requests with 4 threads
  • ~19.2 tps

5. Same as # 4, but I added injection of the Seam logging handle, the Seam Identity component and a Seam managed Hibernate Session handle

  • 78.249ms mean request time across 1000 requests with 4 threads
  • ~12.8tps

As you can see, the base processing time introduced by the Seam framework is negligible. On very high capacity sites that do not require EJBs you might consider using POJO components that will gain you about 10% performance over the EJB infrastructure.

As you can see by test #5 above, when you start injecting components beware of overhead. My testing was very simplistic, just using Apache “ab”, which means every single request included the overhead of creating the session and conversation scopes – and in the case of # 5, also includes setup of the Log, Identity, and Hibernate Session handles.

As a result, test # 5 above is a little unfair, because most requests are going to be repeat requests from the same visitors, which will not include this overhead.

I’m fairly pleased with Seam, and this testing allays my fears about it sucking too much performance from an application from a framework perspective. Now to quantify some of the effects of the techniques we’re using on these other projects.

It’s not at all surprising to note that your approach to a Seam web application design can have considerable impact on the performance of your application. Techniques that work well in other environments (ie. PHP, Rails, and other highly horizontally scalable “shared-nothing” environments) do not work well in Seam.

This should not be surprising, as the whole value of Seam is in the contextual component model, where you have shared resources that allow you to do things like save yourself round trips to the database and should theoretically allow you to scale a single instance of an application higher than “shared-nothing” environments.

Stay tuned for part 2, where I will examine in more detail ajax interaction timing and general Seam application design.


4 thoughts on “Performance Profiling with JBoss Seam – Part 1

  1. Fijaicairo

    Great post. Thanks for sharing your experience. Seam is easy to develop in but my first cut of our first Seam app has yielded some very horrific performance stats that make me rather nervous.
    I think I will be switching my apps components from session beans to regular pojos. The EJB3s served me well in a single server environment but have been a pain to deal with in a clustered environment.

  2. Tobias


    We had the same experience with the cost of injections in seam
    and actually had to change parts of our application into using a
    view specific DTO-pattern instead. Sad but true. See this post for

    What we also found out (much to my astonishment) that it isn’t always a 1-to-1
    mapping between the number of bean references on your page and the actual
    number of invocations on the beans. This becomes very apparent when you
    have complex page layouts with lots of fragment-compositions. For instance
    I could remove one #{pojo.ref} on the page and reduce the number of times it
    was called by 15-20. How about that. : /

  3. thiagu

    Great post. what about sate less EJB performance.
    if i need to maintain the state, i am using the entity beans with transient variables or DTO’s with different scope type.
    i think this will give us better performance

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s