Artigos

Falando sobre Node.js: Mas que diabos é isso?

Salve pessoal, bem… esse é meu primeiro post aqui no blog então por favor deixem suas opiniões e críticas sobre essa publicação no espaço de comentários lá embaixo. Vou tentar esclarecer algumas dúvidas sobre a tecnologia e ao mesmo tempo explicar seu funcionamento em algumas que permeiam a tecnologia em posts curtos e periódicos.

Um dos primeiros pontos a ser abordado é que Node.js não é uma linguagem de programação, então o que é isso? Node.js é uma plataforma baseada na Google V8 Engine ( mesma engine utilizada no Google Chrome ) que roda do lado do servidor escrito por uma equipe liderada por Ryan Dahl em 2009. Tal plataforma disponibiliza uma serie de ferramentas que variam desde um interpretador de linguagem javascript à uma forte API que permite o desenvolvedor trabalhar de forma fácil para criar aplicações em rede altamente escaláveis.

Ok… mas qual a grande diferença entre a infraestrutura fornecida pelo Node.js comparada a servidores como Apache, Tomcat, JBoss dentre outros? Para responder essa pergunta vamos observar o passo-a-passo o funcionamento de ambos.

Outros servidores:

  • Cliente faz a requisição;
  • Servidor atende e processa a requisição;
  • Servidor responde a requisição ao cliente;
  • Servidor está pronto para atender uma nova requisição.

 

servidor normal
retirada de “IIS is how to handle ASP.NET requests”

Node.js:

  • Cliente faz a requisição;
  • Servidor passa a requisição para processamento e se disponibiliza para atender a próxima requisição;
  • Servidor continua atendendo requisições a medida que elas vão acontecendo;
  • Servidor responde as solicitações a medida que seus processamentos vão sendo concluídos.

 

funcinoamento_node
retirada de “Node.js Performance Tip of the Week: Event Loop Monitoring”

Como foi descrito, diferente de outros servidores, o Node não trata a requisição como um todo para que ele possa estar disponível para tratar uma nova requisição do cliente, ele simplesmente a recebe, repassa para threadpool do servidor e já está disponível novamente para atender outra requisição do cliente.

Esse tipo de abordagem é o que tem atraído as atenções para a tecnologia, pois assim podem se criar aplicações que atendem uma grande quantidade de requisições (o que muito vantajoso quando se fala de aplicações pra internet) sem que hajam gargalos ou deadlocks em seus processos.

Referências:

IIS is how to handle ASP.NET requests

Node.js Performance Tip of the Week: Event Loop Monitoring

 

Melhores locais de aluguer de carros Portugal

5 Comentários

  • Marcelo Pereira

    Mr. legal tu falares sobre Node.js, uma tecnologia que vem ganhando adeptos. Porém, faltou mais pesquisa sobre o tema. Tu respondes a questão “que diabos é isso?” de maneira equivocada. Node.js é simplesmente uma máquina de execução. Esta tecnologia “ganha” poderes de um servidor a partir do momento em que tu te utilizas de módulos escritos pela comunidade para prover esta funcionalidade. Mas Node.js em si não é um servidor. É como se dissesse que a JVM é um servidor, quando na verdade os servidores de aplicação são aplicações construídas em cima da JVM. A JVM sozinha não faz nada. Daí eu não concordar com a sua comparação “outros servidores vs. Node.js”.
    Mas vamos dizer que o que tu quiseste dizer foi “outros servidores vs. servidores construídos em Node.js”. Tu colocas como se os outros servidores só ficam prontos para atender uma nova requisição uma vez que terminam de processar a primeira. Isto é um grande equívoco, uma vez que estes servidores que tu citas se utilizam de um thread-pool para processar várias requisições simultaneamente.
    O Node.js, por outro lado, não delega as requisições para um thread-pool. Se tu prestares atenção na referência que tu colocaste, o autor fala que o event loop delega tarefas de IO para o sistema operacional usando uma interface POSIX. Porém, todo o processamento no CPU é single-threaded (ao contrários dos outros servidores). A referência que você colocou inclusive mostra dicas para monitorar funções que podem estar “blockando” o event-loop, ou seja, não é o caso de o Node.js delegar a requisição e estar pronto para a próxima.
    Conclusão, Node.js é muito bom, mas gargalos e deadlocks nada têm a ver com utilizar outros servidores ou Node.js. Aplicações Node.js podem ter gargalos e a referência que você utilizou inclusive é sobre como preveni-los. A iniciativa foi muito boa, acho que você tinha que se aprofundar mais na tecnologia e enriquecer o blog com outros postos sobre o assunto. Curti a referência do “event loop monitoring”, já coloquei aqui nos meus favoritos.

    Um grande abraço!

  • Adalberto Júnior

    Salve Marcelo.
    Respondendo rapidão ao seu comentário:
    Concordo contigo que o Node.js não é um servidor, tanto que no segundo parágrafo eu deixo bem claro que é uma plataforma, que te fornece desde um interpretador de código ( V8 ) até uma boa API para desenvolvimento web de alta performance que internamente te permite instanciar um servidor ( vide o modulo nativo “http”). O que quis tentar explicar nesse post foi a forma diferente que a plataforma Node trabalha quando comparada com tecnologias “tradicionais” ( usemos como exemplo de comparação um servidor JavaEE ).

    Outro ponto que eu vou abrir debate é quando você cita a forma com a qual o Node trata as requisições. O que quis dizer é que cada thread de qualquer servidor “tradicional” que possui um thread pool precisa atender toda a request para estar disponível à atender outra.

    Com relação a single threading em node: Bem esse é o grande ponto de discussão nesse post. É válido dizer a plataforma Node é single threaded ? Sim ! A partir do momento em que você olha apenas pro event loop ( o que vai ser assunto de um próximo post ), mas quando esse evento loop recebe um evento onde existe uma função assíncrona ele cria um processo do teu sistema operacional, que acaba sendo tratada por uma thread, ou seja, ao invés de criar threads internas e ter de gerenciar elas na tua plataforma ele delega pro sistema operacional ! Mas não deixam de ser threads rodando em paralelo.

    Que bom que você gostou da referência que deixei, aqui embaixo tem mais uma do mesmo blog que fala exclusivamente sobre event loop:

    https://strongloop.com/strongblog/node-js-event-loop/

    E essa aqui é uma discussão que foi aberta no Stack Overflow sobre single threading em node.

    http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded

    Pra fechar, cara… muito obrigado pela crítica, creio que explicamos muito mais coisa aqui nesse debate do que no próprio post em si. Creio que foruns como esses só fazem a gente se aprofundar e interessar mais pelo assunto.

    Valeu!

  • Marco Balieiro

    Poxa tudo que eu ia apontar o Marcelo Pereira já falou. É isso mesmo Adalberto, ambos (servidores convencionais e servidores construídos com Node.js) processam requisições de forma simultânea, a diferença é o mecanismo (thread-pool ou single-thread com event loop).
    Esse mecanismo de event loop do Node.js é realmente o que faz com que ele possa tratar muito mais requisições simultâneas do que o conceito de thread-pool, pois usando thread-pool, ocorrem muitas trocas de contexto (preempção do processador) e demandam muito tempo de CPU com essas trocas.
    Muito boa a iniciativa e nos próximos posts você poderia falar sobre os diversos módulos do Node.JS (que o transformam desde um servidor web de páginas estáticas até servidores complexos com WebSockets ou Stream de vídeo).

    Grande Abraço!

  • Thiago Medeiros

    Realmente, curti para um post inicial foi bem Mr.

    Aguardo para ver a explicação mais detalhada do Event loop e threads assíncronas, que é o que acho mais legal na plataforma.

    E por último, só tenho a acrescentar que o Node.js nem é só um servidor (como dito anteriormente, pelo colega Marcelo Pereira), mas também não é atado a uma máquina virtual específica – há implementações do Node.js para várias VMs (Google V8, SpiderMonkey, JVM, .NET, etc), e o mesmo não é obrigatoriamente single-threaded (existe um fork chamado JXcore).

Deixe um comentário para Thiago Medeiros Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *