Mise à l'échelle d'une application Node.js à 10s de 1000 connexions simultanées

Nous avons travaillé sur une application qui permet aux gens de tirer des balles de baseball sur Internet.

Il vit entièrement dans l'écosystème AWS d'Amazon, et nous construisons cela pour un nouveau projet. La pile comprend:

-Les serveurs dédiés MongoDB et Redis – trois groupes différents de serveurs nodejs – en plus, nous utilisons l'API d'Amazon pour la configuration du serveur et la mise à niveau automatique

Le problème auquel nous sommes confrontés est que nous n'avons pas pu simuler plus d'environ 15000 utilisateurs simultanés (connexions websocket) par instance. Nous devrions avoir beaucoup plus; Nous pensons que 10s de milliers. L'utilisation du processeur du serveur n'est que de 40%.

Toute réflexion sur la façon d'étendre une application node.js pour lui permettre d'avoir beaucoup plus de connexions simultanées à un seul serveur?

Chaque connexion tcp a un descripteur de fichier ouvert dans le système d'exploitation du fichier. Il est important de définir la limite à un nombre supérieur à ce dont vous avez besoin.

Par exemple, dans ubuntu, vous pouvez voir cette limite par des commandes:

$ulimit -a $ulimit -n 

Pour définir définitivement cette limite dans Ubuntu, vous devez modifier le fichier /etc/security/limits.conf et ajouter ces lignes avec le numéro souhaité:

 * soft nofile 100000 * hard nofile 100000 

Ensuite, redémarrez:

 $sudo reboot 

Une connexion Web est une connexion TCP, non? Et combien de temps vos clients conservent-ils vos connexions ouvertes?

Un serveur aura une limite sur le nombre de connexions TCP ouvertes que vous pouvez avoir. Votre système d'exploitation aura également une limite sur le nombre de poches de fichiers ouverts qu'une procédure peut avoir à tout moment.

Alors:

  • Quelle est la limite de socket Open TCP sur votre serveur, et
  • Quelle est la limite de gestion des fichiers ouverts sur votre serveur

?

Je suppose que vous commencez à toucher certaines des limites par défaut du noyau sur les descripteurs de pile / fichier tcp. Avez-vous déjà essayé des optimisations au niveau du système? Si oui, lequel?

  1. Redis s'exécute-t-il répliqué? Le problème peut être avec Redis – il est simple à thread. Quote from their docs: Redis utilise une conception à la fois unique. Cela signifie qu'un seul processus sert toutes les demandes des clients, en utilisant une technique appelée multiplexage. Cela signifie que Redis peut répondre à une requête unique à chaque instant donné, de sorte que toutes les demandes sont diffusées séquentiellement . Ainsi, les processus peuvent être dans la file d'attente de Redis en attente de leur tour

  2. Les serrures sont-elles utilisées au côté du mongodb? J'ai observé ce genre de problèmes de performance avec le code à l'aide des verrous mysql: les processus attendent le verrouillage.