1. Introdução
O pool de threads de negócios JSF usa a tecnologia de pool de threads do JDK e adota o modo cache por padrão (o número de threads principais é 20, o número máximo de threads é 200). Além disso, o modo de tamanho de thread fixo também é fornecido. Ambos os modos podem definir o tamanho da fila de solicitações.
Este artigo tem como objetivo fornecer resultados de benchmark para "configuração do tamanho do pool de threads de negócios JSF" por meio de testes de carga em um cenário simplificado ("aplicativo de serviço único") e tirar algumas conclusões geralmente aplicáveis.
Os leitores-alvo deste artigo incluem engenheiros de testes de estresse, engenheiros e arquitetos de desenvolvimento, implantação e operação e manutenção que precisam configurar razoavelmente o tamanho do thread JSF. Este artigo não cobre outros itens de configuração do servidor JSF, nem discute a configuração razoável de "aplicativos de serviço compostos". É possível usar as conclusões fornecidas neste artigo como referência para projetar casos de teste de estresse ou métodos básicos para avaliar o tamanho do conjunto de encadeamentos de negócios, para que você possa configurar razoavelmente o tamanho do conjunto de encadeamentos de negócios JSF na prática. Deve-se observar que a configuração razoável do tamanho do conjunto de encadeamentos de negócios JSF deve ser baseada em resultados de testes de carga de alta fidelidade.
"Aplicativo de serviço único" significa que o aplicativo contém apenas uma interface fornecida e apenas um método na interface.
"Aplicativo de serviço composto" refere-se a um aplicativo que contém diversas interfaces fornecidas ou uma interface que contém diversos métodos.
2. Descrição do caso de teste
Este teste de benchmark selecionou o sistema de permissão USF3.0 e o personalizou em um único provedor de serviços. Apenas um método do provedor foi testado, portanto pode ser considerado um "aplicativo de serviço único". No teste, a CPU é usada como recurso principal do teste de benchmark e, levando em consideração o impacto do coletor de lixo JVM, dados de teste simples são usados para garantir a consistência de cada chamada ao serviço e para garantir que o YGC tenha regularidade (ou seja, um valor fixo de chamada causará YGC de 30+ms por vez), sem a influência do FGC.
No design do caso de teste, todos os recursos de serviço dependentes são ilimitados para garantir que a taxa de disponibilidade do serviço atinja 100% durante o processo de teste. Nosso principal indicador de desempenho é o TP99, ou seja, 99% dos tempos de resposta do serviço devem ser inferiores a 10ms.
Para testar o desempenho em diferentes modos de pool de threads, usamos os modos Cache e Fixo do pool de threads JSF e conduzimos vários conjuntos de testes para cada modo para descobrir as condições de carga máxima do sistema.
Aplicação de teste : sistema de permissão USF3.0 (processamento personalizado)
Serviço de teste : com.jd.susf.service.api.SusfPermissionService#findUserInfo, um serviço retornado pela consulta de dados do Redis com base nas informações do usuário.
Configuração de hardware : único 4C 8G
Método de teste : O sistema Forcebot adotou um método de pressão de escada para conduzir testes de carga do sistema no pool de threads de negócios JSF nos modos Cache e Fixo.
Formular requisitos de SLA : TP99 de tempo de resposta de serviço <10ms
Observação: personalizamos o sistema de permissão USF3.0, ajustamos os dados de configuração do provedor de serviços e mantemos apenas com.jd.susf.service.api.SusfPermissionService.
3. Resultados e análises de testes
3.1. Carga do sistema do pool de threads em cache
Figura: Diagrama de carga do sistema do pool de threads padrão JSF (em cache, threads = 200) sob diferentes números de usuários simultâneos (1-200)
| Número de usuários simultâneos | TP99 | Taxa de transferênciaTPS | Utilização da CPU (%) |
|---|---|---|---|
| 1~23 | <8ms | crescimento linear | crescimento linear |
| 24 | 8ms | 6553 | 99,62 |
| 25 | 11ms | 6607 | 99,83 |
| 26~79 | Crescimento rápido | Crescimento lento | 99+ |
| 80 | 74ms | 6928 | 99,82 |
| 81~199 | aumentar lentamente | diminuir lentamente | 99,82 |
| 200 | 99ms | 6230 | 99,94 |
Resumo: A configuração padrão do conjunto de encadeamentos JSF apresenta grandes riscos. O sistema pode suportar no máximo 24 simultaneidades. Se mais de 24 simultaneidades forem alcançadas, o SLA não poderá ser cumprido.
3.2 Carga do sistema do pool de threads fixo (fila)
Figura: Diagrama de carga do sistema do conjunto de threads fixos JSF (fixo + fila) sob diferentes números de usuários simultâneos (1-50)
| Número de threads de negócios JSF | O número máximo de usuários simultâneos que podem ser suportados | Valor TP (50/90/99/999) | Taxa de transferência (TPS) | Utilização máxima da CPU (%) |
|---|---|---|---|---|
| 4 | 11 | 08/07/10/18 | 1531 | 27,67 |
| 8 | 25 | 8/8/10/18 | 3113 | 46,45 |
| 16 | 50 | 8/8/10/21 | 6228 | 87,97 |
| 20 | 23 | 04/03/10/15 | 6409 | 99,92 |
| 24 | 22 | 04/03/07/15 | 6178 | 99,86 |
| 25 | 22 | 04/03/06/15 | 6182 | 98,83 |
Tabela: Conjunto de threads de negócios fixos JSF (fixo + fila) atende à carga máxima do sistema (número máximo de usuários simultâneos) de TP99<10ms
resumo:
① No modo de thread fixo, há um limite máximo de utilização da CPU.
② O uso de filas pode aumentar efetivamente o suporte do sistema à simultaneidade e também melhorar o rendimento. Porém, como as tarefas estão aguardando na fila, o tempo de resposta do serviço aparecerá “uma maré alta levanta todos os barcos”, e há um certo risco.
3.3 Carga do sistema do pool de threads fixo
Figura: Carregamento do sistema quando o sistema tem o número máximo de usuários simultâneos no modo de pool de threads fixo JSF (fixo)
| Número de threads de negócios JSF | Número de usuários simultâneos | TP99 | Taxa de transferência (TPS) | Utilização máxima da CPU (%) |
|---|---|---|---|---|
| 4 | 4 | 5 | 1063 | 20h26 |
| 8 | 8 | 5 | 2216 | 36,62 |
| 16 | 16 | 6 | 4262 | 68,56 |
| 20 | 20 | 5 | 5550 | 86,22 |
| 24 | 24 | 8 | 6711 | 99,62 |
| 25 | 25 | 16 | 6644 | 98,77 |
| 26 | 26 | 19 | 6744 | 99,93 |
Resumo: Com base no desempenho do pool de threads fixo (fixo), é necessário definir um número razoável de threads para equilibrar a utilização total dos recursos da CPU e atender aos requisitos do SLA. Se o número de threads for muito pequeno, será levará ao desperdício de recursos da CPU e, se o número de threads for muito grande, isso não será possível. Cumpra o SLA
4. Conclusão
Com base nos resultados dos testes e na análise de dados, tiramos as seguintes conclusões:
- A configuração padrão do pool de threads JSF é arriscada em cenários com alta simultaneidade : poucos servidores onde os serviços JSF estão localizados em ambientes de produção online podem atender ao SLA mesmo com 200 threads. A configuração do pool de threads com no máximo 200 threads coloca o servidor em risco de ficar sobrecarregado em cenários com alta simultaneidade. A configuração adequada dos tamanhos do pool de threads deve vir de testes de carga de alta fidelidade.
- Um número suficiente de threads pode garantir a utilização de recursos (CPU) : Os serviços de negócios geralmente têm certas operações de IO (rede, disco, etc.) e a espera ocorrerá durante a execução do thread. A utilização da CPU não é alta e a simultaneidade precisa ser Somente aumentando o número de threads e permitindo que mais threads participem da alocação de CPU a utilização da CPU pode ser melhorada. Quanto mais operações de E/S no serviço, maior será o tempo de espera e mais threads simultâneos serão necessários. Para serviços de negócios com operações de E/S, o número de threads para teste de carga pode começar em 2N (N é o número de núcleos de CPU do servidor).
- Um número excessivo de threads apenas reduzirá o SLA do sistema : quando o número de threads já pode utilizar 100% da CPU, se você aumentar o número de threads, os threads não conseguirão obter alocação de CPU suficiente, então a resposta o tempo do serviço aumentará. Dentro de um determinado intervalo, o TP99 ainda pode atender aos requisitos do SLA e a taxa de transferência do sistema também aumentará ligeiramente. Se você continuar a aumentar o número de threads, o TP99 não será capaz de atender aos requisitos do sistema e a taxa de transferência do sistema começará a diminuir.
- O número fixo de threads pode proteger a capacidade de carga que o sistema precisa suportar : o número fixo de threads pode garantir que a utilização da CPU do sistema seja limitada a um determinado intervalo de carga, proteger a operação estável do sistema e garantir o tempo de resposta TP99, mas também limita a capacidade de simultaneidade do sistema. Definir corretamente o tamanho da fila pode aumentar a simultaneidade do sistema e não afetará o sistema TP99, mas aumentará o tempo geral de resposta do serviço e causará alterações instáveis, o que é arriscado.
- Deixe a CPU rodar com 100% de carga alta : Normalmente o compromisso de SLA externo do serviço costuma ser maior que o desempenho real do serviço, isso porque consideramos a instabilidade da infraestrutura e dos serviços dependentes. Portanto, mesmo que a CPU tenha atingido 100%, ainda podemos aumentar o número de threads em uma certa quantidade sem afetar o comprometimento do tempo de resposta externo TP99. Isso pode melhorar a capacidade de simultaneidade do sistema. Embora o sistema possa funcionar sob carga elevada, precisamos realizar mais testes de estabilidade para melhorar a confiabilidade do sistema.
Em resumo, a configuração razoável do tamanho do conjunto de threads precisa ser avaliada e testada com base nos requisitos de negócios e nas condições de recursos do sistema, e um espaço de buffer razoável deve ser reservado para garantir a operação estável do sistema e atender aos SLAs do usuário.
5. Apêndice
Apêndice 1: Descrição dos indicadores estatísticos e terminologia
Número de usuários simultâneos : o número de usuários que iniciam solicitações ao mesmo tempo.
Valor TP (50/90/99/999) : Valor TP do cliente, unidade ms, os dados vêm do Forcebot.
Taxa de transferência TPS : os dados vêm do Forcebot.
Utilização da CPU (%) : os dados vêm do PFinder.
Número de encadeamentos de negócios JSF : O número de encadeamentos no conjunto de encadeamentos de negócios JSF, como: <jsf:server id="jsf" protocol="jsf" threadpool="fixed" threads ="16" / >
fixo/em cache : tipo de conjunto de encadeamentos do conjunto de encadeamentos de negócios JSF, como: <jsf:server id="jsf" protocol="jsf" threadpool="fixed" threads="200"/>
Finalmente: O vídeo tutorial completo de teste de software abaixo foi compilado e carregado. Amigos que precisarem podem obtê-lo sozinhos [garantido 100% gratuito]
Documento de entrevista de teste de software
Devemos estudar para encontrar um emprego bem remunerado. As perguntas da entrevista a seguir são dos materiais de entrevista mais recentes de empresas de Internet de primeira linha, como Alibaba, Tencent, Byte, etc., e alguns chefes da Byte deram respostas confiáveis. Depois de terminar isto set Acredito que todos podem encontrar um emprego satisfatório com base nas informações da entrevista.
