Análise e uso de testes de desempenho

Análise e uso de testes de desempenho

1. Por que testar o desempenho?

O sistema xx foi lançado com sucesso. De acordo com o planejamento do projeto anterior, ele está planejado para atender mais de 1000 clientes. No futuro, inevitavelmente haverá uma tendência de crescimento massivo de informações no sistema comercial.
À medida que o sistema se torna mais estável na produção, ele nos permite focar mais nas questões de desempenho:

1. Quantos dados podem ser tolerados?

2. Qual é o gargalo do sistema?

3. Como está a qualidade do código?

   Essas perguntas precisam ser respondidas por meio de testes de desempenho

2. A que se deve prestar atenção?

1. Esclareça o objetivo do teste

性能测试的目的分为两种：

• Verificação: Verifique se o sistema está em conformidade com os requisitos de desempenho relevantes. Tais como: para atender as solicitações simultâneas de 500 pessoas

• Posicionamento e ajuste: obtenha dados relevantes por meio de testes e analise, posicione e ajuste os dados.

2. Determine o conteúdo do teste

• Esclarecer pontos e prioridades de negócios

• De acordo com a prioridade de função e desempenho para dividir o nível de prioridade do negócio, determine o negócio a ser testado e o negócio não testado

• Determine os requisitos de desempenho relevantes para diferentes negócios e cenários: throughput, tempo de resposta, etc.

3. Entenda a categoria de teste de desempenho

1. Testes de Nível de Rede Testes Atuais

   Taxa de transferência e tempo de resposta

2. teste do sistema operacional

   utilização da CPU, taxa de troca de disco

3. Teste de nível de banco de dados

   O número de conexões de banco de dados simultâneas, o número de recursos de bloqueio usados ​​e o tamanho do tráfego de E/S

4. Fatores afetados

1. Largura de banda de rede como: Ali 50M 100M

2. O número de servidores, como: servidor Aliyun

3. CPU do servidor, memória e outros desempenhos, como: unidade de estado sólido 2G 8G da Ali, disco rígido mecânico

4. Versão do sistema operacional do servidor

5. qualidade do código

3. Operação básica

Jmeter usa o endereço online do documento: [https://blog.csdn.net/r657225738/article/details/114981779]{.underline}

1. Solicitação http simples

2. Variáveis ​​de usuário personalizadas

3. Extraia os dados da solicitação e armazene-os no arquivo

Cenário: adição em lote,
componentes necessários para consulta em lote : [extrator de expressão regular->programa de pós-processamento BeanShell] Nota:
codificação de texto: utf-8

4. Use o arquivo CSV para ler os dados

Cenário: edição em lote, exclusão em lote

Componentes necessários: [configuração do arquivo de dados CSV]

4. Use dados para falar

1. Comparação antes e depois da otimização do código

问题列表-我的问题

---

2. A diferença de desempenho entre cópias simples e duplas

5. Resumo da experiência

1. Ideias de otimização de código

Exibir logs de operação da API por meio do rastreamento de link APM

• 1. Reduza o acesso desnecessário à biblioteca

  2. Reduza chamadas de dados desnecessárias

Exemplo: Lista de problemas - Meus problemas antes e depois da atualização

Por meio de testes e ajustes de código, há dois pontos que precisam da atenção de todos

• 1. Ferramenta de teste: Jemter para testes simultâneos

  2. Localização do problema: a API específica encontra a direção do código de otimização por meio do rastreamento de link APM da intranet

chegar a conclusão:

1. No teste de simultaneidade, a assincronia da API melhorará diretamente o desempenho. Se a API não for escrita de forma assíncrona com 20 simultaneidades, a taxa de transferência pode ser tão baixa quanto um dígito. Depois que a API é alterada para Tarefa assíncrona, com 100 simultaneidades, a taxa de transferência pode alcance 150-200

2. A remoção de acesso desnecessário à API no código pode continuar a melhorar o desempenho, e a melhoria de desempenho é óbvia. (Relacionado ao número de acessos à API irrelevantes removidos) No teste, 100 simultaneidade, a taxa de transferência pode chegar a 200-250

2. Solução de erro de API durante o teste de desempenho

在保证API地址与参数填写正确的情况下,如还报错则为以下两种情况

1. Relatório API 500

1.1数据库崩溃,卡死,需要重启

2. A API reporta 404

2.1所在企业Api服务卡死,需要重启

Seis. Pouco conhecimento

6.1 Significado dos parâmetros no relatório de agregação

• Valor mínimo : refere-se ao tempo mínimo necessário para retornar os dados após a solicitação ao servidor

• Valor máximo : refere-se ao tempo máximo necessário para retornar os dados após a solicitação ao servidor

• Valor anormal : refere-se à proporção de requisições que serão desconectadas ou conectadas de forma anormal

• TPS (taxa de transferência) : refere-se a quantas solicitações podem ser processadas por segundo, como 120/seg, ou seja, 120 solicitações de rede podem ser processadas por segundo. 20/min, ou seja, por minuto

• Média : Refere-se à média da soma de todos os tempos de resposta da solicitação

• 99% : Significa que 99% das requisições estão abaixo desta faixa, como 354ms / 99%, ou seja, 99% das requisições completam a resposta antes de 354ms

6.2 Aumentar o papel de Replicado (cópia) /Escala (escala)

1. Entenda por si mesmo: o Docker gastará menos tempo criando uma nova instância em outro nó quando ocorrer uma falha, o que ajuda a melhorar o desempenho e reduzir as taxas de falha. Por exemplo, atualmente existem três cópias (replicadas), quando uma das cópias (Servidor) será automaticamente transferido para uma cópia disponível quando não puder suportá-la.

2. Explicação profissional: Vamos pegar uma cópia contendo uma única instância como exemplo. Agora, suponha que haja uma falha. O Docker Swarm notará que o serviço falhou e o reiniciará. O serviço será reiniciado, mas a reinicialização não é instantânea. Digamos que leva 5 segundos para reiniciar. Durante esses 5 segundos, seu serviço fica indisponível. ponto unico de falha.

E se sua réplica contiver 3 instâncias. Agora, quando uma delas falhar (sem serviço perfeito), o Docker Swarm perceberá que uma das instâncias está indisponível e criará uma nova. Durante esse tempo, você ainda tem 2 instâncias íntegras atendendo a solicitações. Para os usuários do seu serviço, parece não haver tempo de inatividade. Este componente não é mais um ponto único de falha.

6.3 Regras de agendamento de escala

将node1宕机后或将node1的docker服务关闭，那么它上面的task实例就会转移到别的节点上。当node1节点恢复后，它转移出去的task实例不会主动转移回来，只能等别的节点出现故障后转移task实例到它的上面。使用命令\"docker node ls\"，发现node1节点已不在swarm集群中了。

6.4 Significado popular de alta simultaneidade

Por exemplo, digamos que você abra uma lanchonete.

Você tem 3 caixas (encadeamentos de processamento de solicitações da web), 5 chefs (conexões de banco de dados).

No início, o negócio não durou muito. Há menos convidados. 1 caixa registradora pode lidar com isso. Outros ainda estão ociosos.

Mais tarde, o negócio ficou cada vez melhor. Portanto, todas as 3 caixas registradoras estão funcionando (simultaneamente).

Como resultado, depois de um tempo, uma celebridade da Internet apareceu e, de repente, a loja se tornou popular e um grande grupo de pessoas (alta simultaneidade) veio aqui com admiração.

Com isso, os três caixas ficavam na frente das filas dos grandes nomes (os pedidos eram bloqueados e enfileirados), e os caixas não eram robôs, e às vezes erravam no pedido (exceções simultâneas).

Olhando para o chef na parte de trás, há cada vez mais pedidos. O chef tem cozinhado e cozinhado e está ficando cada vez mais cansado, e o cozimento está ficando cada vez mais lento (a pressão no banco de dados é alta e o tempo de resposta da solicitação está ficando mais longo).

Quanto mais devagar os pratos saírem, mais pessoas ficarão atrás (um círculo vicioso depois que o pedido é bloqueado).

Alguns clientes saíram sem esperar (o atendimento era hora extra), e até te deram uma crítica negativa, o que afetou o humor deles (afetou o atendimento de nível superior).

Quanto ao chef por trás, depois de fazer N pratos, ele finalmente não aguentou mais, e não aguentou mais (a conexão com o banco de dados estava esgotada).

Assim, a pequena loja só pode suspender a coleta de clientes (o servidor rejeita a solicitação e informa o erro 502).

6.5 Significado comum de taxa de transferência e número simultâneo

Caso 1: taxa de transferência e simultaneidade são dois conceitos completamente independentes. Pegue o balcão do banco como exemplo. Contagens simultâneas referem-se a quantas pessoas estão correndo para o balcão do banco ao mesmo tempo. A taxa de transferência refere-se a quantas pessoas o balcão do banco pode atender em um período de tempo

Caso 2: Uma torneira é aberta por um dia e uma noite e saem 10 toneladas de água; 10 torneiras são abertas por 1 segundo e saem 0,1 tonelada de água. É claro que a taxa de transferência de um toque é grande. Você pode dizer que a capacidade de saída de água de 1 torneira é melhor do que a de 10 torneiras? Portanto, precisamos somar a unidade de tempo para ver quem tem mais água em 1 segundo. Esta é a taxa de transferência de 0,1 toneladas de água/segundo
, erro 502).