Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So; Java's SSL implementation is not particularly quick under most circumstances. I've seen blogs demonstrating noticeable speedups when a Java app is moved to Solaris to take advantage of its Kernel-based SSL.

That's all well and good on Sun/Oracle (especially SPARC-based) hardware that provide on-board accelerators, but is there any material on how a Java app would perform when the Solaris installation is on a commodity Intel box (or even a VPS) without hardware-based acceleration?

i.e. How much does KSSL speed up an SSL-enabled Java app on an x86 Solaris box?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Note that x86 can get some accel for SSL from CPU. You can get listing of accelerators by running cryptoadm list -mv. Even kernel software provider has some optimizations. Those providers are the same ones running KSSL.

To measure the difference run following for example:

/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11

First one is pure software and second one is kernel accelerated provider accesible as PKCS11 token. Exactly those two on my old T1 Niagara are doing 8.4 sign/s versus 19740.0 sign/s. That's for sure huge difference. Modern x86 CPUs can accelerate AES for example and as far as I know it is used in software kernel provider. Check yourself what's the difference. More important is to have speedy asymmetric ciphers, because they are used during establishing a connection and are more CPU hungry... web applications close connection often.

Btw KSSL is in fact just in kernel SSL encrypting proxy... a fact it happens in kernel contribute to speed too.

Just to compare... on another machine, ~ same age as T1 noted above, but x86 in VMware is doing for me 42.1 signs/s versus 98.6 signs/s for rsa2048. So more than doubled speed.

share|improve this answer

Solaris kernel SSL proxy delivers performance improvements based on: 1. coalescing data so that fewer read() syscalls of the proxy application are required 2. offloading crypto operations to hardware crypto providers

The improvement of first point is probably much smaller compared to crypto operation offload. The second point depends on number of SSL sessions handled by KSSL, amount of traffic, underlying hardware and cipher suites used by the clients and supported by KSSL.

On x86 on Solaris, the second point is currently visible only for AES based SSL/TLS cipher suites on machines which support the AES-NI Intel instruction set. This is basically Intel Westmere and later. No other cipher is currently accelerated on Intel/AMD architectures so this is only valid for 2 cipher suites supported by KSSL: rsa_aes_256_cbc_sha and rsa_aes_128_cbc_sha. Given this is symmetric cipher acceleration only, it pays out more for bulk data transfers rather than short lived connections with small amounts of data.

As for the quantification of performance improvement, testing this with openssl(1) speed will provide some hints but care should be taken since OpenSSL PKCS#11 engine has to traverse multiple layers (OpenSSL engine, PKCS#11 metaslot, PKCS#11 kernel /dev/crypto API to the kernel) so the overhead of the layers can skew the measurements quite badly, especially for small data sizes. KSSL only has one very thin layer (Kernel Crypto Framework API) to go through and there is no syscall transition overhead for the actual processing of SSL records.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.