I've been doing some profiling of our remote EJB3 invocations, and I just wanted to post and share what I found out. I was able to achieve an average 50% performance boost for our remote calls by changing 1 line in deploy/ejb3.deployer/META-INF/jboss-service.xml:
Original line:
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873</attribute>New line:
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?serializationtype=jboss&socket.check_connection=false</attribute>JBoss serialization gives a really nice performance boost. However, I did run into a bug in JBoss AOP when I enabled it. I posted a patch for this at
http://jira.jboss.com/jira/browse/JBAOP-347.
The other change that gave an almost equally impressive boost was the check_connection=false bit. The socket transport sends a 1 byte ping to the server and waits for a 1 byte response before handing the socket back to the client from the pool. So because of this, every remote invocation actually involves
2 round trips by default. Adding this parameter to disable this check shaves a few milliseconds off of each remote call, on average.
However, this does seem to cause a problem in that, once the socket connection times out (default configuration value is 1 minute), the subsequent remote call fails on the client side, because it tries to reuse the closed socket connection. The call after this is fine because it gets a fresh connection. So to resolve this, I increased the socket connection timeout to 10 minutes (timeout=600000), and created a custom client-side interceptor that wraps the invocation, checks for an IOException, and retries the call once when it happens.
This seems to be working pretty well, and is significantly faster. If anyone has any suggestions for how to squeeze some more performance out of the transport, or sees anything potentially wrong with what I'm doing, I'd appreciate hearing about it. :)
--Tim
