Here are few findings: anonymous wrote : | I did see few threads waiting on DB connection which Brian also pointed out. This was intentionally left out because caching whatever data that threads are trying to get would result into a huge memory footprint in some use cases. But what I am going to do is turn on caching for those data and see what that results into. Changing the cache configuration for above results into good scalability. Earlier hibernate config was set to use lazy="extra" and apparently hibernate bypasses second level cache for this lazy loading configuration. This setting is recommended for large collection and hence was made default in portal. Changing it to lazy="true" forces hibernate to use second level cache which helps in scalability. | #Node #Users | 1 1400 | 2 2200 | 3 3300 | 4 4100 | 5 5500 | So although ability to handle more load decreases for (2,3} node cluster, it helps with 4 and 5 nodes. I think this suggests that increasing heap size for each node would result into each node handling more load while keeping the scalability. I have posted in Hibernate ML asking if there is a way to use cache with lazy="extra" because I think that will be optimal in this use case. Of course I wont know until I run tests. Since this new jar fixes problem with OL and REPL_SYNC combination, I am going to run tests with this configuration as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170656#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...