x86 KSSL benchmarks para aplicativos Java habilitados para SSL

Question

Então; A implementação SSL do Java não é particularmente rápida na maioria das circunstâncias. Eu tenho visto blogs demonstrando speedups perceptíveis quando um aplicativo Java é movido para o Solaris para tirar proveito de seu Kernel- SSL baseado.

Tudo isso está bem no hardware da Sun / Oracle (especialmente SPARC) que fornece aceleradores integrados, mas há algum material sobre o desempenho de um aplicativo Java quando a instalação do Solaris está em uma caixa Intel comum (ou mesmo um VPS) sem aceleração baseada em hardware?

i.e. Quanto a KSSL acelera um aplicativo Java ativado por SSL em uma caixa x86 Solaris?

    

Answer 1

Observe que o x86 pode obter alguma aceleração para SSL da CPU. Você pode obter uma lista de aceleradores executando cryptoadm list -mv . Até mesmo o provedor de software do kernel tem algumas otimizações. Esses fornecedores são os mesmos que executam o KSSL.

Para medir a diferença, siga por exemplo:

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

O primeiro é um software puro e o segundo é um provedor de kernel acelerado, acessível como token PKCS11. Exatamente esses dois no meu antigo T1 Niagara estão fazendo 8,4 signs / s contra 19740,0 sign / s. Isso é com certeza enorme diferença. Modernos processadores x86 podem acelerar o AES por exemplo e, até onde eu sei, ele é usado no provedor de kernel de software. Verifique você mesmo qual é a diferença. Mais importante é ter rápidas cifras assimétricas, porque elas são usadas durante o estabelecimento de uma conexão e são mais famintas por CPU ... aplicações web fecham conexão frequentemente.

O Btw KSSL é, na verdade, apenas um proxy de criptografia SSL do kernel ... um fato que acontece no kernel também ajuda a acelerar.

Apenas para comparar ... em outra máquina, ~ mesma idade do T1 mencionado acima, mas o x86 no VMware está fazendo para mim 42,1 sinais / s versus 98,6 sinais / s para o rsa2048. Então mais que dobrou a velocidade.

    

Answer 2

O proxy SSL do kernel do Solaris oferece melhorias de desempenho com base em:   1. dados de coalescência, para que sejam necessários menos syscalls de leitura () do aplicativo proxy   2. transferindo as operações de criptografia para os fornecedores de criptografia de hardware

A melhoria do primeiro ponto é provavelmente muito menor em comparação com o descarregamento da operação de criptografia. O segundo ponto depende do número de sessões SSL tratadas pelo KSSL, quantidade de tráfego, hardware subjacente e pacotes de criptografia usados pelos clientes e suportados pelo KSSL.

Em x86 no Solaris, o segundo ponto é atualmente visível apenas para conjuntos de cifras SSL / TLS baseados em AES em máquinas que suportam o conjunto de instruções Intel AES-NI. Isso é basicamente a Intel Westmere e mais tarde. Nenhuma outra codificação é atualmente acelerada em arquiteturas Intel / AMD, portanto, isso é válido apenas para dois conjuntos de codificação suportados pelo KSSL: rsa_aes_256_cbc_sha e rsa_aes_128_cbc_sha. Como isso é apenas aceleração de codificação simétrica, ele paga mais por transferências de dados em massa do que por conexões de curta duração com pequenas quantidades de dados.

Quanto à quantificação da melhoria de desempenho, testar isso com a velocidade openssl (1) fornecerá algumas dicas, mas deve-se tomar cuidado já que o mecanismo OpenSSL PKCS # 11 precisa atravessar várias camadas (mecanismo OpenSSL, metaskot PKCS # 11, PKCS # 11 kernel / dev / crypto API para o kernel) para que a sobrecarga das camadas possa distorcer muito as medições, especialmente para tamanhos pequenos de dados. O KSSL tem apenas uma camada muito fina (Kernel Crypto Framework API) para percorrer e não há sobrecarga de transição syscall para o processamento real de registros SSL.