The database can become a bottleneck when too many requests
SPOB
SPOF
Goals
High availability
High performances
Linear scalability
A possible solution : data grids
It is a cluster of machines that handles in memory a large quantity of shared data
Terracotta (Server)
Clustering at the JVM level
1 active TC server
Server TC :
Shared data
Clients list
Spread the updates
Manage locks
Garbage Collector
Terracotta (Client)
From the code
No specific storage structure, only use Java classes
Recommanded to use "synchronized" keyword
Configuration file (XML)
To configure the objects to share (roots)
To configure locks
To configure distributed methods
...
Useful for
Relieving Database Overload
Distributed Caching
Hibernate second level cache
HTTP Session
Simplifying Application Architecture and avoid clustering by hand
Virtual Heap for Large Datasets
Clustering OSS Frameworks
Master / Worker
POJO Clustering
Linear Scalability by connected JVMs
HTTP Sessions
Demo Sample Terracotta application
Clustering a Wicket Application
Wicket stores objects into the session
Page, PageMap...
These objects would need to be declared in the Terracotta configuration
Already done in a wicket-module for Terracotta
<clients> <modules> <module name= "clustered-wicket-1.3" version= "2.6.2" /> </modules> </clients> <instrumented-classes> <!--Include all classes for DSO instrumentation--> <include> <class-expression> *..* </class-expression> </include> </instrumented-classes> <!--Tell DSO which applications in your web container is using DSO--> <web-applications> <web-application> Gallery </web-application> </web-applications>
Sharing Data
Wicket, as a Java application, will use objects for the business layer
Instead of coming from the database, those objects can be in memory
Should be declared in the tc-config file
Classes using it (Pages), should declare it in the tc-config file
Non Uniform Distribution top 4 pages account for >50% of total hits top 17 pages account for >80% of total hits (14% of total pages) spend small amount of memory to cache top 14% of pages -> remove 80% of load
Cache limitations
Amdahl' Law
If the thing you’re caching is not your bottleneck, it won’t matter
Memory
cache uses memory which your app might need
Concurrency
access to cache can be a bottleneck
Reduce LAtency
EhCache
First created in 2003 by Greg Luck
Most widely used Java cache
Apache 2.0 licence
JSR 107 Java cach implementation
EhCache Architecture
Hibernate 2 nd Level Cache
Using Terracotta
EhCache 1.7.0 can be as drop in replacement
Side effect on a single node, keeping state
Monitoring and profiling capabilities
Distributed transparently
Using Terracotta
Enhancement to Hibernate
More efficient in-memory and total count eviction (3.1.1)
Better visibility of memory conditions
Improved Query Caching
Improved performance of core Terracotta (lock manager and memory manager)
0 comments
Post a comment