anonymous wrote : If I can't increase the heapsize beyond 1700MB(including permgen), Does that mean 2GB/4GB/8GB RAM will not make much difference? That is correct. As long as you are using a 32-bit JVM you are limited to a 32-bit (4GB) address space for each process. Windows uses 2GB of that space for its data (file handles, thread handles, GUI handles, etc) and leaves the other 2GB for the process' use. Then take away the memory required for the code (exe and dlls), the C/C++ data structures used by the JVM, and the thread stack memory, and you are left with around 1700MB, give or take a few 100 MB depending on the exact version of Windows. You would have to install a 64-bit OS and run with a 64-bit JVM to get a larger address space. anonymous wrote : If garbage collector is not the culprit for the difference in response times at different intervals, I wonder what else could be the reason...? Without profiling your code, it is hard to tell. You need to find out where you code is spending its time. Also, seriously consider my suggestion of running with different numbers of users - with 500 threads all fighting to get time on 4 cores you could just be overloading the system. Reducing the number of threads could very well improve your response times. even if you have requests queued up waiting for their turn. anonymous wrote : Will clustering of JBoss help me in meeting the SLA? Clustering using a software load balancer (Apache mod_jk) will probably work for you. 500 requests per minute (based on SLA of 1 min max response time for 500 users) is very low, usually you need to go to a hardware load balancer if you are handling hundreds (or thousands) of requests per second. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258944#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...