In our ISV Engineering organization, we do some pretty cool work with a variety of software companies built around open source business models;
here are just a few of our more strategic open source partners. This week, we
published some work we've been doing with
Terracotta for the last few months to help them optimize their technology on Sun's products. The 4-page document provides an overview of the business benefits of Terracotta for
Java developers, plus some results of testing we did with Terracotta on both
x64 and
CMT servers. We also ran their same tests on RedHat Enterprise Linux to see how we did. We did great.
I really like what Terracotta's done; my overly-simplistic explanation of what they do is to hook into a
Java Virtual Machine (JVM) and link it with other JVMs working together, so that a cluster of JVMs look like a single, big JVM to the Java developer. The significance is this: if you're a Java developer and you want to easily scale up your application so it can take on more load, Terracotta makes it really easy for you to do that.
In the document that we published, we showed the results of tests we did with sample workloads that Terracotta created to demonstrate what it can do for some common Java application scenarios. (one scenario models an online test-taking application where many people login concurrently to take their tests, maybe leave the test midway through, come back where they left off, etc.) If you look at the results table, you'll see a couple of results that I find interesting:
- Performance of Terracotta on Solaris vs. RedHat. Everything else was the same: same JVM, same physical hardware. But Terracotta on Solaris performed much better, making more efficient use of the compute resources. You leave less of your computing budget on the table with Terracotta on Solaris, is what this says to me.
- Terracotta performance on CMT. On the T5240 CoolThreads server, we didn't get the top result, but we had plenty of headroom to go (using 9% of the CPU resource available), which means we could launch more copies of Terracotta, or the Java application itself. Our tests with Terracotta show us we can use CMT to get massive scaling; the results table clearly reflects that.
Once we started scaling up with Terracotta on CMT, we started to notice that their persistence mechanism was becoming a bottleneck (if you
read more about Terracotta, you find that they make your cluster of JVMs reliable because Terracotta keeps track of Java objects that change, and persists those changes to its local disk). So we introduced Terracotta to our
solid state disk (SSD) products and configured the Terracotta server to persist its data to the SSDs instead of spinning disk. That essentially gave us reliability at in-memory speeds which means that you don't have to make the tradeoff of performance vs. reliability. It's very cool.
We've had a blast working with Terracotta; they're sharp people, and they create a product that I think is hugely valuable to Java developers, especially those trying to write apps that work at large scales on the web. If you're such a developer, you should check them out. Their software is available as open source and it works.
Powered by ScribeFire.
|
|
|
|
