Combien de connexions simultanées Workerman prend-il en charge ?

Le concept de concurrence est trop flou. Ici, nous l'illustrerons à l'aide de deux indicateurs quantifiables : le nombre de connexions simultanées et le nombre de requêtes simultanées.

Le nombre de connexions simultanées désigne le nombre total de connexions TCP maintenues par le serveur à un moment donné, sans se soucier de savoir si des données y circulent ou non. Par exemple, un serveur de notification peut maintenir des millions de connexions d'appareils, et comme il y a rarement des communications de données sur ces connexions, le chargement du serveur peut être presque nul. Tant que la mémoire est suffisante, le serveur peut continuer à accepter des connexions.

Le nombre de requêtes simultanées est généralement mesuré en QPS (requêtes par seconde que le serveur peut traiter), sans se soucier du nombre de connexions TCP existantes sur le serveur à un moment donné. Par exemple, si un serveur n'a que 10 connexions clients et que chaque connexion client génère 10 000 requêtes par seconde, le serveur doit être capable de supporter au moins 10 * 10 000 = 100 000 requêtes par seconde (QPS). Supposons que 100 000 requêtes par seconde soit la limite pour ce serveur, si chaque client envoie une requête par seconde, ce serveur peut prendre en charge 100 000 clients.

Le nombre de connexions simultanées est limité par la mémoire du serveur. Un serveur Workerman avec 24 Go de mémoire peut généralement supporter environ 1,2 million de connexions simultanées.

Le nombre de requêtes simultanées est limité par la capacité de traitement du CPU du serveur. Un serveur Workerman de 24 cœurs peut atteindre un débit de 450 000 requêtes par seconde (QPS), la valeur réelle variant en fonction de la complexité des affaires et de la qualité du code.

Remarque

Pour des scénarios de haute concurrence, il est impératif d'installer l'extension event, voir le chapitre sur l'installation et la configuration. De plus, il est nécessaire d'optimiser le noyau Linux, en particulier la limite d'ouverture des fichiers pour les processus. Veuillez consulter le chapitre sur l'optimisation du noyau en annexe.

Données de test de charge

Les données proviennent d'un organisme de test de charge tiers de confiance techempower.com, lors de la 20e série de tests
https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zik073-sf

Configuration du serveur :
Total de cœurs 14, Total de threads 28, 32 Go de mémoire, Switch Ethernet Cisco 10 gigabits dédié
Logique commerciale :
Business avec requêtes de base de données, base de données pgsql, php8+jit
QPS de plus de 390 000