iBATISには、キャッシュ機能があるが、メモリキャッシュはiBATISのを使うとして、ディスクキャッシュならどれがよいか比較しました。
まず、 Hibernateを参考に、同フレームワークがサポートしているキャッシングフレームワークにどんなのがあるかというとEHCache 、 OSCache 、SwarmCache 、JbossTreeCache。デフォルトは、EHCache。
その他にJCSもあります。 JCS vs EHCacheのページによるとJCSのほうが速いとかいてあります。
しかしながら、iBATISでディスクキャッシュをやるなら、OSCacheしかありません。というかOSCacheしかサポートされていません。
しかし、いろいろ調べてみると、「EHCache for iBatis」なるものがありました。これは、このフォーラムにいる人が作ったようです。とりあえず、正式にサポートしているわけではありませんが、CentOS5.0上で両者の比較をしてみました。
比較の内容は、あるテーブルに、異なる１０００件の主キーで検索します。これを２回ずつ繰り返します。（１０００×２の検索をします。）１回目は、DBより、２回目は、キャッシュより取得される事になります。
まず始めに、タイトルとはずれますが、メモリキャッシュ（LRUアルゴリズム）の比較です。
■iBATISでメモリキャッシュ
１回目：1000件 26秒
2回目：1000件 4秒
■OSCacheをつかってメモリキャッシュ
1回目：1000件 17秒
2回目：1000件 2秒
LinkedHashSet
■ehcacheをつかってメモリキャッシュ
1回目：1000件 24秒
2回目：1000件 12秒
内部的に使用しているクラスは、iBATISは、Collections.synchronizedMap(new HashMap())、OSCache、ehcahceは、LinkedHashMap。OSCache、ehcacheは内部的なロジックの違いで差が出ているようです。
OSCacheが一番速いです。
ちなみにiBATISのメモリキャッシュは、キャッシュのタイプ＝「MEMORY」だと、「reference-type」とか選ぶことができます。
これがあるのですてがたい（？）。
次は本題のディスクです。
■OSCacheをつかってディスクキャッシュ
1回目：1000件 28秒
2回目：1000件 7秒
■ehcacheをつかってディスクキャッシュ
1回目：1000件 25秒
2回目：1000件 20秒
なんか、ehcache遅いですね。最適化されてないのでしょうか？
最後におまけの比較です。
OSCacheのディスクストアのタイプに、DiskPersistence、HashDiskPersistenceがあります。
DiskPersistenceは、１ディレクトリにオブジェクトを作っていきます。
HashDiskPersistenceは、複数のディレクトリを作り１ディレクトリ１オブジェクトです。
※先ほどは、DiskPersistenceで行いました。
この両者の比較です。
■DiskPersistence（※先ほどの結果です。）
1回目：1000件 28秒
2回目：1000件 7秒
■HashDiskPersistence
1回目：1000件 27秒
2回目：1000件 7秒
あまり変わらないので、2999件にしてみます。（３０００件のデータがありませんでした）
■DiskPersistence
1回目：2999件 146秒
2回目：2999件 17秒
■HashDiskPersistence
1回目：2999件 182秒
2回目：2999件 17秒
データの出力に差が出ました。
http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.4/filesystems/ext2.txt.html
に、 「一つのディレクトリ内のファイル数は、実運用上約 10-15k 個が上限になります。」とあります。
どれくらいの数のオブジェクトをキャッシュするかによって使い分ける事が必要です。
ちなみに、http://daubau.net/post/memosにOSCache × memcachedのプラグインがありました。
この報告は次回にします。
