支持SSL的x86应用程序的KSSL基准测试

Question

因此，在大多数情况下，Java的SSL实现并不是特别快速。当一个Java应用程序被移动到Solaris以利用其基于内核的SSL时，我的见过博客演示了明显的加速。

这在Sun/Oracle (尤其是基于SPARC的)硬件上很好，这些硬件提供了车载加速器，但是，当Solaris安装在普通英特尔(甚至VPS)而没有硬件加速的情况下，有什么关于Java应用程序如何运行的信息吗？

也就是说，KSSL在x86 Solaris盒上加速了启用SSL的Java应用程序多少？

Answer 1

请注意，x86可以从CPU获得一些用于SSL的accel。您可以通过运行cryptoadm list -mv获得加速器的列表。即使是内核软件提供商也有一些优化。这些提供程序与运行KSSL的提供程序相同。

例如，要度量差异，运行如下：

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

第一种是纯软件，第二种是内核加速提供者，可作为PKCS11令牌访问。就在我以前的T1尼亚加拉上，这两个人正在做着8.4个星座/S和19740.0个星座/S。这肯定有很大的不同。例如，现代的x86 CPU可以加速AES，据我所知，它被用于软件内核提供商。看看你自己有什么区别。更重要的是要有快速的非对称密码，因为它们是在建立连接时使用的，并且更需要CPU .web应用程序经常关闭连接。

顺便说一下，KSSL实际上只是在内核SSL加密代理.在内核中发生的一个事实也有助于提高速度。

只是为了比较..。在另一台机器上，~与T1上面提到的年龄相同，但x86 in VMware为我做了42.1个符号/S，而98.6个符号/ rsa2048代表rsa2048。所以速度加倍了。

Answer 2

Solaris内核SSL代理提供性能改进的基础是: 1.合并数据，以减少代理应用程序的read()系统；2.将密码操作卸载到硬件密码提供者

与密码操作卸载相比，第一点的改进可能要小得多。第二点取决于由KSSL处理的SSL会话的数量、通信量、客户端使用并得到KSSL支持的底层硬件和密码套件。

在Solaris上的x86上，第二点目前只对支持AES-NI Intel指令集的计算机上基于AES的SSL/TLS密码套件可见。这基本上是英特尔威斯特米尔和以后。目前没有其他密码在英特尔/AMD架构上加速，因此这只适用于两个由KSSL支持的密码套件: rsa_aes_256_cbc_sha和rsa_aes_128_cbc_sha。考虑到这仅仅是对称密码加速，它会为大量数据传输支付更多的费用，而不是使用少量数据的短暂连接。

至于性能改进的量化，使用openssl(1)速度测试它将提供一些提示，但是应该注意，因为OpenSSL PKCS#11引擎必须遍历多个层(OpenSSL引擎、PKCS#11元线程、PKCS#11内核/dev/crypto到内核)，因此层的开销可能会严重扭曲度量，特别是对于小数据大小。KSSL只有一个非常薄的层()，并且不存在用于实际处理SSL记录的syscall转换开销。