Faster file cache store (no extra dependencies!) in 6.0.0.Alpha1

As announced yesterday by Adrian, the brand new Infinispan 6.0.0.Alpha1 release contains a new file-based cache store which needs no extra dependencies. This is essentially a replacement of the existing FileCacheStore which didn't perform as expected, and caused major issues due to the number of files it created.

The new cache store, contributed by a Karsten Blees (who also contributed an improved asynchronous cache store), is called SingleFileCacheStore and it keeps all data in a single file. The way it looks up data is by keeping an in-memory index of keys and the positions of their values in this file. This design outperforms the existing FileCacheStore and even LevelDB based JNI cache store.

The classic case for a file based cache store is when you want to have a cache with a cache store available locally which stores data that has overflowed from memory, having exceeded size and/or time restrictions. We ran some performance tests to verify how fast different cache store implementations could deal with reading and writing overflowed data, and these are the results we got (in Ks):

• FileCacheStore: 0.75k reads/s, 0.285k writes/s
• LevelDB-JNI impl: 46k reads/s, 15.2k writes/s
• SingleFileCacheStore: 458k reads/s, 137k writes/s

The difference is quite astonishing but as already hinted, this performance increase comes at a cost. Having to maintain an index of keys and positions in the file in memory has a cost in terms of extra memory required, and potential impact on GC. That's why the SingleFileCacheStore is not recommended for use cases where the keys are too big.

In order to help tame this memory consumption issues, the size of the cache store can be optionally limited, providing a maximum number of entries to store in it. However, setting this parameter will only work in use cases where Infinispan is used as a cache. When used as a cache, data not present in Infinispan can be recomputed or re-retrieved from the authoritative data store and stored in Infinispan cache. The reason for this limitation is because once the maximum number of entries is reached, older data in the cache store is removed, so if Infinispan was used as an authoritative data store, it would lead to data loss which is not good.

Existing FileCacheStore users might wonder: what is it gonna happen to the existing FileCacheStore? We're not 100% sure yet what we're going to do with it, but we're looking into some ways to migrate data from the FileCacheStore to the SingleFileCacheStore. Some interesting ideas have already been submitted which we'll investigate in next Infinispan 6.0 pre-releases.

So, if you're a FileCacheStore user, give the new SingleFileCacheStore a go and let us know how it goes! Switching from one to the other is easy :)

Cheers,

Galder

Infinispan 6.0.0.Alpha1 is out!

Dear Infinispan community,

We're proud to announce the first Alpha release of Infinispan 6.0.0. Starting with this release, Infinispan license is moving to the terms of the Apache Software Licence version 2.0.

Besides increased stability (about 30 bug fixes) this release also brings several new features:

• A more efficient FileCacheStore implementation (courtesy Karsten Blees)
  
• A new set of usage and performance statistics developed within the scope of the CloudTM project
• A new (experimental) marshaller for Hot Rod based on protobuf, which will be primarily used by the upcoming remote querying feature. Since this has reuse potential in other projects it was promoted to an independent project named protostream under the Infinispan umbrella
  

For a complete list of features and fixes included in this release please refer to the release notes.

Visit our downloads section to find the latest release and if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Thanks to everyone for their involvement and contribution!

Cheers,

Adrian

Store data by reference or by value?

Traditionally, Infinispan has always stored data by-reference. Once clients store some data, clients can still modify entries via original object references. This means that since client references are valid, clients can make changes to entries in the cache using those references, but these modifications are only local and you still need to call one of the cache's put/replace... methods in order for changes to replicate.

Obviously, allowing clients to modify cache contents directly, without any cache invocation, has some risks and that's why starting with Infinispan 5.3.0.Final, it offers the possibility to store data by-value instead. The way store-by-value is enabled is by enabling Infinispan to store data in binary format and forcing it to do these binary transformations eagerly.

We've also added an FAQ entry that clarifies this topic.

Cheers,
Galder

Lower memory overhead in Infinispan 5.3.0.Final

Infinispan users worried about memory consumption should upgrade to Infinispan 5.3.0.Final as soon as possible, because as part of the work we've done to support storing byte arrays without wrappers, and the development of the interoperability mode, we've been working to reduce Infinispan's memory overhead.

To measure overhead, we've used Martin Gencur's excellent memory consumption tests. The results for entries with 512 bytes are:

Infinispan memory overhead, used in library mode:
Infinispan 5.2.0.Final: ~151 bytes
Infinispan 5.3.0.Final: ~135 bytes
Memory consumption reduction: ~12%

Infinispan memory overhead, for the Hot Rod server:
Infinispan 5.2.0.Final: ~174 bytes
Infinispan 5.3.0.Final: ~151 bytes
Memory consumption reduction: ~15%

Infinispan memory overhead, for the REST server:
Infinispan 5.2.0.Final: ~208 bytes
Infinispan 5.3.0.Final: ~172 bytes
Memory consumption reduction: ~21%

Infinispan memory overhead, for the Memcached server:

Infinispan 5.2.0.Final: ~184 bytes

Infinispan 5.3.0.Final: ~180 bytes
Memory consumption reduction: ~2%

This is great news for the Infinispan community but our effort doesn't end here. We'll be working on further improvements in next releases to bring down cost even further.

Cheers,

Galder