2 Replies Latest reply on Sep 24, 2005 2:04 AM by Tom Robins

    Network performance question

    Tom Robins Newbie

      What sort of round trip times should I expect from a simple call to a stateless echo style bean?

      Server

      @Stateless
      @Remote({Echo.class})
      public class EchoBean implements Echo, Serializable {
       public String echo(String value) {
       return value;
       }
      }
      
      


      Client

      jndi.properties

      java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
      java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
      java.naming.provider.url=localhost:1099
      


      client code (in another JVM)

      InitialContext ctx = new InitialContext();
      Echo e = (Echo)ctx.lookup(Echo.class.getName());
      long tx = System.currentTimeMillis();
      e.echo("hello");
      System.out.println((System.currentTimeMillis() - tx) + " ms");
      


      This call yields a miniumum round trip time of 125 ms!! on a local interface, mind you. I'm coming from a world of ONC-RPC, where this sort of call would take a few milliseconds, so maybe my performance expectations are a bit unrealistic. Nevetherless, 120ms+ call time to an idle server running on the same network interface, IMHO, is really, really SLOW. Are these the numbers I should be expecting, or am I doing something wrong?

        • 1. Re: Network performance question
          Raja Master

          Even though its the same Network Interface, you are making a call between two VMs. Running it in the same VM(like a servlet calling the EJB) maybe faster but I think the numbers might just be what you might get. For all this, JBoss uses Dynamic Proxies, instead of Stubs and Skeletons, so your invocation stack is one level of method calls less than what you have with a stub and skeleton.

          • 2. Re: Network performance question
            Tom Robins Newbie

            Actually, it's not as bad as I'd presented in my prior post. Only the first call (which I'm assuming triggers the bean construction step) takes unusually long to complete. Once the stub has been acquired and at least one call made, it's actually very fast. Obviosuly, that warrants some design changes, such as: using statful beans or maybe even caching the stubs of the stateless onces on the client side for the duration ofa session.