My experience is this area is that it is all to do with how expensive the Aware IM transactions are. For example, if you have processes that are updating multiple tables at once, or are using regular user too much for context then this can place a massive strain on things.
We have a very big application that is used by many users. Over the course of last year we had lots of performance issues.
There was lots we did, but the headlines are:
start monitoring for any deadlocks in the DB and review which (if any) tables are getting hit the hardest.
check the active processes and see which are not clearing quickly. These will be good candidates for moving to a stored procedure. We have moved a significant amount of Aware IM processes to stored procedures and the performance boost has been profound. For example- having Aware IM calculate ages for 150,000 people might take 4 hours or so. An SP can do this in about 5 seconds.
avoid writing to the regular user as this will likely trigger a bunch of rules. Instead, we write to the ref user with an SP. Reading an object carries no cost.
we have also stripped out as many rules as possible from the major objects in our system and instead these are governed with triggers in the DB.
In summary:
Monitor and resolve deadlocks
Switch processes for stored procedures
Switch rules for triggers
These changes will significantly increase your applications capacity for extra users without the need for a load balancer- however, we have also worked with Vladimir to support storing the session Id for a user in a database rather than in tomcat memory, which is an asset if you go down that route.
Making the changes I am outlining require a different style of thinking as you will need to think much more about version control for your SP's and triggers as they are not wrapped up on the bsv, but from our limited experience the change was more than worth it.
Martyn
