APRENDER. PRATICAR. EVOLUIR.1. Definir o limite da medição
Antes de calcular concorrência, decide o que entra e sai do sistema observado. Para um modelo estável de utilização de ligações, cada entrada adquire uma ligação e cada saída liberta-a. A ocupação média relaciona-se com taxa efetiva e tempo médio de retenção: L = λ × W. Quarenta utilizações por segundo durante 0,2 segundos em média representam oito ligações ocupadas em média. Esse oito não é uma recomendação de máximo do pool. Picos, variabilidade, esperas e margem operacional continuam a precisar de análise. Não mistures taxa global da aplicação com duração de uma operação que só parte dos pedidos executa. As grandezas devem referir-se ao mesmo limite e período.
2. Avaliar o efeito de retenções mais longas
Se a retenção média passar a 0,8 segundos, sustentar quarenta utilizações por segundo exigiria trinta e duas ligações ocupadas em média no modelo. Um pool limitado a vinte não pode apresentar trinta e duas ligações ocupadas nesse instante: o cálculo descreve procura incompatível com o limite. A fila pode crescer, o throughput cair ou pedidos falhar. Procura a causa da retenção, incluindo espera em dependências ou transações demasiado longas. Aumentar pool sem rever o backend pode deslocar a saturação. Compara também membros individualmente: um pool a vinte de vinte e outro vazio produzem cinquenta por cento agregado, mas a primeira JVM já está no limite.
3. Distinguir fila, serviço e trabalho pendente
Uma resposta média de quatrocentos milissegundos pode incluir trezentos de fila e cem de serviço. O utilizador sente ambos. Se o backend está saturado, duplicar threads de aplicação pode permitir mais trabalho concorrente sem aumentar conclusões úteis. Mede taxa de entrada, saída, erros e tempo por camada. Num exemplo separado de sessenta segundos, entram 45 pedidos/s e terminam trinta, sem perdas nem cancelamentos. O trabalho por terminar cresce novecentos pedidos. Isto é conservação de contagens num intervalo, não aplicação de uma hipótese de regime estável. Usa o resultado para explicar urgência e limites de admissão, mantendo claro se a medição inclui fila, execução ou ambos.
4. Dar um orçamento temporal a cada fase
Esperar por uma ligação do pool e esperar por dados numa ligação JDBC já adquirida são fases diferentes. Reduzir apenas o timeout de aquisição não limita por si só uma leitura de socket em curso. Confirma driver, versão e parâmetro aplicável antes de propor alteração. Um relatório que legitimamente fica vinte segundos sem receber dados pode falhar com um limite de leitura de cinco. A ausência posterior de avisos de threads demoradas não demonstra que o relatório passou a funcionar. Uma exceção local também não prova o resultado final de trabalho remoto. Define prazo total, fases, recuperação e forma de reconciliar operações quando o resultado é incerto.
5. Controlar tentativas e tempo total
Repetições podem ajudar com falhas transitórias, mas aumentam trabalho durante uma falha persistente. Num modelo com três camadas aninhadas e três tentativas totais em cada uma, um pedido pode gerar vinte e sete chamadas finais. O número resulta dos pressupostos do exercício; não é uma configuração predefinida WebSphere. Num segundo modelo, três tentativas de dois segundos e duas esperas de meio segundo somam sete segundos, excedendo um prazo total de cinco. Define onde o retry é coordenado, que erros são elegíveis e como se preserva idempotência. Backoff altera o momento das tentativas, mas não dispensa limites nem validação do orçamento temporal. Conta sempre a tentativa inicial de forma explícita.
6. Rever capacidade antes de acrescentar membros
Três JVMs com pools de vinte e cinco ligações e vinte ligações reservadas a outros consumidores totalizam um potencial de noventa e cinco. Com uma quarta JVM igual, o potencial passa a cento e vinte. Se o orçamento aprovado da base é cem, a proposta excede-o em vinte. Isto não mede sessões já abertas nem define automaticamente o desempenho, mas identifica uma incompatibilidade de configuração que precisa de decisão. Coordena aplicação, middleware e base de dados para avaliar máximos, reserva e carga representativa. Uma experiência de capacidade deve medir throughput útil, erros, filas e consumo com critérios de interrupção. Fecha a mudança com comparação antes/depois e evidência de que a operação de negócio continua correta.
SYNTHETIC MODEL / MODELO SINTÉTICO
40 uses/s * 0.2 s = 8 mean connections
40 uses/s * 0.8 s = 32 required mean connections
3 JVMs * 25 + 20 other = 95 potential connections
4 JVMs * 25 + 20 other = 120 potential connections
3 * 3 * 3 = 27 nested final calls
2 + 2 + 2 + 0.5 + 0.5 = 7 secondsModelo estável: 40 utilizações/s × 0,2 s = 8 ligações médias. Com retenção de 0,8 s, o objetivo exigiria 32. Um pool de 20 não suporta essa combinação no modelo.
Armadilhas comuns
Tratar média como máximo seguro, ocultar um membro saturado na média global, multiplicar retries sem orçamento ou confundir timeout de aquisição com leitura JDBC.
Tópicos relacionados: JDBC e transações · Concorrência e filas · Timeouts e retries
Calcula no mesmo limite e período, identifica o recurso restritivo e valida a mudança com throughput útil, tempos e resultados de negócio.
Referência: Statistics and queueing · DR WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30