Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
Undefined future, 1.1 [LEGACY], 1.2 branch
-
None
Description
Been profiling Cayenne in the last few days, and stumbled upon a possible performance bottleneck that dates back to 1.1. Processing of change notification event is expensive; moreover it has O(N) performance (where N is a number of peer DataContexts), meaning it mostly affects high traffic web applications that lots of parallel sessions.
Note that the client that initiated the commit will not see a performance hit, as event processing is done in a separate thread, but the overall throughput is affected significantly.
1. A simple interim fix:
If you have DataContexts that do not care about up to the minute fresh data (or you are using refreshing queries to get all your objects anyways), you can do this right after DataContext creation:
context.getEventManager().removeListener(context.getObjectStore());
Note that this can be done per context.
2. Possible generic fix in 1.2
I am thinking we should use some sort of deferred event mechanism in Web applications (other applications that require an immediate refresh are fine the way they are), where events are not immediately dispatched to all peer DC's, but are queued instead in a shared queue. On certain events (such as request start), a DataContext would pull events that are newer than the last pull, and synchronize its cache. I.e. change event processing from "push" to "pull".
Note that this potentially solves two problems:
- improves performance, as the sessions that are idle and eventually timeout without a single user access will not be synchronized (this can easily be 50% of sessions)
- Makes possible to synchronize deserialized sessions (think clustering)