Greg Luck's Blog

I thought I would share a few of the topics I am reading:

The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines Luiz André Barroso and Urs Hölzle 2009- s00193ed1v01y200905cac006.pdf
Lessons from Giant-Scale Services, Eric Brewer 2001

(The files are up on Dropbox but I discovered you cannot create a public link to a shared folder to everyone. You need to email to share. And there was no blindingly obvious way to share a link to my public folder, which kinds of seems amazing)

For those of you looking for the older Hibernate Subversion repository it is here: http://anonsvn.jboss.org/repos/hibernate/core/trunk/

It is now on GitHub, but the older SVN is still useful for legacy.

Is it that time of year again. A time for reflection and of New Year’s resolutions. I therefore thought this was good time to reflect on what has been happening with Ehcache.

Ehcache and Terracotta got together in August 2009. We got our first combined release done with Ehcache backed by Terracotta three months later. That was really only the beginning. We have done 5 major releases to date with of course another one in the cooker right now.

The big news is that Ehcache and Terracotta together have been a great success. Most Terracotta users now use it as a distributed backing store for Ehcache. Most of Terracotta’s revenue comes from that use case. This means that Ehcache’s needs are driving the evolution of Terracotta.

At the same time, Ehcache as an open source project has seen a huge investment. Most of the features added are designed to work in Ehcache open source as well as with Terracotta as the backing distributed store.

So let’s look at what we added in 2010 and what is in the cooker so far for 2011.

What we did in 2010

New Hibernate Provider

When we merged Terracotta had just done a Hibernate provider and Ehcache had one too. Neither supported the new Hibernate 3.4 SPI which uses CacheRegionFactories instead of CachingProviders. So we combined the two into a new implementation and added support for the new SPI at the same time. This meant that for the first time Ehcache supported all of the cache strategies, including transactional, in Hibernate and importantly supported them across a caching cluster.  (http://ehcache.org/documentation/hibernate.html)

XA Transactions

Right now XA transactions have fallen from favour partly because of flaky support for them in XAResource implementations out there. But what if you could create a canonically correct implementation that could be absolutely relied on in the world’s most demanding transactional applications? We hired one of the Java world’s foremost experts in transactions (Ludovic Orban, the author of the Bitronix transaction manager) and came out with just that. We challenge anyone to prove that our implementation is not correct and does not fully deal with all failure scenarios. If you need to be absolutely sure that the cache is in sync with your other XAResources with a READ_COMMITTED isolation level you have come to the right place. (http://ehcache.org/documentation/jta.html)

Terabyte Scale Out

Ehcache backed by Terracotta initially held keys in memory in each application that had Ehcache in it. This effectively limited the size of the caching clusters that could be created. With a new storage strategy, we blew the lid of that and stopped storing the keys in memory. The result – horizontal scaling to the terabyte level.

Write-through, behind and every which way

What happens when you have off-loaded reads from your database but now your writes are killing you? The answer is write-behind. You write to the cache. It calls a CacheWriter which you implement and connect to the cache which is called periodically with batches of transactions. In your CacheWriter you open a transaction write the batch and then close the transaction. Much easier for the database. And all done in HA with the write-behind queue is safe because it is stored on the Terracotta cluster.

More caching in more places

We were really happy to extend our support for popular frameworks. During the year:

• Ehcache became the default caching provider for Grails
• We created an OpenJPA provider
• We created Ruby Gems for JRuby and Rails 2 and 3 caching providers
• We created a Google App Engine module

Acknowledgement of the CAP Theorem

Originally Ehcache with Terracotta was consistent above all else. During the year we flexed both ways to allow CAP tradeoffs to be made by our users. We added XA and manual locking modes on the even stricter side and we added an unlocked reads view of a cache and even coherent=false for scale out without coherence on the looser side. And you can choose this cache by cache. There is a tradeoff between latency and consistency, so you choose the highest speed you can afford for a particular cache.

And rather than just blocking on a network partition, we added NonStopCache, a cache decorator which allows you to choose whether to favour availability or consistency.

BigMemory

BigMemory was a big hit. It surprised a lot of people and frankly it surprised us. We were looking to solve our own GC issues in the Terracotta server and found something that was more generally useful than that one use case. So we added BigMemory to Ehcache standalone as well as the server. In the server we have lifted our field engineering recommendation from 20GB of storage per server partition to 100Gb. And we have tested BigMemory itself out to 350GB and it works great!

A new Disk Store

Let’s say you are using a 100GB in Ehcache standalone. When you restart your JVM you want the cache to be there otherwise it might take hours or days to repopulate such a large cache. So we created a new DiskStore that keeps up with BigMemory. It writes at the rate of 10MB/s. So when it is time to shutdown your JVM it just needs to do a final sync and then your are done. And it starts up straight away and gradually loads data into memory. A nice complement to BigMemory and very important.

Ehcache Monitor/Terracotta Dev Console Improvements

For those using Ehcache standalone we have only ever had a JMX API. That is fine but we found many people built their own web app to gather stats. So we did the same and the result was Ehcache Monitor. One of the highlights is the charts including a chart of estimated memory use per cache.

The Terracotta Developer Console got an Ehcache panel, and as we added features to Ehcache we added more to the panel. If you are using Ehcache with a backing Terracotta store then it is a full featured tool which gives you deep introspection.

What is Coming in 2011

Speed, speed and more speed

What does everybody want? More speed. We are splitting hairs in our concurrency model to enable as much speed as possible for each use case. We now have two and will be adding more modes to allow the best tuning for each use case.

Search

Ehcache is based on a Map API. Maps have keys and values. They have a peculiar property – you need to know the key to access the value. What if you want to search for a key, or you want to index values in numerous ways and search those. All of this is coming to Ehcache in February 2011 and is available right now in beta. Oh and one cool thing: search performance is O(log n/partitions). So as your data grows and spreads out onto more Terracotta server partitions, your search performance stays constant! (http://ehcache.org/documentation/search.html)

New Transaction Modes

We already did the hard one: XA. Now we are adding Local Transactions. If you just want transactionality within the caches in your CacheManager and there are no other XAResources, you can use a Local Transaction. It will be three times faster than an XA cache. (http://ehcache.org/documentation/jta.html)

.NET Client

Quite a few customers use Java but also some .NET. And they want to be able to share caches. We have lots of users happily using ehcache for cross-platform use cases, but are planning on extending our cross-platform support still further – for example with a native .NET client

Bigger BigMemory

We are looking at ongoing speedups and testing against larger and larger memory sizes for BigMemory. We are also looking to provide further speed in BigMemory by allowing pluggable Serialization strategies. This will allow our users to use their Serialization framework of choice – and there are now quite a few.

After many requests we have extracted our talks out of the mess that is Webex and have started posting them to ScreenCast. From there you can easily watch them without any sign in rubbish or embed them. See http://www.screencast.com/users/Terracotta

While having a few drinks with some French-speaking colleagues at  Le Meridien hotel in San Francisco during JavaOne 2010 I realised that French speakers have a cool name for a load phenomenon of online systems

It is difficult to tune an online system for the average daily traffic volume because it varies a lot during the day. Specifically in my experience it is common to see demand rise in the morning to a midday peak then lull somewhat in the afternoon to be followed by a lower mid-evening peak. Things then quiten down. Now my experience is in travel systems. The explanation we had was that though some of the usage was business related, a lot was leisure. And users would tend to search and book travel at lunchtime and then after dinner.

It turns out that French speaking people have come across the same phenomenon but were clever enough to give it a name: The Elephant Curve. The reference is to Le Petit Prince, a best-selling children’s story from  1943 which has been published in 190 languages. In the book a boa constrictor swallows an elephant. The silhouette of the boa then becomes an elephant curve. Though I did not read the book at school it seems that many people have.

Here is the elephant curve illustration from the book

So I plan on calling the E-commerce daily double spike the elephant curve from now on like the Francophones do. I am going to add this as a slide in my talks and to my Caching Theory chapter on ehcache.org.

Thanks to Ludovic Orban (Belgian) and Alex Snaps (German/Belgian) for appraising me of this.

Online Petition

Last month we made a big splash with our news of BigMemory, our add-on to Ehcache which creates very large caches in the Java process ((VLIPCCs) while still avoiding the achilles heel (hell) of GC pauses. We released charts on ehcache.org showing our performance up to 40GB of cache.

Optimising for Byte Arrays. Why?

We will be GAing later this month and have been doing lots of optimisation work. One case we have optimised for is storage inthe cache of byte arrays. Why? Because we use also use BigMemory in the Terracotta Server Array (TSA) as well. And data in the TSA is stored in byte arrays. We get to escape GC pauses in the TSA, which is generally a very good idea for a high performance server. A field recommendation to escape GC has been to use no more than 4GB of cache in the TSA in-memory with the balance on disk. With BigMemory for users who do not want disk persistence with TSA, we can run the whole lot in memory.

Some new Charts

Himadri Singh, a performance engineer at Terracotta has done some new performance runs, to try out our byte array optimisation, with our published perf tester  (See  https://svn.terracotta.org/repo/forge/offHeap-test/ ).

These were done on a new machine with 8 cores and 350GB of RAM of which we used up to 100GB for these tests.

This first chart below shows the mean latency for byte arrays. It is almost 4 times faster than our beta release a month ago! Now we get 110 usec flat response time right out to 100Gb and then we had 450 usec out to 40GB.

This next chart is the old test from the documentation page on ehcache.org and is still representative of the present performance for non byte array data types.

This next chart is throughput. We also get a four fold increase in throughput compared to the beta.

What’s Next

The speedup for byte arrays was done by optimising serialization for this one case. We know that serialization for puts and dererialization for gets is by far the biggest cost. So applying Amdahl’s law, it makes sense for us to concentrate our further optimisations there.

The following chart is from the Java Serialization Benchmark, and shows the performance of alternative Java Serialization frameworks.

Some key observations:

1. Java’s built in one is pretty slow
2. There are lots of choices now
3. We can get around a 50 times speedup with the faster libraries!
4. Handwritten is the fastest

So what’s next? We don’t want to hold up ehcache-enterprise 2.3, but we are planning a follow-up release to exploit this. We are thinking about these changes:

1. Make Ehcache’s Element Externalizable with a pluggable strategy for readExternal and writeExternal
2. Expose the pluggable serialization strategy via config on a per cache basis or across an entire CacheManager
3. Probably bundle or make an optional dependency on one of the above serialization packages. If you have a favourite you want to argue for ping me on twitter. I am gregrluck.

This year’s JavaOne was a dismal affair. Crammed into the Hilton hotel and Parc 55, the feeling was that Oracle had ruined the conference. And the dual conference idea also caused Java people problems: those that tried to attend the key note at Moscone with JavaOne passes were turned away – instead needing to go to the Hilton ballroom to see it televised.

Last year, Larry shocked many with a goof ball suggestion to port OpenOffice to JavaFX. This year attendees were shocked to hear of the cancellation of JavaFX. Those giving and attending sessions on the topic felt it was futile. I was never convinced that JavaFX would be able to get the sort of dominance required to make it work as a browser platform. But what of Java 7, something I am interested in? The beer talk I heard at the Thirsty Bear, was that the JCP has stalemated for the past year on Java 7 over Oracle wanting to add a “restricted field of use condition” to it restricting the OpenJDK to desktop and server, not mobile. One possibility is for Oracle to abandon the JCP and just release it. The other rumour floating around is that future free versions of the JDK will be reference implementations, with higher quality or more fully featured versions only available under commercial license.

All of this suggests to me that Java as we have known it is over. Should we wait for Java to lose momentum and popularity to other languages? Or should we as a community step up and go in a new direction. I prefer the latter. Following is a sketch of how this could be done.

What to call the fork

Java is famous for coffee but also for volcanoes. So let’s call the new fork Lava.

Lava Foundation

We don’t want one company to take over the fork. What would be best is if  a foundation, like the Linux Foundation, Mozilla Foundation, or Eclipse Foundation be formed. This group would be funded by corporations with deep enough pockets to make it work such as Google, IBM, HP and RedHat.

It would be a non-profit foundation.

It would  perform the following duties:

Write Once, Run Anywhere

So how would we maintain this guarantee? The Lava compiler and Virtual Machine would remain backwardly compatible with Java 6. That way the vast array of existing code would work. Then depending on IP restrictions, Lava versions could add support for new language features in later versions of Java. If IP restrictions would preclude that it stays with Java 6.

The question then becomes whether developers would write to the new Java versions or to the evolving Lava. The answer likely would depend on market traction. In favour of Oracle is that it is the real Java. However  if you need to pay license fees to Oracle for the higher quality implementations you would likely want to run in production, then that would come at a cost. If enough commercial companies supported Lava so that it was very high quality, then developers would follow. And developers would want the open source version to win.

I am interested in what the community thinks of this idea. Ping me at gluck AT gregluck.com.

Updates

October 7:

Stefan Asemota created a Lava Foundation facebook page here.

October 14:

Well, some interesting developments have occurred in the last week. IBM and Oracle jointly announced that IBM was switching from project Harmony to OpenJDK and would:

work with IBM and others to enhance and improve the JCP.

What does this last one mean? Trink Guarino clarified this for me:

This includes improving the collaboration with other standards bodies, increasing the participation in the JCP processes and expert groups as well as improving the efficiency of the specification process.

A close reading of the various corporate blogs and press releases shows that the approach between the two companies was made after the reaction to this blog. So, here is hoping that IBM, by negotiating in it’s own interest, will also open things up for the community.

Finally, what about the conference? Happily I was asked to give some feedback on JavaOne, which I did in great detail. Beyond that I am going to Devoxx 2010 and will be speaking there on “The essence of Caching”. With Google there, and hopefully the European non-attenders of JavaOne this year, it should be a bumper conference and may well be the largest Java conference this year.

Today we released the press release for Ehcache’s new Off-Heap Memory Store. Later this week there will be a public beta.

Tonight we released the documentation for it which you can get here.

Well it has been a very West Wing few weeks here in Australia. A hung parliament, with 6 reps deciding the future Australian Government. In the end it came down to Tony Windsor, the member for New England, and broadband.

New England is a region in the north of NSW which takes in Armidale right up to the Queensland border, which is where I come in. Curlew Retreat, my country retreat, is in New England. And I have worked from there quite a bit on Ehcache. Indeed people like me, and how we connect to the Internet and what we can do with it, were central to Tony Windsor’s decision.

Curlew Retreat is remote. It is about 30km equidistant from it’s nearest towns. It is in rugged country and is out of mobile phone service. So a reasonable proxy for problematic country Internet access.

Now, I know one or two things about networking, and have, over the last 3 years, worked through a succession of ideas for Internet access. When I first set up the retreat I was considering dial-up. There is an old Telstra cable which cuts through my property. However with a rooftop antenna I was able to get Telstra Next G Internet access. I got 1GB for $60 per month. In the end it was very unreliable. Atmospheric conditions would cause it to disconnect up to twice per minute. This would cause my base station to drop the DHCP connections which played havoc with connected computers. The Maxon modem and base station would also crash. I told guests to turn power off to the retreat and then turn it back on to reset it.

All of these problems led me to satellite. Due to the Australian Government’s “Broadband Guarantee” I was able to get around $3,000 of satellite equipment for free, fully installed. I purchased mine from Active8me. I get 2GB per month for $29.95. This service, and the modem, have proved to be very reliable. Problem solved.

Which brings us to the election. Tony Windsor, decided to join with the ALP, on the basis that broadband to New England would be better if done with fibre. The ALP’s plan, with fibre to the curb for 93% of the population (which is about the percentage that is urban) and then enhanced satellite for the rest, is budgeted at $43 billion. The Coalition’s is a fraction of that, which uses fibre for trunks between cities and towns, and then a market for local delivery.

Now, will Curlew Retreat get fibre to the farm? No. The only difference is that the Coalition was going to bring enhanced satellite earlier. So for Curlew Retreat, there is disadvantage to the ALP plan. And Tony Windsor, who represents New England, made his decision for the ALP based on this??

Finally, for what it is worth, what will people do with fibre to the curb? My prediction is HD TV and movies on demand. And porn. I expect 3D HD porn to emerge as a format and be the main app that requires the fibre. Certainly my svn commits do not.