 |
| Bellacosa Mainframe e a performance em mainframe |
☕💣🔥 O DIA EM QUE 10.000 USUÁRIOS DERRUBARAM UM COBOL QUE FUNCIONAVA PERFEITAMENTE — O GUIA DEFINITIVO DE TESTES DE PERFORMANCE PARA O PADAWAN DO MAINFRAME
Existem algumas frases que assustam qualquer profissional experiente de Mainframe.
Uma delas é:
"Pode colocar em produção. Já testamos tudo."
A segunda é:
"Funcionou na minha máquina."
E a terceira, talvez a mais perigosa de todas:
"Performance a gente vê depois."
Se você é um jovem Padawan do COBOL, provavelmente acredita que o trabalho do programador termina quando o programa compila sem erros, passa nos testes funcionais e devolve o resultado correto.
Mas existe um mundo oculto além da lógica.
Um universo onde programas corretos derrubam bancos.
Onde APIs perfeitamente desenvolvidas travam durante a Black Friday.
Onde um SELECT aparentemente inocente consegue transformar uma aplicação inteira em um incêndio corporativo.
Esse universo chama-se Performance.
E hoje vamos conversar sobre um assunto que separa programadores comuns dos profissionais que sobrevivem décadas trabalhando em ambientes críticos.
Vamos falar sobre Testes de Performance.
A PRIMEIRA GRANDE LIÇÃO
Imagine que você criou um programa COBOL chamado CONSULTA-SALDO.
O programa recebe:
Agência
Conta
Consulta o DB2.
Retorna o saldo.
Você testa.
Funciona.
Seu colega testa.
Funciona.
O analista testa.
Funciona.
O gerente testa.
Funciona.
Todo mundo comemora.
O programa sobe para produção.
Cinco minutos depois:
O Internet Banking trava.
O aplicativo móvel trava.
O atendimento telefônico trava.
O gerente da agência liga desesperado.
E você pensa:
"Mas aqui funcionava..."
Sim.
Funcionava.
Para um usuário.
Produção não possui um usuário.
Produção possui milhares.
Essa é a primeira lição da performance.
Um sistema que funciona para uma pessoa não necessariamente funciona para dez mil.
O QUE É UM TESTE DE PERFORMANCE?
Muitos iniciantes acreditam que teste de performance significa medir velocidade.
Não é apenas isso.
Teste de performance é a arte de descobrir como um sistema se comporta quando submetido ao mundo real.
Queremos responder perguntas como:
Quantos usuários suporta?
Qual o tempo de resposta?
Onde está o gargalo?
Quanto de CPU consome?
Quanto de memória utiliza?
Quantas transações por segundo processa?
Na prática estamos tentando descobrir o limite antes que o cliente descubra primeiro.
Porque quando o cliente descobre primeiro, normalmente já existe uma crise instalada.
TESTES FUNCIONAIS X TESTES NÃO FUNCIONAIS
O material apresentado faz uma separação extremamente importante.
Testes funcionais verificam:
"O sistema faz o que deveria fazer?"
Exemplo:
Você informa uma conta.
O sistema retorna o saldo correto.
Teste aprovado.
Mas existe outra pergunta.
"O sistema continua fazendo isso quando dez mil usuários acessam simultaneamente?"
Essa pergunta pertence ao mundo dos testes não funcionais.
E é exatamente aqui que entra a performance.
O EXEMPLO DO AUTOMÓVEL
Imagine um carro.
Você gira a chave.
O motor liga.
Teste funcional aprovado.
Mas ainda faltam várias perguntas:
Qual a velocidade máxima?
Quanto consome?
Quanto suporta de carga?
Como se comporta em uma subida?
Como reage após cinco horas de viagem?
Essas perguntas representam os testes não funcionais.
O mesmo vale para sistemas.
O QUE REALMENTE DERRUBA SISTEMAS?
O Padawan normalmente pensa:
"Se estiver lento é porque falta CPU."
Nem sempre.
Na verdade, CPU costuma ser apenas um dos suspeitos.
Os verdadeiros vilões geralmente são:
SQL mal escrito
Índices ausentes
Locks excessivos
Filas MQ congestionadas
Chamada excessiva a serviços
Pool JDBC esgotado
Recursos compartilhados
Em outras palavras:
O problema normalmente não está onde você imagina.
TESTE DE CARGA
Este é o mais conhecido.
O objetivo é reproduzir o uso normal esperado.
Imagine:
O banco estima 5.000 usuários simultâneos.
Criamos então um cenário simulando exatamente esse volume.
A pergunta é simples:
"O sistema suporta?"
Se suporta, ótimo.
Se não suporta, ainda temos tempo para corrigir.
Muito melhor descobrir isso no laboratório do que no Jornal Nacional.
TESTE DE ESTRESSE
Aqui a conversa fica interessante.
Em vez de testar o limite esperado, ultrapassamos o limite.
Muito.
Se o ambiente foi projetado para 5.000 usuários:
Testamos 10.000.
15.000.
20.000.
Queremos descobrir:
Como ele falha?
Uma falha controlada é muito melhor que um colapso inesperado.
TESTE DE RESISTÊNCIA
Agora imagine uma maratona.
O sistema suporta 5.000 usuários.
Ótimo.
Mas por quanto tempo?
Uma hora?
Duas?
Dez?
Vinte e quatro?
O teste de resistência mantém carga constante durante longos períodos.
Muitas aplicações parecem saudáveis por trinta minutos.
Depois começam a consumir memória.
Depois mais memória.
Depois ainda mais memória.
Até morrerem lentamente.
É o famoso Memory Leak.
TESTE DE PICO
Imagine a abertura das vendas de um show.
Ou a Black Friday.
Ou o lançamento de um PIX promocional.
O tráfego explode.
O sistema precisa absorver esse impacto.
O teste de pico verifica exatamente isso.
O comportamento durante explosões repentinas.
O MUNDO HÍBRIDO
Antigamente era simples.
Usuário.
Tela.
Mainframe.
Fim.
Hoje não.
Hoje temos:
Aplicativo Mobile
↓
Apache
↓
WebSphere
↓
API Gateway
↓
Microsserviços
↓
MQ
↓
CICS
↓
COBOL
↓
DB2
Percebe o problema?
Se a tela demora cinco segundos, onde está o gargalo?
Pode estar em qualquer ponto da cadeia.
E é por isso que observabilidade se tornou tão importante.
APACHE JMETER
Se existe uma ferramenta que virou símbolo dos testes de carga modernos, essa ferramenta é o Apache JMeter.
Pense nele como um exército virtual.
Você configura usuários fictícios.
Esses usuários começam a executar operações.
Consultar saldo.
Fazer transferência.
Emitir extrato.
Pagar boleto.
E o sistema acredita que são usuários reais.
O JMeter consegue gerar milhares de acessos simultâneos.
É exatamente assim que simulamos produção sem colocar clientes reais em risco.
EXEMPLO PRÁTICO
Suponha uma API:
GET /saldo
Queremos simular:
5.000 usuários.
Criamos:
Thread Group
Usuários: 5000
Ramp-Up: 300 segundos
Loop: infinito
Agora adicionamos:
HTTP Request
Executamos.
Pronto.
Começamos a produzir carga.
Mas isso é apenas metade da história.
POR QUE APENAS GERAR CARGA NÃO BASTA?
Imagine um médico.
Ele mede sua pressão.
Mas ignora:
Frequência cardíaca
Oxigenação
Temperatura
Seria um diagnóstico completo?
Claro que não.
Com performance ocorre a mesma coisa.
Gerar carga é apenas o começo.
Precisamos observar o ambiente inteiro.
DYNATRACE
É aqui que entra o Dynatrace.
Pense nele como uma tomografia computadorizada da aplicação.
Ele acompanha cada requisição.
Cada chamada.
Cada serviço.
Cada banco de dados.
Cada microsserviço.
Cada transação.
Em vez de simplesmente dizer:
"Está lento."
Ele mostra:
"Está lento porque o Serviço X chamou o Serviço Y que executou uma consulta SQL custosa."
Agora existe informação para agir.
O SONHO DE TODO ANALISTA DE PERFORMANCE
Imagine um clique no aplicativo.
Consultar saldo.
Dynatrace exibe:
Frontend = 80 ms
API = 100 ms
Microsserviço = 120 ms
CICS = 800 ms
DB2 = 700 ms
Pronto.
Achamos o culpado.
Não existe mais adivinhação.
GRAFANA
Se Dynatrace é o médico.
Grafana é o painel da UTI.
Ele transforma números em gráficos.
Mostra:
CPU
Memória
Throughput
Erros
Tempo médio
Percentil 95
Percentil 99
E permite acompanhar tudo em tempo real.
Uma imagem muitas vezes vale mais que mil relatórios.
O QUE O MAINFRAME ENSINA SOBRE PERFORMANCE?
Muito antes da palavra observabilidade virar moda, o Mainframe já monitorava tudo.
E quando digo tudo, é tudo mesmo.
O z/OS nasceu para ambientes críticos.
Por isso existem ferramentas extremamente sofisticadas.
SMF
System Management Facility.
Registra praticamente tudo.
CPU.
I/O.
Transações.
Consumo.
Execução.
É o grande livro de registros do sistema.
RMF
Resource Measurement Facility.
Analisa comportamento dos recursos.
Ajuda a identificar gargalos.
Mostra utilização de processadores.
Filas.
Memória.
Dispositivos.
OMEGAMON
Uma das ferramentas mais famosas do universo IBM.
Monitora:
z/OS
CICS
DB2
MQ
Em tempo real.
Quando algo fica lento, geralmente ele é um dos primeiros lugares onde o especialista procura respostas.
O MAIOR ERRO DOS PROGRAMADORES INICIANTES
O Padawan costuma pensar:
"Meu programa executa rápido."
Mas rápido para quem?
Com qual volume?
Em qual horário?
Contra qual banco?
Com quantos registros?
Essas perguntas mudam tudo.
Um SELECT que retorna dez linhas parece maravilhoso.
O mesmo SELECT retornando dez milhões de linhas pode virar um desastre.
O CASO DO LOOP INOCENTE
Imagine:
PERFORM UNTIL EOF
READ ARQUIVO
PROCESSA
END-PERFORM
Parece simples.
Mas e se o arquivo possuir:
50 milhões de registros?
Agora o cenário muda.
Performance não depende apenas do código.
Depende dos dados.
PERFORMANCE É ARQUITETURA
Muitos acreditam que performance é responsabilidade exclusiva da infraestrutura.
Não é.
Também não é responsabilidade exclusiva do desenvolvedor.
Performance é responsabilidade de todos.
Arquitetura.
Banco.
Infraestrutura.
Rede.
Aplicação.
Integração.
Monitoramento.
Tudo influencia.
A MENTALIDADE DO PROFISSIONAL MADURO
O iniciante pergunta:
"Funciona?"
O profissional experiente pergunta:
"Funciona sob carga?"
O iniciante pergunta:
"Retornou o resultado?"
O profissional experiente pergunta:
"Quanto tempo demorou?"
O iniciante pergunta:
"Passou no teste?"
O profissional experiente pergunta:
"Qual foi o consumo?"
Essa mudança de mentalidade transforma carreiras.
A LIÇÃO FINAL
Ao longo dos anos vi programas COBOL sobreviverem décadas.
Vi sistemas processarem bilhões de transações.
Vi ambientes suportarem eventos gigantescos sem falhar.
E todos tinham algo em comum.
Performance não era tratada como um detalhe.
Era tratada como requisito.
Porque funcionalidades atraem usuários.
Mas é a performance que permite que eles permaneçam utilizando o sistema.
No fim das contas, um programa COBOL não é avaliado apenas pelo que faz.
Ele é avaliado pela velocidade, estabilidade e capacidade com que faz aquilo.
E essa é a diferença entre escrever código e construir sistemas capazes de sobreviver ao mundo real.
Bem-vindo ao próximo nível da sua jornada no Mainframe, jovem Padawan.
Agora você já sabe que compilar é apenas o começo.
