Multi-threading leads to 700% increase in response times on WLS6


EJB programming & troubleshooting: Multi-threading leads to 700% increase in response times on WLS6

  1. Hi,

    I have found that when I send concurrent requests to my EJB hosted on WLS6.1 the response time goes up by 700%
    i.e. average response for my single threaded client is 10ms, average response for my multi-threaded client is 70ms.
    It is not all bad news, because the throughput is actually 300% better i.e. the time it takes to actually process the same number of requests is a third of the single threaded test (due to the concurrency).

    Has anyone else had similar experiences with response times going up drastically? If yes or no, were you using WLS6.1 or a different app server.

    Test details:

    My tests where on a single Sun E450 with 4CPUs (400MHz).
    Both client and server were on this machine.
    Multithreaded client used 20 threads to send concurrent requests.
    Weblogic server had 15 threads.
    I was using native threads in both client and server JVMs

    I know that you are all going to come up with theories of why this is e.g.
    - client has thread blocking issues
    - overhead of initialising threads
    However, I think my client code is rock solid in these areas and I am really after empirical evidence not theories right now. It would really help me if someone had done some testing like this and has some figures they can share.

    Bea tell me this is due to thread context switching but I would like to hear from you all...

    Simon Reavely
  2. It is hard to know if the increased time is due to WebLogic or not, since you had 20 other threads running outside WebLogic on the same box.

    That will lead to potential process switching by the OS, which is far less likely if the WebLogic server had the box to itself (incidentally, this is why database software tends to like being left to its own devices on the server as well.)

    The other test is to run X virtual machines (each single threaded) against the same server and then run one process with X threads. Theoretically this represents the same number of threads on the server, but the one with multiple VMs ought to put more load on the server as the client VM won't be switching as much.

    It is also worth reducing the number of client threads to LESS than the number of WebLogic threads to see what the effect of hitting the WebLogic limit has on the performance.

    That should all give you a better idea of the performance characteristics.