1 / 7

Caching in Sakai

Explore the issues and bugs related to caching in clustered environments with a focus on Sakai, including problems with cache length and multiple request-response cycles. Learn about app-aware caching and the impact of Hibernate and EHCache on performance. Discover possible future directions and recommendations for optimizing caching in Sakai.

sandridge
Download Presentation

Caching in Sakai

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Caching in Sakai Charles Severance Notes - 5/20/2006 csev@umich.edu

  2. Clustered Caching Issues • Problem is that bad caching in clustered environments = bug reports • Length of cache • Within one (exactly one) request-response cycle (0.5 - 2 sec) - Very safe • Across multiple request-response cycles (10 sec - 5 minutes) - Source of “bugs” • This covers the multiple request scenario • App-aware caching / event bus caching • Hibernate / EHCache style

  3. Has Changed Has Changed Sakai App-Aware Cache 1 API API … Cache Cache 2 3 4 Event Bus Some tool modifies an object and saves it via the API The local cache is invalidated An event is generated indicating which object was modified The event is delivered across cluster causing invalidation as necessary Note: TTL is still on the order of 3 minutes to keep caches small and fresh

  4. Hibernate / EHCache 4 1 6 7 … API API EHC EHC 2 3 5 7 6) Until TTL expires, requests come from cache on other nodes and get bad data 7) When TTL expires and a request is made for the object 8) It is properly re-retrieved from disk Object is modified in a node It is invalidated in the local cache It is updated in the DB When a new request happens, It is properly re-retrieved

  5. Possible Future Directions • Improve Event Implementation • Use JGroups instead of Database • Early experiments worked well • Must solve the issues in dynamic cluster configuration • Likely to improve scaling nicely • Have Hibernate use Cluster-aware caching • Will need careful performance analysis - coordination in large clusters could easily overwhelm benefits • oscache, jbosscache, swarmcache (From Josh)

  6. Recommendations • TTL of < 10 seconds in EHCache or any other non-cluster aware cache - Even things that seem “read-mostly” are dangerous to cache - because when these change often they are broad settings like “test start time” that are important to propogate quickly. • A short cache TTL approximates “request scope caching” as well as “app-aware caching” • Developers may want a TTL of zero to insure that they truly are encouraged to look at generated SQL.

  7. Summary • Increasing EHCache TTL as a performance tuning approach is very bad • Developers on single systems will *never* encounter bugs • Synthetic tests in clustered environments may not catch bugs • Users will catch bugs when making changes because of user-support or student request - user behavior causes worst-case need for synchronization • Sakai’s app-aware caching is not *easy* • Requires the use of events • Improve performance of applications which use Hibernate by looking at the data model and SQL and improving it - not just using EHCache

More Related