3 méthodes d'optimisation de code Node.js que vous ne connaissez pas_node.js

Les programmes Node.js peuvent s'exécuter très lentement en raison de limitations du processeur ou des opérations d'entrée et de sortie. Du point de vue du processeur, l'une des raisons typiques pour lesquelles un programme s'exécute lentement est un « chemin chaud » non optimisé (un morceau de code fréquemment consulté). Du point de vue des entrées et des sorties, la limitation de la vitesse d'exécution du programme peut être affectée par le système d'exploitation sous-jacent, ou elle peut être due à la défaillance de Node lui-même. Ou encore, un programme lent peut n'avoir rien à voir avec Node lui-même. Le problème réside dans les ressources externes, telles que les requêtes de base de données ou les appels d'API, qui sont lents et non optimisés.

Dans cet article, nous nous concentrerons sur l'identification et l'optimisation des opérations dans la base de code qui entraînent un fonctionnement lourd du processeur. Dans le même temps, les fichiers de configuration des applications de production seront explorés et les changements susceptibles d'améliorer l'efficacité opérationnelle seront analysés et apportés.

En raison de la nature monothread de Node, il est particulièrement important pour les serveurs d'éviter une charge CPU importante. Car le temps passé sur le CPU prend du temps pour répondre à d'autres requêtes. Si vous remarquez que votre application est lente à répondre et que le processeur est constamment élevé au cours de ce processus, l'analyse de votre application peut aider à identifier les goulots d'étranglement et à remettre votre application en marche rapidement.

Applications d'analyse
La réplication de programmes lents en production est difficile et prend du temps. Heureusement, vous n'avez pas besoin de le faire vous-même. Vous pouvez collecter des données de profil sur votre serveur de production et les analyser hors ligne. Jetons un coup d'œil à plusieurs méthodes d'analyse.

1. Utilisez les outils au niveau du noyau
Tout d'abord, vous pouvez utiliser des outils au niveau du noyau tels que DTrace (Solaris, BSD), perf (Linux) ou XPerf (Windows) pour collecter les traces de pile d'un processus en cours d'exécution, puis générer un graphique de flamme. L'analyse au niveau du noyau a un impact minimal sur les processus en cours d'exécution. Le graphique de flamme est un graphique vectoriel généré sur la base de la pile d'appels qui prend en charge le zoom avant et arrière. Yunong Xiao de Netflix a prononcé d'excellents discours et tweets sur les performances des systèmes Linux pour vous aider à approfondir votre compréhension de cette technologie. Si vous souhaitez maintenir un débit élevé dans une application de production, envisagez d'utiliser cette méthode.

2,

2. Utiliser l'analyseur V8
Une autre option consiste à utiliser directement le profileur V8. Cette approche partage le processus avec le programme et affecte donc les performances du programme. Pour cette raison, veuillez exécuter le profileur V8 uniquement pour capturer la sortie pertinente lorsque vous rencontrez de tels problèmes. L'avantage de cette approche est que vous pouvez utiliser tous les outils d'analyse de Chrome et leurs résultats (y compris les graphiques de flamme) pour étudier le programme.

Veuillez exécuter le code suivant pour tester votre programme :

npm install v8-profiler --save

Après cela, ajoutez le code suivant à votre programme :

const profiler = require('v8-profiler')
const fs = require('fs')
var profilerRunning = false
function toggleProfiling () {
 if (profilerRunning) {
  const profile = profiler.stopProfiling()
  console.log('stopped profiling')
  profile.export()
   .pipe(fs.createWriteStream('./myapp-'+Date.now()+'.cpuprofile'))
   .once('error', profiler.deleteAllProfiles)
   .once('finish', profiler.deleteAllProfiles)
  profilerRunning = false
  return
 }
 profiler.startProfiling()
 profilerRunning = true
 console.log('started profiling')
}
process.on('SIGUSR2', toggleProfiling)

Dès que vous envoyez le signal SIGUSR2 à ce processus, il commencera l'analyse. L'analyse peut être arrêtée en envoyant à nouveau un signal SIGUSR2 (code ci-dessous).

kill -SIGUSR2 [pid]

Les résultats de l'analyse de ce processus seront écrits dans le fichier dans le chemin de travail actuel (veuillez vous assurer que le chemin peut être écrit). Puisqu'il s'agit d'une interface programmable, vous pouvez la déclencher à volonté (à l'aide de points de terminaison Web, IPC, etc.). Si vous avez une idée du moment où votre programme deviendra lent, vous pouvez déclencher cette interface à tout moment. La configuration de déclencheurs automatiques est utile pour éviter une surveillance constante, mais elle nécessite que vous ayez une compréhension prédictive du moment et de la durée des captures.

Une fois les données de profil collectées, chargez-les dans Chrome Dev Tools et commencez à les analyser !

3. Utiliser le gestionnaire de processus
Bien que l'utilisation directe de l'analyseur V8 soit très efficace et personnalisable, il entrera dans votre base de code et ajoutera encore une autre dépendance à votre projet dont vous ne voudrez peut-être pas. Une alternative consiste à utiliser un gestionnaire de processus, qui peut envelopper votre programme avec divers outils lorsque vous avez besoin de l'analyser. Un outil facultatif est l'outil de ligne de commande SLC de StrongLoop.

Tout d'abord, exécutez npm install strongloop –g, puis exécutez le code suivant :

slc start [/path/to/app]

Le code ci-dessus lancera votre programme dans le gestionnaire de processus et vous pourrez extraire les données de profilage du processeur à la demande. Pour vérifier et obtenir l'identifiant de l'application, exécutez :

slc ctl

Vous obtiendrez des résultats similaires aux suivants :

Service ID: 1
Service Name: my-sluggish-app
Environment variables:
  Name   Value
  NODE_ENV production
Instances:
  Version Agent version Debugger version Cluster size Driver metadata
   5.0.1    2.0.2      1.0.0       1       N/A
Processes:
    ID   PID  WID Listening Ports Tracking objects? CPU profiling? Tracing? Debugging?
  1.1.61022 61022  0
  1.1.61023 61023  1   0.0.0.0:3000

L'identifiant du processus de l'application de localisation. Dans cet exemple, l'identifiant est 1.1.61023. Nous pouvons désormais lancer l'analyse à tout moment en exécutant le code suivant :

slc ctl cpu-start 1.1.61023

当我们觉得已经捕获到了迟滞行为，就可以运行以下代码来停止分析器：

slc ctl cpu-stop 1.1.61023

以下代码将写文件至硬盘：

CPU profile written to `node.1.1.61023.cpuprofile`, load into Chrome Dev Tools

好啦，就是这样。你可以像在 V8 分析器里那样把文件加载到 Chrome 里面进一步分析。

作出正确决定
在本文中，笔者展示了三种在 Node 中捕获生产环境下 CPU 使用量的方式。那么，你应该选用哪一种呢？下面是一些帮助你缩小决策范围的想法：

• 我需要分析很长一段时间：使用内核级工具。
• 我想用 Chrome 开发工具：使用 V8 分析器或者过程管理器。
• 我想捕获应用中的特定行为：使用 V8 分析器。
• 我不想影响到程序性能：使用内核级程序
• 我希望我不用挨个测试文件来获取程序分析信息：使用过程管理器

以上就是本文的全部内容，3种Node.js代码优化方式，希望大家可以熟练掌握。