The framework imposes unnecessary overhead on JCS. Every put and get retrieves the region for JCS but not OSCache. You wouldn't uses log4j like this. You wouldn't get a logger everytime you wanted to log. You would setup the logger as a static variable by getting it from the factory and then use it. JCS should be used in the same way.
Since OSCache doesn't have regions, your framework biases the results against JCS.
JCS is region based, like log4j logger. Each region can be configured to use different plugins, like a log4j appender.
As far as I can tell OSCache does not provide you the ability to manage data by region. They provide groups, but this is not the same.
With JCS you can configure the size, element behavior, and plugins (or auxiliaries) for each region. Some can use disk caches, some can be configured to distribute, some can use LRU, some can use Berkeley DB, some can use the adaptive replacement cache, some can use javagroups, some can use lateral tcp distribution, some can have 0 memory size, etc. . . . This flexibility is one of the best features of JCS. It provides fine grained control and a completely pluggable architecture. . . .
The way you are using JCS makes it appear slower than it is.
More realistic data on JCS looks like this:
Disk cache reads should be under 1/10 of a millisecond on anormal desktop harddrive.
Putting 20,000 items in the LRU memory cache should take about 100 millis on a decent desktop.
Getting 20,000 items from the LRU memory cache should take about 50 milliseconds.
(Running the jcs command line tester will demonstrate how much faster it is without the overhead of your framework.
The tester is in the /src/scripts directory
The tester.bat wants you to have the dependencies in /jars/
)
Cheers,
Aaron Smuts
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
