Desempenho do PIX SPI JVM
Escalabilidade denomina a capacidade de realizar mais trabalho proporcionalmente ao aumento na capacidade do sistema que realiza o trabalho.
Quando nós tomamos um determinado sistema que nós sabemos que realiza trabalho em uma máquina com um processador, nós esperamos que este mesmo sistema realize o dobro do trabalho em uma máquina com dois processadores.
Na prática, devido a existência de diversos tipos de gargalo no sistema, desde o hardware, passando pelo sistema operacional, até a aplicação, a escalabilidade real será menor.
O objetivo deste trabalho é avaliar o desempenho do novo PIX SPI JVM 2.0 com ênfase na variável concorrência, isto é, na quantidade de trabalho sendo realizada concorrentemente.
Tomando uma arquitetura fixa, realizamos medições fazendo variar a quantidade de concorrência, com o intuito de verificar o impacto nas métricas latência (tempo de uma operação) e vazão (taxa de operações por unidade de tempo).
Imediatamente abaixo estão os resultados deste exercício, e mais adiante está uma descrição do nosso método. Clientes da Prodist interessados em um estudo de desempenho nas suas arquiteturas com a nossa ferramenta precisam apenas solicitar uma agenda ao nosso time de suporte técnico.
RESULTADOS:
Executamos nossa ferramenta de medição em uma máquina com 8 processadores e um cluster do Prodist STS com 2 servidores em máquinas com 8 processadores cada. Considerando um servidor STS como um coprocessador criptográfico, a configuração conta com um total de 24 processadores, 8 genéricos e 16 criptográficos. Medimos os tempos de um handshake mTLS 1.2 e de uma assinatura SPI.
Nesta arquitetura, obtivemos 2000 handshakes ou 4000 assinaturas por segundo, com ambos, no percentil 99, abaixo de 50 milisegundos.
A vazão, em ambas as métricas, cresceu linearmente até o nível de concorrência 8 com impacto imperceptível na latência; a partir do nível 16, o crescimento da vazão desacelerou e o impacto no percentil 99 da latência acelerou perceptivelmente; a partir do nível 24, o ganho em vazão cessou completamente.
Este exercício sugere que a proporção ideal de processadores para o PIX SPI JVM é de 1 genérico para 2 criptográficos. Em um estudo futuro, vamos verificar esta hipótese.
Handshake mTLS 1.2
Assinatura SPI
METODOLOGIA:
Arquitetura
Utilizamos AWS EC2 com uma VPC isolada e três máquinas conectadas a esta VPC na seguinte configuração:
Duas máquinas c5a.2xlarge com Windows Server 2019 e STS Server 7.0.3.
Uma máquina c5a.2xlarge com Ubuntu 22.04 e a ferramenta de microbenchmarking do PIX SPI JVM.
Ambos os Servidores STS com um domínio configurado para o protocolo RSFN 3 contendo um ISPB com uma chave privada, e o parâmetro read timeout configurado para 1000.
Arquivo de configuração do cluster editado para os dois servidores acima com o mesmo peso de 50%.
A JVM utilizada foi JDK 11.0.22, OpenJDK 64-Bit Server VM, 11.0.22+7-post-Ubuntu-0ubuntu222.04.1.
A ferramenta de microbenchmarking do PIX SPI JVM é uma aplicação da Java Microbenchmarking Harness (JMH), integrando:
- dev.prodist.certificates.jvm:certificates-sts:1.0-42+499d69f8
- dev.prodist.jca:jca:1.0-61+558a0557
- dev.prodist.keys.jvm:keys-sts:1.0-121+bc96d6e2
- dev.prodist.pix.spi.jvm:pix-spi-core:2.0-1194+22119c0a
- dev.prodist.sts.jvm:sts-api:2.0-302+7b32d934
- org.apache.santuario:xmlsec:2.3.1
- org.openjdk.jmh:jmh-core:1.37
Este é o template da linha de comando usada para executar medições:
java -jar pix-spi-core-2.0-1194+22119c0a-jmh.jar -bm ${mode} -jvmArgs ‘-
Ddev.prodist.pix.spi.licensing=file:///home/ubuntu/app-27.lic’ ‘-
pconfigurationFile=politicamsg.xml’ ‘-pmessageSize=1024’ -rf csv -rff ${mode}-
${concurrency}.csv -t ${concurrency} -tu ${unit} HandshakeBenchmark.handshakeWithKeyInSts
SignBenchmark.sharedWithKeyInSts
A ferramenta roda cinco séries de cinco iterações descartados e cinco iterações contabilizadas, cada iteração
executando por 10s. Para mais detalhes sobre os modos de operação e as métricas obtidas, veja a documentação
da JMH.
Handshake mTLS 1.2
Medimos o tempo de um handshake mTLS 1.2 aplicando SSLEngine diretamente sem o intermédio de conexões TCP, pelo mesmo procedimento usado na suite de testes automatizados.
Um handshake processa localmente com somente uma operação criptográfica RSASSA/PKCS1 (para autenticação do cliente) delegada para o cluster STS.
O SSLEngine do servidor foi configurado com chave privada em memória usando o KeyManager e o TrustManager padrão da JDK.
O SSLEngine do cliente foi configurado com chave privada no cluster Prodist STS usando o CoreKeyManager e o CoreTrustManager do Prodist PIX SPI JVM, exatamente como seria feito em produção.
Assinatura SPI
Medimos o tempo de sortear uma mensagem e assinar esta mensagem com uma única instância compartilhada do assinador.
Uma assinatura SPI processa localmente com somente uma operação criptográfica RSASSA/PKCS1 delegada para o cluster STS.
Sorteamos uma nova mensagem a cada vez para evitar o efeito de acessar sempre a mesma mensagem do cache do processador. O tempo deste sorteio contribui negativamente para a medição, já que este esforço não existe em produção. Para apoiar a atividade interna de Pesquisa e Desenvolvimento, a ferramenta inclui uma medição especial chamada random que mede exatamente este tempo. No ambiente deste exercício, o tempo médio de um random é de 12 μs.