PierreJ's questions

Hipervisores comuns (Proxmox, Vmware, KVM..) não impedem que a soma dos recursos virtuais alocados (como vCPU) exceda o número de recursos físicos, mesmo que alguns deles (OpenStack) limitem a taxa de sobrecompromisso (recursos_virtuais/recursos_físicos ) para um valor configurável.

Estou confuso sobre este parágrafo deste artigo

Anteriormente, o XenServer permitia o overcommit de vCPUs. No entanto, esse comportamento é bloqueado, pois pode levar a efeitos indesejáveis ​​ao executar uma VM, uma vCPU que não pode corresponder a uma pCPU

Posso lê-lo como "o excesso de comprometimento está bloqueado no Xen" ou "uma VM não pode exceder o número de núcleos físicos, mas a soma de todas as VM vCPUs pode"

É (ainda) possível comprometer demais a CPU/memória com o Xen?

O Nginx é colocado na frente de uma arquitetura de microsserviços sobre a qual não temos nenhuma visão. Recuperamos as métricas expostas pelo status do stub http e gostaríamos de calcular um indicador do desempenho da plataforma: Não podemos usar latência em um teste de carga, pois queremos comparar sites geograficamente diferentes.

O que tentamos até agora:

• Calcule um delta do total de solicitações por unidade de tempo. Problema: não reflete o desempenho, todos os sites tratam a mesma quantidade de solicitações (100req por 100ms)
• Use o medidor de conexões em espera*

*Com este indicador, observamos diferentes comportamentos. Os dois extremos são:

Servidor 2012 (E5-2620 v1, 24 threads): média de 68,62 conexões em espera por 100ms

Servidor 2021 (AMD EPYC 7642, 96 threads): uma média de 91,96 conexões em espera por 100ms

Primeira pergunta. Parece que o medidor deve ser lido como "quanto maior, melhor". Por quê? A documentação não dá detalhes mas, até onde sabemos, uma conexão esperando por uma resposta deve aparecer aqui. Ou esse medidor é composto apenas por conexões ociosas (ou seja, já atendidas)?

Segunda questão. Em um mesmo teste de carga, as métricas de conexão aceitas/tratadas são muito maiores no servidor mais recente (em torno do dobro). Por quê? Ambos atenderam ao mesmo número de solicitações enviadas por um pool de 100 conexões. O que vemos é que a quantidade de conexões manipuladas progride muito rapidamente no início, até um valor limite diferente dependendo da arquitetura, e depois a progressão é bastante linear. Não encontramos nenhuma explicação para este comportamento mostrado neste gráfico: gráfico de conexões manipuladas