Nginx/node.js/postgres est-il une architecture très évolutive?

Question

je une application en cours d'exécution avec:

• une instance de nginx comme interface (servant fichier statique)
• un cluster d'application Node.js pour l'arrière-plan (en utilisant cluster et express.js modules)
• une instance de Postgres comme la DB

est cette architecture suffisante si l'application a besoin d'évolutivité (ce qui est uniquement pour les requêtes HTTP/REST) ​​pour:

• 500 demandes par seconde (chaque requête ne récupère que les données de la base de données, ces données peuvent être de plusieurs ko, et sans grand calcul après l'extraction).

• 20000 utilisateurs connectés en même temps

Où pourraient être les goulots d'étranglement?

Answer 1

Pour la charge spécifiée (500 demandes simples/seconde), je n'aurais pas pensé que ce serait trop un problème. Et je suppose qu'un cluster d'instances de nœuds ne sera même pas nécessaire. Toutefois, comme vous n'avez qu'une seule instance, il est fort probable que ce soit votre goulot d'étranglement en ce qui concerne la mise à l'échelle. Vous avez également le problème supplémentaire que ce serait votre point de défaillance unique (je ne suis pas familier avec Postgres, ici travaillait avec un cluster Oracle et dataguard qui signifie que nous avons un cluster de base de données de sauvegarde pour atténuer cela) .

Si vous n'avez pas besoin d'un modèle de données relationnel, alors MongoDB peut être un choix plus évolutif.

Une autre chose à garder à l'esprit est votre infrastructure réseau. Si vous allez ajouter des clusters/noeuds, assurez-vous que le réseau peut gérer la charge distribuée.

Une dernière chose: Généralement, il est impossible de déterminer si une application sur une architecture peut gérer une charge particulière sans test de performance/volume/stress, donc la réponse est un «peut-être» retentissant.

Answer 2

Vous devriez être OK à 500 ops/sec. Redesign si vous prévoyez d'entrer dans les mille ops/sec.

Sans connaître beaucoup plus de données de votre part, les E/S disque seront votre goulot d'étranglement le plus probable. Cela se produira dans votre base de données PostgreSQL à environ 10 000 ops/sec si vous utilisez le disque dur sur du matériel en stock et que vous ralentirez également si vous faites une commande JOIN sur la commande SQL. Cela ralentira également le nombre d'utilisateurs simultanés que vous tentez d'accéder à un seul lecteur. Votre temps de recherche de lecteur va flipper, car vous aurez constamment accès au lecteur.

Vous devriez rechercher la structure de vos données et si une base de données relationnelle est nécessaire (devez-vous faire un JOIN?). Une solution noSQL pourrait être la solution. Essayez toujours d'obtenir les E/S de votre disque aussi distribuées et séquentielles que possible.