9 Replies Latest reply on Jan 31, 2010 12:59 PM by Eric K.

    EJB3 slower than EJB2

    Eric K. Newbie

      Hi everybody,

      im currently working on an Migration Project from EJB2 to EJB3. Now I'm doing some testing and this problem is driving me crazy.

      I'm using JBoss 5.1.0.GA and an Oracle Database Version 11g.

       

      In the each Session Bean I have a method who is doing a create. And the task is to do a create 10000 times in a row. Once in EJB2 (old Version) once in EJB3 (new version). And to my suprise the EJB2-create-Method is nearly twice as fast: 31 Seconds in EJB2 compared to 67 Seconds in EJB3. How is that? I've tried a lot of things: Changed Transaction Types, Tested JBoss 6, etc.

       

      What is interesting: I've mesured the Data going from the Client to the Server and back. Result: The Data beeing received by the Client is nearly the same. But the Data beeing send to the server, during the process, is aprox. double! When I use a local JBoss Server an the remote Oracle Database, the Process is getting faster in EJB3. Makes sense. Can you tell me why the amount of Data is so different? Is there so much more Overhead in EJB3?

       

      I have a very simple testing example in EJB3: Remote Interface ->  Session Bean -> Entity Bean.

       

      I'm using a JUnit3 Test-Case which does the following in Version 2...

       

      /**
           *
           * @throws Exception
           */
          public void testCreateEJB2() throws Exception {
             XyzDto xyzDto = new XyzDto();

       

              for (int i = 0; i < id_old.length; i++) {
                  id_old[i] = xyzBD.createXyz(xyzDto);
              }
          }

       

      ... and Version 3:

       

         /**
           *
           * @throws Exception
           */
          public void testCreateEJB3() throws Exception {
             
      EntityBean bean = new EntityBean();

       

              for (int i = 0; i < id_neu.length; i++) {
                  id_new[i] = Remote.
      createBean(bean);
              }
          }

       

      "id_new/old.lenght" is 10000.

       

      This is the create-Method:

       

      @Stateless

      public class ...Bean$$$ implements ...Remote$$$ {

       

          @PersistenceContext
          EntityManager em;

       

          public Integer createBean() {
              Integer number = new Integer(1);
              EntityBean bean = new EntityBean();

       

              if (this.selectMaxID() == null) {
                  number = 1;
              } else {
                  number = this.selectMaxID().intValue() + 1;
              }

       

              bean.setId(number);

       

              em.persist(bean);
              bean.setBLocked(true);
              return bean.getId();
          }

           ...

      }

       

      The selectMaxID-Method. It gets the smallest possible ID from the Database.

       

      public Integer selectMaxID() {
              Query query = em
                      .createQuery("SELECT max(u.id) FROM xyz u");
              Integer maxID = (Integer) query.getSingleResult();
              return maxID;
          }

       

       

      So to the EJB2 Version: There is a Delegate-Class who uses a Session Facade Bean and the "Dto"-Pattern-Object to create the Entity...

       

      public Integer createBean(xyzDto xyzDto) throws EJBException {
          Integer nPrimaryKey;
          if (xyzDto == null) {

          }
          try {
           
      Xyz xyz = xyzHome.create();
            setXyzFromXyzDto(
      xyz, xyzDto);
            nPrimaryKey = new Integer(((Integer)
      xyz.getPrimaryKey()).intValue());
           
      xyz.setBLocked(true);
          } catch (Exception e) {
            throw new EJBException(e.getMessage());
          }
          return nPrimaryKey;
        }

       

      ... and in the ejbCreate of the Entity there is the same "selectMaxID" (same SQL Statement) as mentioned before.

       

      public Integer ejbCreate() throws CreateException {
          Integer number = new Integer(1);
          try {
           
      number = this.ejbSelectMaxID().intValue() + 1;
          } catch (Exception e) {
          }
          setId(
      number);
          return null;
        }

       

      I hope you have any ideas why the new Version is so slow. I'm sorry if I forgot to provide any data or if this post is in the wrong format.

       

      Thank you.

        • 1. Re: EJB3 slower than EJB2
          Eric K. Newbie

          I've found out, that the Traffic using the EJB3 Version is a lot heavier than with EJB2.

          During 10000 creates, the Data send from the Client to the Server is almost twice as much.

           

          Does anybody know why? Thank you.

           

           

           

          Received Data

          Send Data

          EJB2

          5,4 MB

          22,4 MB

          EJB3

          8,7 MB

          38,9 MB

          • 2. Re: EJB3 slower than EJB2
            jaikiran pai Master

            What kind of data difference are you seeing? And are these JPA entities that you are testing?

            • 3. Re: EJB3 slower than EJB2
              Eric K. Newbie

              Thanks for your respond. What difference do you mean? It takes longer (almost twice as long) for the 10000 creates to finish in EJB3.


              As you can see in my first post.

               

              I'm using normal Entity Beans in both Versions with the same fields and getters/setters.

               

              EJB3:

               

              package ...

               

              import java.sql.Date;

               

              import javax.persistence.Column;
              import javax.persistence.Entity;
              import javax.persistence.Id;
              import javax.persistence.Table;
              import javax.persistence.Transient;

               

              @Table(name = "...")
              @Entity(name = "...")
              public class ...$$$ implements java.io.Serializable {

               

                  /**
                   * private static final long serialVersionUID = -5953089278565486983L;
                   */

               

                  boolean bLocked;
                  private Integer id;
                  ...

               

                  public void setBLocked(boolean bLocked) {
                      this.bLocked = bLocked;
                  }

               

                

                   ...

               

                  @Id
                  @Column(name = "ID")
                  public Integer getId() {
                      return id;
                  }

               

                  @Transient
                  public boolean getBLocked() {
                      return bLocked;
                  }

               

                 ...
              }

               

              EJB2:

               

              package ...;

               

              import javax.ejb.EJBLocalObject;
              import java.sql.Date;

               

              public interface ... extends EJBLocalObject {

               

                public void setBLocked(boolean bLocked);

               

                public boolean getBLocked();

               

                   ...

              }


              package de.ibs.pakt.hilfetext;

               

              import javax.ejb.EntityBean;
              import javax.ejb.EntityContext;
              import javax.ejb.CreateException;
              import javax.ejb.RemoveException;
              import java.sql.Date;
              import javax.ejb.FinderException;
              import java.util.Collection;

               

              public abstract class ...Bean implements EntityBean {

               

                EntityContext entityContext;
                boolean bLocked;

               

                public Integer ejbCreate() throws CreateException {

              ...

              }

               

              I hope that answers your question.

              • 4. Re: EJB3 slower than EJB2
                Eric K. Newbie

                If made a screeshot, I hope this makes the problem clearer.

                I create, update and remove the same number of Entities. You can see that the EJB3 TestCase is very slow, compared to the EJB2 Test Case.

                 

                But why? I Expected it to be faster. It seems like much more traffic in the EJB3 Version. My thought: More Overhead in EJB3?

                 

                Test.png

                • 5. Re: EJB3 slower than EJB2
                  Andrew Rubinger Master

                  Thanks for your observations.  They're consistent with what we've found as well.

                   

                  In EJB3 now we've had some discussions about our wire protocol and the objects sent during each invocation.  The output of this work should be a mechanism compatible w/ the new Interceptors 1.1 (from EJB 3.1) specification, and be much trimmer in its profile.

                   

                  S,

                  ALR

                  • 7. Re: EJB3 slower than EJB2
                    Eric K. Newbie

                    Thank you for your reply.

                     

                    Is there a chance for me to test that new implementation?

                     

                    I'm at the moment working on my bachelor thesis: Migrating from EJB2 to EJB3.

                     

                    At this point of my testing work it's hard to explain why EJB3 is slower, while we thought it should be faster.

                     

                    Any Ideas?

                     

                    Thank you very much.

                     

                    EDIT: I've allready tested JBoss6.0.0.M1.

                    • 8. Re: EJB3 slower than EJB2
                      Andrew Rubinger Master

                      ekric wrote:

                       

                      Thank you for your reply.

                       

                      Is there a chance for me to test that new implementation?

                       

                      I'm at the moment working on my bachelor thesis: Migrating from EJB2 to EJB3.

                       

                      At this point of my testing work it's hard to explain why EJB3 is slower, while we thought it should be faster.

                       

                      Any Ideas?

                       

                      Thank you very much.

                       

                      Unfortunately we don't yet have this in place to test.  Requires some more discussion, work/coding, then integration.

                       

                      As a general issue though:

                       

                      What would lead you to conclude that EJB3 is necessarily faster than EJB2?  They're different specification versions of a programming model, and speed is a function of the underlying implementation.  In many scenarios we've found that our EJB3 implementation is faster than in previous versions, and we work to improve this as time goes on.  This case here is clearly slower, but that's not a function of the programming model itself.

                       

                      S,

                      ALR

                      • 9. Re: EJB3 slower than EJB2
                        Eric K. Newbie

                        Okay. The answer is clear, it has something to do with the traffic caused by the Server and it's protocols and has nothing to do with the programming model.

                         

                        I allready thought about doing some other tests, that show that the new Implementations used aren't slower.

                         

                        But it was my task to do exactly these tests. So I was the unlucky one to find that bottleneck...

                         

                        Would you advise me to do some other tests? If yes, which ones would you do?

                         

                        Thank you and have a nice sunday evening.