Ao executar o Apache Bench no mesmo servidor do site, como:
ab -n 1000 -c 10 localhost:8080/
Provavelmente não estou obtendo resultados precisos quando comparado a usuários que acessam o servidor de vários locais.
Estou tentando entender como ou melhor, por que isso afetará o desempenho no mundo real, já que um usuário na China terá problemas de latência diferentes quando comparado a alguém no mesmo estado/país.
Digamos que meu servidor web tenha um limite máximo de threads de 100.
Alguém pode explicar em detalhes como a latência do usuário final pode afetar o desempenho do servidor.
Estou assumindo aqui que cada solicitação será computada igualmente em, digamos, 10ms.
O que não entendo é como fatores externos podem afetar o desempenho geral do servidor, especificamente conexões de Internet (localização ou mesmo dispositivo como celular) e handshakes http/tcp, etc.
Responder1
Em geral, a latência do usuário final não afeta o desempenho do servidor. A principal diferença será que com maior latência do usuário final, seu servidor terá mais conexões por vez porque cada conexão demora um pouco mais para ser concluída. Mas o servidor ainda realiza aproximadamente a mesma quantidade de trabalho para cada conexão. Contanto que você não atinja as limitações do servidor, principalmente a memória, não importa.
O servidor não começará a fazer nenhum trabalho pesado para uma conexão até que tenha toda a solicitação. Portanto, se demorar mais para configurar a conexão e receber a solicitação, isso significará apenas que o servidor esperará um pouco mais, basicamente sem fazer nada, antes de realizar o processamento real.
Normalmente, o servidor processa a solicitação e enfileira a resposta de uma só vez. A latência do cliente e da rede pode significar que demora um pouco mais para esvaziar a fila. Mas a parte do servidor que lida com isso é altamente otimizada e a lógica da página ou objeto específico já foi executada até o fim, gerando a resposta. Então, novamente, normalmente não há efeito significativo no desempenho do servidor.
No entanto, a experiência do cliente pode ser muito pior. Isto é especialmente verdadeiro se o serviço tiver muitos casos em que o cliente precisa obter informações do servidor e depois conectar-se novamente para obter mais informações. Por exemplo, se uma página da Web diz ao cliente para carregar um monte de quadros e então esses quadros dizem ao cliente para carregar um monte de imagens, haverá muitas operações de "ida e volta" (cada uma aumentada pela latência da rede) antes do cliente vê um resultado. Mas o servidor faz a mesma quantidade de trabalho.
Responder2
Na verdade, isso não será um problema, a menos que você tenha um multi-multiprocessador operacional em tempo real (digamos, contagem de 1K CPU), um supercomputador com muita memória ...
Em um sistema multiprocesso, todos os processos possuem uma janela de tempo chamada Quantum Size. Os sistemas operacionais com capacidades multiprocessos, que é o caso aproximadamente dos anos 80 aos 90 até hoje, alternam entre os processos em execução, dando a cada um deles aquele tamanho quântico. Essa janela de tempo é de cerca de 20 milissegundos em nossos sistemas operacionais modernos e a comutação está sendo feita muito rapidamente, com sobrecarga de comutação muito baixa. Digamos, se tivermos uma CPU, dois processos sendo alternados, em 1 segundo, o que é igual a 1000 milissegundos, podemos executá-los por 900-950-980 (talvez) milissegundos (a diferença desapareceu para a troca de processos ). Enfim, como eu disse, essa troca é feita tão rapidamente e imaginando 50 processos rodando, vemos todos os processos rodando simultaneamente. Na verdade não são e isso é multiprocessamento, noções básicas de agendamento de processos...
Quando temos multithreads em processos, o SO agenda o processo primeiro e dá a ele um quantum, depois agenda os threads nesse processo. E nesse quantum, os threads também estão agendando. Quando todo o quantum termina, o SO agenda outro processo (ou o mesmo de acordo com o algoritmo de escalonamento) e os threads desse novo processo também são agendados.
Existem dois níveis de ambiente de execução para threads. Um é o nível do usuário, dois é o nível do kernel. O que mencionei acima é o nível do usuário. Agendamento de processos, agendamento de threads nesse tamanho quântico. Mas, quando você vai para o nível do kernel, o agendador pode agendar diferentes threads de diferentes processos. O quantum é aplicado a threads diretamente no nível do kernel...
Depois de falar sobre tudo isso, vamos começar a entender como a latência de uma conexão final pode afetar o desempenho do servidor:
Seus threads devem estar no nível do kernel se você quiser desempenho máximo, e eu sei que os threads do Apache não estão no modo kernel. O próprio Apache está no modo de usuário, é um aplicativo de usuário final e seus threads são executados no modo de nível de usuário. Então você não obterá 100% de desempenho desse servidor de forma alguma ... Digamos que os threads estejam rodando no modo kernel e você tenha dois CPUs. Um thread para a primeira CPU, um thread para a segunda. Agora, dois threads estão realmente sendo executados simultaneamente. Um thread de trabalho da web é na verdade um I/O Boundedthread do ponto de vista do sistema operacional e quando solicita algum arquivo, ele será bloqueado até que o arquivo esteja pronto. O Agendador agendará outro thread de trabalho para execução. Quando 'aquele' arquivo estiver pronto, o thread bloqueado será movido para a fila de prontos e será agendado novamente. Então, tudo bem... O que acontece se você tiver 100 threads de trabalho? Esta questão traz outra questão: Quando um thread de trabalho é criado?
Falando em aplicativos de servidor web, um thread de trabalho é criado quando o low-level IP connection is made. Então, seus dois threads reais já estão em execução, uma nova conexão estabelecida pelo hardware (eles têm suas próprias PUs e interrompem o sistema principal para transferência de informações de dados), um novo thread de trabalho apareceu, foi enviado para a fila pronta para agendamento ...
Voltando ao tema principal, como um fator externo afeta o desempenho do sistema. É tudo uma questão de limitações do sistema. A contagem de threads afeta o desempenho, independentemente de o sistema ter unidade de processo suficiente para lidar com eles ou não. Matemática básica, dois processadores processam apenas dois threads ao mesmo tempo... A má largura da conexão de rede afeta o desempenho em "quantas conexões ela pode aceitar". Digamos que os dados de uma conexão tenham 10 bytes e a largura de banda seja 100 bytes por segundo, você pode ter 10 conexões por segundo...
Dimensionar isso depende de você. Você precisa se lembrar de apenas uma coisa: seu recurso total de CPU já está processando os threads que já estão na fila de prontos... Então, quando um novo thread aparece, isso simplesmente não piora as coisas para os threads atuais.
O desempenho pode ser um problema quando o aplicativo do servidor. primeiro começa. Rapidamente atingirá o limite máximo. É uma espécie de aceleração de um carro. Ele irá acelerar primeiro e atingir a velocidade máxima depois de algum tempo. Você pode ir em velocidade máxima até ficar sem acelerador ou tirar os pés do acelerador.