tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 54783] New: Tomcat 6 DeltaManager poses significant performance overhead for Application
Date Tue, 02 Apr 2013 11:32:47 GMT

            Bug ID: 54783
           Summary: Tomcat 6 DeltaManager poses significant performance
                    overhead for Application
           Product: Tomcat 6
           Version: 6.0.20
          Hardware: PC
            Status: NEW
          Severity: major
          Priority: P2
         Component: Cluster
    Classification: Unclassified

We see significant performance degradation for our Web Application when using
TCP In-Memory replication with DeltaManager.

On looking at Tomcat 6 source, here are possible causes we identified and our

#1 Need early evaluation of Filters:

In method invoke, the Filtering of URI's is done after
having done some computation.

This should be done at the earliest immediately after the following call.
   getNext().invoke(request, response);

This will avoid unnecessary checks / computations for URI's that are filtered
out based on the Filter expression defined for the ReplicationVavve.

#2 Minimize Session locking in DeltaManager requestCompleted method

In the DeltaManager method
  public ClusterMessage requestCompleted(String sessionId)
the DeltaSession is locked at start of the method and the lock is released
towards end of the method.

Minimize the DeltaSession locking in this method so that parallelism of
Requests fired by Browser for the same User is not impaired.

Could a copy / clone of DeltaSession be done so that the interval for which
DeltaSession is locked can be minimized?

Going further, after a copy / clone of DeltaSession is done, could the Response
be sent back to the Browser and the DeltaSession processing for replication
done asynchronously in a seperate Thread / by using a seperate Thread Pool?

The DeltaSessionManager does extra computation for Session replication using
the same Thread that processes the User's request. It also holds up sending
back the Response till the extra computation is done. The result is Response
times for a Web Application regress with Session Replication enabled compared
to a baseline when no Session Replication is used.

Both the points noted above and the suggestions on these points can help
mitigate the Performance impact on the Application.

While the issue is being reported on Tomcat 6.0.20, I think it applies to
Tomcat 6 latest version and Tomcat 7 latest version as well.

Fixes for the issues mentioned will go a long way in addressing Performance
concerns with In Memory Session Replication.

--- Abhijit Rajwade

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message