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.