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

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

因此,在大多数情况下,Java 的 SSL 实现并不是特别快。我已经看过的博客当 Java 应用程序移至 Solaris 以利用其基于内核的 SSL 时,速度会得到明显的提升。

这一切都在提供板载加速器的 Sun/Oracle(尤其是基于 SPARC 的)硬件上很好,但是有没有关于当 Solaris 安装在没有硬件加速的商用 Intel 机器(甚至是 VPS)上时 Java 应用程序的性能的材料?

即 KSSL 可以在多大程度上加快 x86 Solaris 机器上启用 SSL 的 Java 应用程序的速度?

答案1

请注意,x86 可以从 CPU 获取一些 SSL 加速。您可以通过运行获取加速器列表cryptoadm list -mv。甚至内核软件提供商也有一些优化。这些提供商与运行 KSSL 的提供商相同。

要测量差异,请执行以下操作:

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

第一个是纯软件,第二个是内核加速提供程序,可作为 PKCS11 令牌访问。我旧的 T1 Niagara 上的这两个程序每秒执行 8.4 次签名,而每秒执行 19740.0 次签名。这肯定是巨大的差异。例如,现代 x86 CPU 可以加速 AES,据我所知,它用于软件内核提供程序。自己检查一下有什么区别。更重要的是要有快速的非对称密码,因为它们是在建立连接期间使用的,而且更耗 CPU……Web 应用程序经常关闭连接。

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

只是为了比较...在另一台机器上,~与上面提到的 T1 年龄相同,但 VMware 中的 x86 为我提供了 42.1 个符号/秒,而 rsa2048 为 98.6 个符号/秒。因此速度提高了一倍多。

答案2

Solaris 内核 SSL 代理基于以下方式提供性能改进:1. 合并数据,以便减少代理应用程序的 read() 系统调用 2. 将加密操作卸载到硬件加密提供程序

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

在 Solaris 上的 x86 上,第二点目前仅适用于支持 AES-NI Intel 指令集的机器上的基于 AES 的 SSL/TLS 密码套件。这基本上是 Intel Westmere 及更高版本。目前没有其他密码在 Intel/AMD 架构上加速,因此这仅适用于 KSSL 支持的 2 个密码套件:rsa_aes_256_cbc_sha 和 rsa_aes_128_cbc_sha。鉴于这只是对称密码加速,它为批量数据传输付出的代价比为具有少量数据的短暂连接付出的代价更大。

至于性能改进的量化,使用 openssl(1) 速度进行测试会提供一些提示,但应小心谨慎,因为 OpenSSL PKCS#11 引擎必须遍历多个层(OpenSSL 引擎、PKCS#11 元槽、PKCS#11 内核 /dev/crypto API 到内核),因此层的开销可能会严重扭曲测量结果,尤其是对于小数据量。KSSL 只有一个非常薄的层(内核加密框架 API)需要通过,并且实际处理 SSL 记录没有系统调用转换开销。

相关内容