Aqui estão 10 regras de desempenho que seguimos ao usar o Node.js:
1. Evite usar código síncrono
Em termos de design, o Node.js é um thread único. Para permitir que um único thread lide com muitas solicitações simultâneas, você nunca pode deixar o thread aguardar operações de bloqueio, síncrono ou de longa duração. Uma característica distinta do Node.js é que ele foi projetado e implementado de cima para baixo para obter assíncrono. Isso o torna muito adequado para programas do tipo eventos.
Infelizmente, ainda existe a possibilidade de ocorrer chamadas síncronas/de bloqueio. Por exemplo, muitas operações do sistema de arquivos têm versões síncronas e assíncronas, como WriteFile e WriteFilesync. Mesmo se você usar o código para controlar o método de sincronização, ainda é possível usar a biblioteca de funções externas que bloqueia as chamadas inadvertidamente. Quando você faz isso, o impacto no desempenho é enorme.
// bom: gravar arquivos assíncronos.writefile ('message.txt', 'hello node', function (err) {console.log ("é salvo e o servidor permanece responsivo!");}); // ruim: gravar arquivos síncronoss.writefilesync ('message.txt', 'hello node'); console.log ("É salvo, mas você acabou de bloquear todas as solicitações!");Nosso log de inicialização inclui sem querer uma chamada síncrona para gravar conteúdo no disco quando implementado. Se não fizermos testes de desempenho, será fácil ignorar esse problema. Ao usar uma instância Node.js na caixa de desenvolvedor como teste padrão, essa chamada síncrona fará com que o desempenho caia de milhares de solicitações por segundo para apenas algumas dezenas.
2. Feche o pool de soquete
O cliente HTTP do Node.JS usará automaticamente os pools de soquete: por padrão, ele limitará apenas 5 soquetes por host. Embora a reutilização de soquetes possa causar o aumento dos recursos sob controle, se você precisar lidar com solicitações simultâneas do mesmo host, ele levará a uma série de gargalos. Nesse caso, é uma boa idéia aumentar o valor dos maxsockets ou fechar o pool de soquete:
// Desative o pool de soquete var http = requer ('http'); var options = {.....}; opções.agent = false; var req = http.request (opções)3. Não deixe recursos estáticos usarem node.js
Para recursos estáticos, como CSS e imagens, use servidor da web padrão em vez de node.js. Por exemplo, o LinkedIn Mobile usa o nginx. Também usamos redes de entrega de conteúdo (CDNs), que podem copiar recursos estáticos em todo o mundo para servidores. Isso tem dois benefícios: (1) pode reduzir a carga em nosso servidor node.js (2) CDNs pode permitir que o conteúdo estático seja entregue nos servidores mais próximos do usuário, reduzindo assim o tempo de espera.
4. Renderizar no cliente
Vamos comparar rapidamente a diferença entre a renderização do servidor e a renderização do cliente. Se usarmos o Node.js para renderizar no lado do servidor, para cada solicitação, enviaremos de volta uma página HTML como a seguinte:
<!-Um exemplo de uma página simples da web renderizada totalmente do lado do servidor-> <! </div> </body> </html>
Preste atenção em observar todo o conteúdo desta página, exceto o nome do usuário, o restante é estático: o conteúdo sobrecarregado por cada usuário e a página são os mesmos. Portanto, uma abordagem mais eficaz é deixar o Node.js retornar apenas o conteúdo dinâmico exigido pela página no formulário JSON.
{"Nome": "John"}
O restante da página - todas as tags HTML estáticas - pode ser colocado em modelos de JavaScript (como o modelo subscore.js):
<!-Um exemplo de um modelo de JavaScript que pode ser renderizado no lado do cliente-> <! %>! </div> </body> </html>
A melhoria do desempenho vem desses lugares: como diz o terceiro ponto, os modelos de JavaScript estático podem ser fornecidos no lado do servidor através do servidor da web (como o NGINX) ou implementados com melhores CDNs. Além disso, os modelos de JavaScript podem ser armazenados em cache no navegador ou armazenados localmente. Depois que todas as páginas iniciais são carregadas, os únicos dados que precisam ser enviados ao cliente são o JSON, que será o mais eficaz. Este método pode reduzir bastante a carga de CPU, IO e Node.JS.
5. Use Gzip
Muitos servidores e clientes oferecem suporte ao GZIP para compactar solicitações e respostas. Se você está respondendo a um cliente ou enviando uma solicitação para um servidor remoto, certifique -se de fazer o uso total.
6. paralelização
Tente deixar todas as suas operações de bloqueio - envie solicitações, chamadas de banco de dados e paralelização de acesso ao sistema de arquivos a serviços remotos. Isso reduzirá o tempo de espera pela operação de bloqueio mais lenta, em vez do tempo de espera de todas as operações de bloqueio. Para manter os retornos de chamada e o manuseio de erros limpos, usamos a etapa para controlar o tráfego.
7. Liberalização da sessão
O LinkedIn Mobile usa a estrutura expressa para gerenciar ciclos de solicitação/resposta. Muitos exemplos expressos incluem a seguinte configuração:
App.use (Express.Session ({Secret: "Keyboard Cat"}));
Por padrão, os dados da sessão são armazenados na memória, o que adiciona enorme sobrecarga ao servidor, especialmente quando o número de usuários aumenta. Você pode usar um armazenamento de sessões externas, como MongoDB ou Redis, mas cada solicitação resultará na sobrecarga de chamadas remotas para obter dados da sessão. Quando possível, a melhor opção é armazenar todos os dados sem estado no lado do servidor. Ao liberalizar a sessão ao não incluir a configuração expressa acima, você verá melhor desempenho.
8. Use módulos binários
Se possível, substitua os módulos JavaScript por módulos binários. Por exemplo, quando convertemos de um módulo SHA escrito em JavaScript em uma versão compilada do Node.js, vemos um grande salto adiante no desempenho:
// Use incorporado ou modulesvar binário Crypto = requer ('cripto'); var hash = cripto.createhmac ("sha1", chave) .Update (SignatureBase) .Digest ("base64");9. Substitua a biblioteca de clientes por JavaScript padrão V8
Muitas bibliotecas JavaScript são criadas para uso em navegadores da Web porque, em ambientes JavaScript, por exemplo, alguns navegadores suportam funções como foreach, mapear e reduzir, mas alguns navegadores não. Portanto, as bibliotecas de clientes geralmente usam muito código ineficiente para superar as diferenças do navegador. Por outro lado, no Node.js, você pode saber exatamente quais métodos JavaScript são eficazes: o mecanismo V8 JavaScript suporta o Node.js para implementar o ECMAScript especificado na quinta edição do ECMA-262. Substitua diretamente a biblioteca do cliente pelas funções JavaScript padrão V8, você encontrará melhorias significativas de desempenho.
10. Mantenha seu código pequeno e leve
O uso de um dispositivo móvel tornará o acesso lento e a latência alta, o que nos diz para manter nosso código pequeno e leve. A mesma filosofia é mantida para o código do servidor. Ocasionalmente, olhe para a sua decisão e faça perguntas como: "Nós realmente precisamos deste módulo?", "Por que usamos essa estrutura? Sua sobrecarga vale a pena usar?", "Podemos implementá -la de uma maneira simples?". O código pequeno e leve é geralmente mais eficiente e rápido.
Experimente
Trabalhamos duro para tornar nossos aplicativos móveis rapidamente. Experimente em plataformas como aplicativos para iPhone, aplicativos Android e versões móveis HTML5 para nos informar como estamos indo.