3 Replies Latest reply on Apr 17, 2002 8:12 AM by crobert

    EJB performance penalty on custom types

    crobert


      Hello,

      I'm having some problem with EJB performance on Jboss 3.0.0a

      My sample applications is:
      - a stateless EJB with one remote method which takes:
      - a String parameter
      - a long parameter (the timestamp in the client just before calling the remote method.)
      - a custom type parameter. The custom type parameter is a simple class which has about 10 instance variables String and with bean-like get/set method.
      The bean simply returns a hardcoded custom type value in a java.util.Vector.
      - a client which connects to this stateless EJB

      And in the bean, the first line of the remote method gets the current timestamp. Being on the same machine with the client and server, it made sense to make this
      measurement, as the reference clock is the same. I'll name this "invocation time" (although it's not entirely correct): the time between the moment just before the remote method invocation in the client and the moment in which the first statement in the remote method of the bean is executed.

      When running in the above setup, I get on average 100ms for the "invocation time". But surprise: when I use a Hashtable(to hold the values of my instance variables in my custom type) instead of my custom type, I get on average 25ms !!!

      Why is this happening ? It can't be because of RMI as the hardcoded custom type in a Vector is returned in about 30ms! (I measured the time just before the "return" in the bean and the first statement in the client after the remote method call.. remember I'm on the same machine with client and server)

      I wonder if this can this be applied to all Java types. However, it doesn't make sense to have custom type induce such performance penalties. Is this a classloader issue ?


      Thanks in advance

      PS: I haven't tested this with jboss3.0.0b, as I can't use it, because (at least the last time I tried it) it is unstable and couldn't get clustering to work on it. However, I'll give it a try and post results in this thread.