Pump your Java with Caching

25 08 2008

So you want caching. First thing to see are if your application are applicable for it. There’s the 80/20 rule saying that you need to be maximum 20% writing on what you intend to cache, if you deviate too much from these numbers caching stuff could actually slow you down. I had some fun with this on my own “production” machine an old p3 500mhz (keep that in mind when you see results).

Im gonna write about my current stack which are Apache Http+Apache Tomcat, JPA / Hibernate + spring & Apache Wicket, this does’nt mean that you cant benefit from the ideas though if you arent using these frameworks, which leads me to what I believe are number one rule with caching:

Non intrusion , cache needs to be applied lightly in a non intrusive way

That way you can easily switch it off, switch strategies etc.

So with my stack you can actually introduce caching in each layer if you want to, i’ll start at Hibernate.

Caching with Hibernate

As I used Hibernate and my application seemed a bit heavy on the database I optimized everything, but Hibernate I thought lets start here. So I did, enabling the query cache and 2nd level cache were actually very simple and few lines of code. But this approach were very intrusive as the application needed to know about the caching mechanism, I went ahead any how. I spent 2 days pondering why it did not work, I kept getting cache misses even though I saw that the queries were added to the cache. Hibernate forum werent being responsive so I thought maybe theres another way. Which leads me to next thing.

btw I just bought Java Persitence with Hibernate http://www.manning.com/bauer2/ to help me digg into the cache with Hibernate.

Caching with Spring modules cache

So the spring guys has an non intrusive way of applying caching. It’s really simple :

ApplicationContext.xml add:

<import resource="classpath:cacheContext.xml" />

cacheContext.xml :

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ehcache="http://www.springmodules.org/schema/ehcache"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springmodules.org/schema/ehcache http://www.springmodules.org/schema/cache/springmodules-ehcache.xsd">

  [4]<ehcache:config failQuietly="true"
configLocation="classpath:ehcache.xml"/>

    <bean id="myCacheKeyGenerator" class="zeuzgroup.core.cache.ZeuzCacheKeyGenerator"/>
    <bean id="myCachingListener" class="zeuzgroup.core.cache.ZeuzCachingListener"/>

    <ehcache:methodMapInterceptors
            cachingInterceptorId="cachingInterceptor"
            flushingInterceptorId="flushingInterceptor">

        <ehcache:cacheKeyGenerator refId="myCacheKeyGenerator"/>

        <ehcache:cachingListeners>
            <ehcache:cachingListener refId="myCachingListener"/>
        </ehcache:cachingListeners>

[1]<ehcache:caching cacheName="translationCache"
methodFQN="zeuzgroup.core.localization.ITranslationService.get*"/>

<!--  Flush cache -->
    [2]<ehcache:flushing cacheNames="translationCache" methodFQN="zeuzgroup.core.localization.ITranslationService.put*" when="after"/>
    </ehcache:methodMapInterceptors>

    <bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
        <property name="beanNames">
            <list>
               [3] <idref bean="translations"/>
            </list>
        </property>
        <property name="interceptorNames">
            <list>
                <value>cachingInterceptor</value>
                <value>flushingInterceptor</value>
            </list>
        </property>
    </bean>
</beans>
ehcache.xml
  1. setup target methods to cache
  2. setup which metods that evict cache
  3. point at beans to look in
  4. point at ehcache.xml

As you can notice theres two beans further more defined(myCachinglistener and mycachingkeygenerator), you can just use the default implementation provided. Although you might want to use your own keygenerator if using datetime properties in your objects, if your methods return objects with new stamps your cache will not be hit. In my setup my wicket page went from 12s to display to 4s (having a 2s round trip).

ehcache.xml

<diskStore path="java.io.tmpdir" />
<defaultCache maxElementsInMemory="1000" eternal="false"
 timeToIdleSeconds="0" timeToLiveSeconds="500" overflowToDisk="true"
 diskPersistent="false" diskExpiryThreadIntervalSeconds="500" />
 <cache name="translationCache" maxElementsInMemory="75000"
eternal="true" timeToIdleSeconds="0" timeToLiveSeconds="0" overflowToDisk="false"
diskPersistent="false"
 diskExpiryThreadIntervalSeconds="3600" />

Above are also pretty straight forward.. Now onto the next part.

Caching with Wicket, or preparation for web cache.

Caching statefull pages? Well you can. But remember that if you do when others look at the page you cache they’ll get the same result. Please remember that you cant cache pages with ajax on (AFAIK).

So this means that if you have a “simple” solution where you have users that can be either authorized or not it’s pretty straight forward. I went ahead and chose all the pages where my users arent logged in to be cachable. I decided to go with ehcache’s web cache namely the simplefiltercache. And to make it visible for the cache when a page could be cachable I added a noop parameter to all my pages called cache it has the value true. The simplest way to work with a cache are using urls, you might be able to do something http codes and cache all that does not sets the cache control header. But that’s stretching it to far for me.

Code:

public abstract class MyPage extends WebPage {
public static final String CACHEABLE = "cache";

private PageParameters myPageParameters;
[1]    public Boolean canCache() {

        if (MySession.class.isInstance(this.getSession())) {
            MySession mySession = (MySession) this.getSession();
            return !mySession.isAuthorized();
        }
        return true;
    }
    public MyPage(PageParameters pageParameters) {
[2]	myPageParameters = pageParameters;
[3]        BookmarkablePageLink creditsLink = new BookmarkablePageLink("credits",
                CreditsPage.class, getPageParameters(getSession().getLocale()));
        add(creditsLink);
}
[4]   protected PageParameters getPageParameters(Locale locale) {
        PageParameters pageParameters = new PageParameters();
        if (canCache() && !pageParameters.containsKey(CACHEABLE)) {
            pageParameters.add(CACHEABLE, "true");
        }
        if (!canCache()) {
            pageParameters.remove(CACHEABLE);
        }
        if (zeuzPageParameters != null) {
            pageParameters.putAll(zeuzPageParameters);
            if (pageParameters.containsKey("locale")) {
                pageParameters.remove("locale");
            }
        }

        pageParameters.add("locale", locale.getLanguage());
        return pageParameters;

}
Okay so 4 simple steps are needed to make our wicket pages cachable:

  1. Make a method that can determine if a page are cachable or not
  2. Keep a reference to the page parameters the page were initialized with.
  3. Use bookmarkablePageLink’s so that url’s are stable
  4. This is where the magic are done, add the cachable parameter to appropriate pages, notice that if you have a multilingual application you need that as a parameter otherwise the locale of the pages will be the one that last caused a miss.

Note : I had to set this to get stable parameter positions in urls:

        // Be able to sort page parametes
        UnitTestSettings.setSortUrlParameters(true);

Okay so now our wicket pages can be cached, now we just setup the cache:

add in ehcache.xml

<cache name=”SimplePageCachingFilter” overflowToDisk=”true” maxElementsInMemory=”500″ timeToLiveSeconds=”86400″ timeToIdleSeconds=”43200″/>

if you want define flush methods in cacheContex.xml:

    <ehcache:flushing cacheNames="SimplePageCachingFilter" methodFQN="zeuzgroup.core.provider.IDBDao.persistExercise*" when="after"/>

For me this made the page I talked about earlier go from 4s to 0.2s to display.

Conclusion

So I tried several approaches before comming to the approach showed above (regarding wicket). I tried creating a custom a IRequestEncodingStrategy, did’nt work for me but it’s my fault nothing todo with wicket. Sometimes simple are better I guess. An annoying thing were that apparently that my pages when in danish locale were’nt encoded with html entities (this caused chars like æ ø å to get corrupted), i’ve submitted a patch to wicket to support this http://issues.apache.org/jira/browse/WICKET-1795 , it’s just for component though a general setting would be nice. I think above are pretty straight forward, but of course it would be nice if wicket support something like it out of the box, but then again it requires many thing that only you as the developer can decide. Using above approach you’re free to chose ehwebcachefilter like i did or something else like Apache http, if you dont select ehcache, you’ll loose the evict option. But there might be other options. The above approach should be usable with other web frameworks aswell.





Ubuntu Benchmarking

13 08 2008

So you want to benchmark your ubuntu box?

Test your harddrives:

hdparm -tT /dev/sda

results
/dev/sda:
Timing cached reads: 276 MB in 2.00 seconds = 137.91 MB/sec
Timing buffered disk reads: 58 MB in 3.05 seconds = 19.05 MB/sec

For cpu & network you can run

Super pi:

Command line(installation):

ftp

open pi.super-computing.org

cd Linux

get super_pi.tar.gz

tar -zxvf super_pi.tar.gz

to run:

./super_pi 2

results:

End of main loop
End of calculation. Time= 194.060 Sec.
End of data output. Time= 0.870 Sec.
Total calculation(I/O) time= 194.930( 6.760) Sec.

Hardinfo runs with an gui or in your command prompt:)

Do this from command line:

sudo apt-get install hardinfo

Then

hardinfo

Lay back and watch benchmark commence, heres my results for my really low end p3 500 mhz 512 mb box:

CPU ZLib
——–

-CPU ZLib-
<i>This Machine</i> : 4274,070
PowerPC 740/750 (280.00MHz) : 2150.597408
Intel(R) Celeron(R) M processor 1.50GHz : 8761.604561

CPU Fibonacci
————-

-CPU Fibonacci-
<i>This Machine</i> : 20,012
Intel(R) Celeron(R) M processor 1.50GHz : 8.1375674
PowerPC 740/750 (280.00MHz) : 58.07682

CPU MD5
——-

-CPU MD5-
<i>This Machine</i> : 14,664
PowerPC 740/750 (280.00MHz) : 7.115258
Intel(R) Celeron(R) M processor 1.50GHz : 38.6607998

CPU SHA1
——–

-CPU SHA1-
<i>This Machine</i> : 16,703
PowerPC 740/750 (280.00MHz) : 6.761451
Intel(R) Celeron(R) M processor 1.50GHz : 49.6752776

CPU Blowfish
————

-CPU Blowfish-
<i>This Machine</i> : 69,238
Intel(R) Celeron(R) M processor 1.50GHz : 26.1876862
PowerPC 740/750 (280.00MHz) : 172.816713

FPU Raytracing
————–

-FPU Raytracing-
<i>This Machine</i> : 94,175
Intel(R) Celeron(R) M processor 1.50GHz : 40.8816714
PowerPC 740/750 (280.00MHz) : 161.312647