Performance decrease when ported to Seam

[canon]

I have an website running at:
-Hibernate
-C3P0 (db pooling)
-MySQL
-Tomcat
-Servlets/JSP/a bit JSF

Which I have ported with Seam-Gen to:
-JPA using Hibernate
-Seam
-JBoss 4.2 / EJB
-MySQL
-Facelets/JSF

I notice a performance decrease in showing DB data. The performance is now about 75%-50% of that without JBoss seam.
Even when I only perform just one HQL/JPA QL query from a Stateless session bean.

At the moment I haven't found the exact cause of this performance decrease. The same DB queries are performed in the background.

Anybody else noticed something like this? What might be the cause?

[leonardinius]

Maybe JSF UI bindings and Seam interceptors causes this decrease?

What do you really mean with performance decrease? (What? How? Deployed as war/ear? Jboss/Tomcat comparision? Measures?)

[canon]

With performance decrease, I mean increase in response time.

I measured the response times using:

• a stopwatch while browsing through 26 pages in a sequence.


• I have also used Apache's HTTP AB (benchmark) to measure HTTP response times, but this one causes new Sessions on each request because all requests are independent, so probably not a good method to measure.


• The number of milliseconds to perform a DB request using Hibernate or JPA. Which I measure by doing new Date().getTime, and then compare begin and end times.

I'm using the same DB in both the Seam solution and my previous solution (without Seam). The same DB queries were seen using a DB monitor.
All methods show that the full stack Seam solution is slower.

Examples:

Seam approach

-

A stateless page scoped EJB bean (which is also a Seam component). Deployed in a EAR.

@Stateless

@Name("modelManager")

@Scope(org.jboss.seam.ScopeType.PAGE)

public class ModelDAOBean implements ModelDAO {


    @PersistenceContext

    private EntityManager em;


.....


    @Override

    public List<Model> getModels() {

        Long begin = new Date().getTime();

        List<Model> models = em.createQuery("select m from Model m where name like ?  and m.notVisible is null order by m.name")

           .setParameter(1, queryString)

           .getResultList();

        Long end = new Date().getTime();

        System.out.println(end - begin);

        return models;

    }

.....

}

The view using facelets

#{modelManager.models}

As println output, I get round 580ms for the JPA query.

Without Seam approach

-

My previous solutiong using plain Hibernate, Servlets and JSP/JSF, Tomcat. Deployed in a WAR. Servlet code

Session session = HibernateUtil.getSessionFactory().getCurrentSession();

Transaction tx = session.beginTransaction();


List<Model> models;

Long begin = new Date().getTime();

models = session.createQuery("from Model where name like ? and notVisible is null order by name").setString(0, letterQuery).list();

Long end = new Date().getTime();

System.out.println(end - begin);


request.setAttribute("models", models);

RequestDispatcher view = request.getRequestDispatcher("/models.jsp");

view.forward(request, response);


tx.commit();

And the JSP view:

${models}

Results using Servlets/JSP/Hibernate: Println output shows round 310ms.

Conclusion:

The Servlets/JSP/Hibernate/Tomcat approach performs Hibernate queries about twice as fast as the Seam/JPA/EJB/Facelets/JBoss approach.

Can these slow DB Lookup response times be caused by Seam Interception?

[barbacena]

Scoping components in page scope, at least in my tests, decreases performance as this is backed by JSF impl.

Could you re-run your test scoping your dao component in session scope?

[canon]

Marcell Barbacena wrote on Jun 05, 2008 19:45:


Scoping components in page scope, at least in my tests, decreases performance as this is backed by JSF impl.

Could you re-run your test scoping your dao component in session scope?

Just tested it. Changing to session scope didn't result in a change in response time in my system.

Also note that in my tests above, a single JPA query was significant slower when performed in a Seam environment than when performed with Hibernate without Seam. (Which is outside the reach of JSF and Facelets.) If Seam is intercepting JPA calls, then the slowdown could be caused by Seam.

Other possible causes that I need to rule out are: different Hibernate versions in which one version might perform faster; maybe the JPA wrapper (over Hibernate) has some extra overhead; maybe EJB is causing JPA to be slower... etc.