Encadeamentos em um servidor da web orientado a eventos versus não orientado a eventos

9

Os dois diagramas a seguir são do meu conhecimento sobre como os threads funcionam em um servidor da Web orientado a eventos (como Node.js + JavaScript) em comparação com um servidor da Web não orientado a eventos (como IIS + C #)

A partir do diagrama é fácil dizer que em um servidor web tradicional o número de encadeamentos usados para executar 3 operações de longa duração é maior do que em um servidor da web controlado por eventos (3 vs 1.)

Acho que obtive o "servidor da web tradicional" como correto (3), mas me pergunto sobre o evento orientado a eventos (1). Aqui estão minhas perguntas:

  1. É correto assumir que apenas um segmento foi usado no cenário orientado a eventos? Isso não pode estar correto, algo deve ter sido criado para lidar com as tarefas de E / S. Certo?

  2. Como o servidor evented lidou com o I / O? Digamos que a E / S tenha que ler em um banco de dados. Eu suspeito que o servidor web teve que criar um thread para entregar o trabalho de se conectar ao banco de dados? Certo?

  3. Se o servidor da Web orientado a eventos realmente criou encadeamentos para manipular a E / S, onde está o ganho?

  4. Uma possível explicação para minha confusão pode ser que em ambos os cenários, tradicional e orientado a eventos, três encadeamentos separados foram de fato criados para manipular o I / O (não mostrado nas fotos) ) mas a diferença está no número de threads no servidor web, não nos threads de E / S. Isso é exato?

por Hector Correa 07.01.2013 в 04:31
fonte

2 respostas

5
  1. O nó pode usar encadeamentos para IO. O código JS é executado em um único encadeamento, mas todas as solicitações de IO estão sendo executadas em encadeamentos paralelos. Se você quiser que algum código JS seja executado em encadeamentos paralelos, use o thread-a-gogo ou alguns outros pacotes que diminuam esse comportamento.

  2. Igual a 1. , os encadeamentos são criados pelas operações Node for E / S.

  3. Você não precisa lidar com threads, a menos que queira. Mais fácil de desenvolver. Pelo menos esse é o meu ponto de vista.

  4. Um aplicativo de nó pode ser codificado para ser executado como outro servidor da web. Normalmente, o código JS é executado em um único thread, mas existem maneiras de fazer com que ele se comporte de maneira diferente.

Pessoalmente, eu recomendo o "threads-a-gogo" (o nome do pacote não é tão revelador, mas é fácil de usar) se você quiser experimentar os tópicos. É mais rápido. O Node também suporta múltiplos processos, você pode executar um processo completamente separado se você também quiser testá-lo.

    
por randunel 07.01.2013 / 12:19
fonte
0

A melhor maneira de fotografar o NodeJS é como um esquilo furioso (ou seja, seu segmento) rodando em uma roda com um número infinito de pombos (sua E / S) disponíveis para passar mensagens.

E / S no nó é "livre". Seu esquilo trabalha para estabelecer a conexão e mandar o pombo embora, depois pode fazer outras coisas enquanto o pombo recupera os dados, lidando apenas com os dados quando o pombo retorna.

Se você escrever um código ruim, você pode acabar tendo o esquilo esperando por cada pombo.

Portanto, sempre escreva código de E / S sem bloqueio.

Se você puder incentivar seus Pombos a prometerem voltar;)

Promessas e geradores são provavelmente a melhor abordagem que você pode adotar.

No entanto, você sempre pode usar o cluster Node para estabelecer um esquilo mestre que irá procriar os esquilos secundários com base no número de CPUs que o esquilo mestre pode encontrar para distribuir o trabalho.

Espero que isso ajude e note a completa falta de uma analogia com o carro.

    
por awjr 29.03.2016 / 17:34
fonte