Asynchronous Messages (using JMS) improves performance even when the desire

Question

I am being told that even when point A to point B communication,
originating at point A, is synchronous, send a message to B wait for B
to finish processing and send a tagged(to corelate the response to the
request) message back asynchronously via another Q will improve the
response time and scalability during peak volume vis-a-vis a
synchronous API call between A and B. A being a servlet B being an
application server hosted on a container. Keep in mind that this
application cannot live with the fact that there is a possibility that
the response may never come back (timeout). The expected response time
during average load is <2sec. Peak load 110 transactions per second.
Response time of 5 secs during peak load is unacceptable. Clustering is
certainly a consideration. Any opinion, pointers, etc. is welcome.
Have a wonderful weekend!!

Answer 1

Hi,
I personally think that you should go for an asynchronous solution as that�s what JMS is all about. You can obviously use a Requestor and go for a RPC style solution but there are overheads:
1) Your messages cannot be concurrently processed
2) A temporary destination (to collect the response) is created per request
3) There is a delay between each message processing event
The number of app server instances that you would need is really application dependant and app server as well. But according to my experience, and assuming that your message process is simple, I would say that less than 2s delay is easily achievable.
By the way, have you considered using a light weight app server like an MDS container? For more info you can have a look at: http://www.arjuna.com/products/arjunams/tutorials/mds/index.html
Hope this helps
Arnaud
www.arjuna.com