WebLogic crypto operations and Sparc crypto acceleration

I've been doing a LOT of writing recently. Unfortunately, or perhaps fortunately depending on how you feel about my writing, it's all been by email to folks inside Oracle and directly with customers. One thing I wrote that is probably interesting for readers of this blog was an answer to a customer's questions about the crypto acceleration capabilities of the Sparc processor. This is a slight rewrite of that doc...

The crypto acceleration of Sparc and Solaris when it's used for SSL acceleration is right in the sweet spot of confluence between networking, crypto, performance and architecture. In other words just about my favorite place!

Before we get into the technical bits we should probably have a common picture in our heads about what sort of architecture we're talking about. When you deploy web apps you usually have user traffic hit a load balancer which then routes the traffic to your servers. The simplest diagram of that sort of environment is the three boxes diagram - like so:

There are a bunch of different styles of VIP / Load Balancer and there are various ways to configure them. The most common ways (in no particular order) are:
1) Terminate SSL connections at VIP/load balancer
2) Terminate TCP connection at VIP/load balancer, but pass traffic through unchanged
3) Transparent load balancing via a NAT style networking device.

I've seen various names for these technologies, so I'm not going to try to assign names to them for the purposes of this post.

In the case of #1 above the connection between the VIP/LB and the back end server is usually simple, unsecured HTTP. You might use this model if the load balancer has SSL acceleration technologies (either via a hardware card or some software optimization). In the case of #2 and #3 all of the SSL work is handled by the backend server.

Solaris on Sparc offers a few ways to really boost the performance of WebLogic Server. Read on to see what they are.



The Sparc processor, especially in its latest revision called the T3, offers some pretty amazing capabilities for crypto operations. The T3 includes 16 cryptographic acceleration engines that support a whole bunch of algorithms including not just AES, but the whole gamut of modern crypto algorithms and constructs. Things like AES, DES, 3DES, SSL, RSA and more. And it can do those operations at wire speed - which on the Sparc T3 is 10 GbE. To put that another way the Sparc T3 does crypto operations at ludicrous speed.

Check out this Wikipedia article and Oracle's web site on the T3 for more info on the processor for more in depth info.

Usually if you wanted to actually take advantage of the crypto acceleration capabilities of the processor your software would need to be specially written to make the necessary calls to the CPU. Thankfully Sun and Oracle thought ahead and wired these capabilities right into the JVM's crypto bits (also/formerly known as JCE). So if you run the Sun JVM on Solaris you've got access to the Sparc crypto acceleration for free! There's all sorts of great information out there about these features. A good place to start is this article on the Sun Performance and Best Practices blog. That post also points you to a couple of really great PDFs on Oracle technet that discuss Weblogic on the T Series and SOA and OWSM on T Series.

I don't want to rehash the entire content of that post, but this graph says it all:

The lowest line on that graph is the "all software" SSL; in other words WebLogic doing the crypto operations in the main CPU without taking advantage of the Sparc's crypto capabilities. The second line (black) shows what happens when you start using the crytpo accleration - things go twice as fast. The third line (red) is even more interesting - it represents enabling a Solaris feature called KSSL and shows that the SSL operations go about three times as fast as the software only implementation; KSSL is a bit more complicated than the normal WebLogic config and so deserves a bit more discussion.

What is KSSL?

KSSL is a really cool feature of Solaris that allows the OS to offload all of the SSL crypto work from user space to kernel space. Here's how that paper I linked to above describes KSSL:

KSSL is a Solaris kernel module that acts as a server-side SSL protocol for offloading operations such as SSL/TLS-based communication, SSL/TLS termination, and reverse proxies for end-user applications. KSSL takes advantage of the SCF to act as an SSL proxy server, performing complete SSL handshake processing in the Solaris OS kernel. KSSL uses the underlying hardware cryptographic accelerators (NCP and N2CP), PKCS#11 keystores, and Hardware Security Modules for enabling SSL acceleration and secure key storage.

Doing the SSL work inside the kernel saves a bunch system calls shuffling data back and forth between the kernel's memory space and user space so it's faster. As you saw in that graph it can be much faster. The way KSSL is implemented is a lot like the user space stunnel implemented within the kernel, or like what I described in #1 above but inside the OS kernel rather than in another box on the network; either way it's an SSL proxy server. The application doesn't even need to know that the user is speaking over an SSL channel.

So should you use KSSL?

The performance gain from using KSSL over just the PKCS #11 provider for JCE is going to depend on your workload. If requests that come into your app server are small and don't require much computational effort then KSSL may impart a huge performance boost. If the requests coming into your app server require the app to do a large amount of computation or require the app to talk to a database, SOAP service or something that's slow the performance gain from KSSL might be tiny. The only way to find out whether it's worth the effort to enable KSSL is to test in your environment with your workload.

Once you've load tested and have measured the performance gain you can decide whether you should use KSSL or not.

The bottom line

If you're running WebLogic (or indeed any Java application) on a Sparc T-series processor you should definitely enable the crypto acceleration capabilities by configuring the PKCS #11 provider. Whether you should use KSSL or not is dependent on your particular environment and uses of the software so you'll need to do some testing to see if it's worth your trouble.