Friday Aug 14, 2009

Terracotta on Sun's CMT and x64 Solaris servers

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:
  1. 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.
  2. 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.

Wednesday Oct 08, 2008

Some questions about Sun's M-series servers

I had the pleasure of meeting with an ISV yesterday who is interested in simplifying how they deploy their solution to customers.  To make a long story short, simplification for them will result in more stable deployments for their customers, who can really stress the solution of software + hardware system.  So they came to Sun to talk about our systems.

A couple of questions came out of the meeting and I agreed to follow up; I figured I'd post the answers here, because the questions are not proprietary and the answers aren't, either.

Question #1: how many power supplies on an M4000 server?
Answer: 2.  The Sun SPARC Enterprise M4000 Server has two power cords coming into the box, in what we call a 1 + 1 redundant power supply configuration.  The M4000 needs only one power cord coming into the system to power it, but we have a second power supply just in case the 1st one fails.

(by the way, the M5000 server has four power cords.  Why?  It uses two power supplies active to power the server, and each of those has a redundant power supply.)

Here are the specs for the M4000 server, which comes from the Sun System Handbook.

Question #2: what kind of monitoring interface does the M-series server have?

Answer: I hope I'm answering the question that was asked here.  I recall that one question had to do with what the console looks like when you log into it: ALOM or ILOM-style interface?  (these have two different styles of giving commands to the server when you log into the console)  According to the technical lead in our ISV Engineering Labs datacenter, the M4000's console interface looks kind of like the SunFire 6800's style, which is (and I quote) "ALOM-ish".

And here is the documentation for the M-series's console, called the XSCF (eXtended System Control Facility).

If this isn't answering the question you asked, let me know what you need to know and I'll happily track it down.

Powered by ScribeFire.

Friday Sep 12, 2008

Sun Ray / VOIP In One Piece of Hardware

There's a company called Mitel that makes unified communications products.  Sun and Mitel recently came out with a webcast that shows this cool product called the Mitel Unified IP Client for Sun Ray.

Check out the webcast, but for me the coolest part was around 13:20 into the cast when they show one of these Mitel phones that has a Sun Ray built into it!  It was cool: you just slide your Java Card into the slot at the bottom of the phone cradle, and the phone's display shows your info, and the monitor connected to the phone shows your Sun Ray session.  Plus, the phone itself has a wireless handset so you can walk up to 1000 feet away from the phone cradle.

Pretty cool stuff; it makes me want one.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. What more do you need to know, really?


« July 2016