Sorry - re-posting with code tags..
PROBLEM
We are trying to use session replication with ASS 4.0.5 but running into significant
performance problems.
Specifically, under load We are seeing a 3-4x cpu increase in cpu on the app servers as a
result of them
trying to do session replication.
Unfortunately the application is pretty old and somewhat badly written. As a result there
are some pretty large oject graphs in the user's session. We are trying to remove
those in order to be
as session replication friendly as possible. In addition the app repeatedly stores the
same
attribute value back into the session rather than checking if the value already exists
there (and avoiding
an unnecessaryt session.set). We could possibly refactor this but its going to be a lot of
work..
There is a possibility of upgrading to a later version of the AS, but not in the short
term and so we would really
like to get this working with our current verson - AS 4.0.5.
BASIC SESSION REPLICATION UNDERSTANDING
Can I get some info on the basic operation of the session cache replication?
(Please note we are using AS 4.0.5 so the info I require must be specific to that version,
since I imagine many improvements have been done since that version)
For example, (for the moment without a UseReplQueue queue setup) does replication occur
every time the app sets a session attribute? And when it replicates does it then replicate
just the value of the attribute that was just set
or does it replicate the entire user's session at that point.
OPTIMAL CONFIGURATION
here is the best guess settings we have for the session replication cache
(org.jboss.cache.aop.TreeCacheAop)
We use buddy replication with 1 backup node for each node.Here is our settings-
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
| can we use 'NONE'. Will this help performance? What are the semantics of NONE
for a session repl cache?
|
| <attribute name="CacheMode">REPL_ASYNC</attribute>
| This should be the best choice - right?
|
| <attribute name="UseRegionBasedMarshalling">false</attribute>
| This should be the best choice - right?
|
| Things we might try ..
| <attribute name="UseReplQueue">true</attribute>
| <attribute name="ReplQueueInterval ">10000</attribute>
| <attribute name="ReplQueueMaxElements">2000</attribute>
| We are considering to ty this since our app updates the same value into the session
repeatedly and often.
| Short of refactoring the app I am hoping maybe the queue mechanism may help?
|
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
| Will this help our cpu load?
|
|
OTHER SUGGESTIONS
Are there any other suggestions that might help us reduce this very significant overheard
of using session replication
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148189#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...