Ne parlez que de la situation d'un serveur.
Le nombre de concurrence fait référence au nombre de requêtes arrivant en même temps, ce qui est du point de vue du client ; la capacité de traitement simultané du serveur fait référence au nombre de requêtes que le serveur peut gérer en même temps (sans changement de processus). concurrence La puissance de traitement est égale au nombre de cœurs du CPU.
D'après ce qui a été dit ci-dessus, s'il y a 8 cœurs et que les tâches demandées sont de pures tâches informatiques sans E/S, alors chaque cœur peut évidemment traiter plus d'une requête par seconde. Supposons qu'il puisse en gérer 10 000 (tâches informatiques simples) par seconde. . Si ce nombre est tout à fait possible), alors ce serveur peut traiter 80 000 requêtes par seconde.
Ajoutez maintenant io, si le CPU doit attendre pendant les IO et ne peut pas faire autre chose, alors évidemment le nombre de requêtes que le CPU peut gérer par seconde sera considérablement réduit, peut-être de 10 000 à des centaines, voire des dizaines ou plusieurs.
Ensuite, vous pouvez ajouter divers facteurs tels que la commutation de processus et l'efficacité des algorithmes. Après avoir ajouté ces facteurs un par un, vous pouvez obtenir un serveur complexe mais réel.

Il ne s'agit pas du même concept, mais ils sont liés :
Supposons que le temps de réponse moyen soit t (l'unité est la milliseconde), que la simultanéité soit c et que le nombre de requêtes traitées par seconde soit q, alors :
q = (1000/t) * c
C'est la relation ;
Pensez Pour augmenter q, il n'y a que deux façons : 1) Réduire t 2) Augmenter c
Pour '1', cela ne peut être obtenu qu'en optimisant le code. Vous ne pouvez que faire de votre mieux, et l'amélioration est. souvent limité ;
Pour '2', généralement c Cela est lié au modèle de traitement des requêtes de votre programme serveur. Si votre programme serveur est dans le mode "un thread correspond à une requête", alors la valeur maximale de c est limitée. par combien de threads vous pouvez prendre en charge ; s'il s'agit du mode « un processus correspond à une demande », alors la valeur maximale de c est soumise au nombre maximum de processus

Dans le processus d'augmentation de c, une chose à noter est que plus il y a de threads/processus, plus le changement de contexte et la surcharge de planification des threads/processus augmenteront de manière significative et indirecte la valeur de t et empêcheront q. . Comme la valeur de c augmente proportionnellement, augmenter aveuglément c ne produira généralement pas de bons résultats. La valeur la plus appropriée de c doit être obtenue sur la base d'expériences expérimentales

De plus, il existe une situation particulière : si l'entreprise détermine que le service fourni par le serveur présente les caractéristiques d'un « petit volume de données et d'un long temps de retour », c'est-à-dire qu'il s'agit d'un type d'entreprise qui n'est pas occupé mais très lent. , alors NIO peut être utilisé. Le mode fournit des services, par exemple, nginx utilise le mode nio par défaut
Dans ce mode, la valeur c n'est plus liée au nombre de threads/processus, mais uniquement au "nombre de connexions socket" ; . Habituellement, le « nombre de connexions socket » peut être très important. Sur un serveur Linux spécialement configuré, des millions de connexions socket peuvent être prises en charge en même temps. Dans ce cas, c peut atteindre 1 million
Sous une valeur c aussi élevée. , quelle que soit la taille de t, il peut toujours prendre en charge un q très élevé. En même temps, le nombre de threads/processus réels ne peut être ouvert que pour être cohérent avec le nombre de cœurs de processeur afin de maximiser l'utilisation du processeur
; Bien sûr, le principe de tout cela est que l'entreprise a "un petit volume de données et un long temps de retour" "Caractéristiques

Nous supposons que votre site Web est un site statique et que toutes les demandes passent par nginx. Vous devez ensuite confirmer que la communication réseau entre la machine de test et le serveur est fluide. Les outils comme ab ne sont pas très convaincants pour les tests de stress. Nous recommandons jmeter ou loadrunner. Lors du stress test, il est nécessaire de s'assurer que la courbe du temps de réponse du test est stable pendant un certain temps avant qu'elle ne soit considérée comme la performance réelle du serveur testé. Cela est dû à un certain temps de préchauffage. est requis au début du test. Généralement, la courbe se stabilise après un certain temps, puis juge le temps de réponse actuel.

Requêtes par seconde = nombre total de requêtes complétées sur une période de temps/heure

Le montant de la concurrence est le nombre de connexions actuellement maintenues. Affichez toutes les connexions via netstat -net.

Par exemple :

netstat -ntp |grep -i "80" | wc -l