Blogging Roller: OSCache 2.0 is quite an improvement.

OSCache 2.0 is quite an improvement.

I just tried the new OSCache 2.0-beta2 release and it is quite an improvement over the 1.7.5 release. Wow. Look at these numbers:

Testing Roller 0.9.7.5 with the old OSCache and the new:

Test	Cache-TO	Threads	Loops	Max-Delay	Avg	Med	Dev	T-Put
OSCache175	5/5	20	10	1000ms	4684	1382	8012	138.7/min.
OSCache200	5/5	20	10	1000ms	2237	821	6624	201.4/min.
OSCache175	60/120	20	10	1000ms	2601	1382	3136	186.9/min.
OSCache200	60/120	20	10	1000ms	1680	731	2113	242.9/min.
OSCache200	60/120	20	1000	1000ms	2248	1603	2079	271.5/min.

See Roller0975Throughput for more information on the tests.

Dave Johnson in Java • 🕒 07:26PM Aug 04, 2003

Tags: Java

Comments:

I swear I just left a huge long comment here, but it's not showing up now! Alright, in short I'm not sure how much fiddling with Roller performance will help, because so much is cached (I believe). However, improving the cache would undoubtedly make a significant difference - check out my suggestion to add gzip compression support to OSCache, and my reasoning on how it will increase performance (less actual cpu cycles used) at http://jira.opensymphony.com/secure/ViewIssue.jspa?key=CACHE-49 Please comment/vote on it if you think it's valid! (or comment if you think it's invalid, as the case may be).

Posted by Paul Rivers on August 05, 2003 at 05:50 AM EDT #

We have GZip compession in the main branch now, perhaps I should backport it to 0.9.7 so FreeRoller can use it. I wonder: how many browsers support it?

Posted by Dave Johnson on August 05, 2003 at 11:11 AM EDT #

Glad to see the speedup is so significant. There were some changes made to the LRU caching algorithm that I was fairly sure would speed things along a fair bit but I hadn't got around to benchmarking them yet. I guess now I don't have to ;-) What JRE did you benchmark this on? I ask because the optimizations work best under JRE 1.4.x. Paul's request for gzip support should make it into v2.1 of OSCache. If you decide to add your own gzip support and you're using OSCache's filter, you may run into problems unless your filter compresses every request (ie it must be applied before OSCache's filter in web.xml). Once we've got gzip support integrated into OSCache however we'll be able to safely cache the *compressed* responses which should save some CPU cycles, memory and disk space (in addition to the reduced network traffic gzip compression offers anyway). Kudos to Paul for thinking of this!

Posted by Chris Miller on August 05, 2003 at 02:01 PM EDT #

I'm pleased as punch that Chris also thought my idea was a great idea! :-) It is my understanding the every browser that is Http1.1 compliant is required to support GZip compression. However it would slow things down on the server if the gzip filter wasn't _behind_ the OSCache filter, so that compressed responses are cached, but if you do that then it won't work with http1.0 clients...thus, the best solution is to have it integrated into OSCache. :-)

Posted by Paul Rivers on August 05, 2003 at 05:20 PM EDT #

I benchmarked on Sun JDK 1.4.1 on Redhat 9.

Posted by Dave Johnson on August 05, 2003 at 11:40 PM EDT #