Les requêtes se concentrent sur certains processus

Phénomène

Parfois, en utilisant la commande php start.php status, nous pouvons observer que les requêtes sont traitées par certains processus spécifiques, tandis que les autres processus restent complètement inactifs.

Mécanisme de préemption

Dans Workerman, la manière dont plusieurs processus obtiennent des connexions est par défaut de type préemptif. Cela signifie que lorsque le client initie une connexion, tous les processus inactifs ont la possibilité de prendre cette connexion, celui qui est le plus rapide l'obtient en premier. Qui est le plus rapide est déterminé par la planification du noyau du système d'exploitation. Il se peut que le système d'exploitation privilégie le dernier processus utilisé pour obtenir le droit d'utilisation du CPU, car il peut encore exister des informations contextuelles du précédent processus dans les registres du CPU, ce qui peut réduire le coût de commutation de contexte. Ainsi, lorsque l'activité est suffisamment rapide ou lors de tests de charge, il est plus fréquent que les connexions soient concentrées sur certains processus, car cette stratégie peut éviter des commutations de processus fréquentes, optimisant souvent la performance, ce qui n'est pas un problème.

Mécanisme de répartition

Workerman peut changer la méthode d'acquisition des connexions en définissant $worker->reusePort = true; pour adopter une méthode de répartition. Avec cette méthode, le noyau distribue les connexions de manière à approximativement les répartir égalitairement entre tous les processus, de sorte que tous les processus traitent les requêtes ensemble.

Idées reçues

Beaucoup de développeurs pensent que plus il y a de processus participant au traitement des requêtes, meilleure est la performance, ce qui n'est pas nécessairement vrai. Lorsque l'application est suffisamment simple, le nombre de processus participant au traitement des requêtes doit être aussi proche que possible du nombre de cœurs du CPU pour maximiser le débit du serveur. Par exemple, sur un serveur à 4 cœurs, si le nombre de processus est fixé à 4, le QPS lors d'un test de charge avec "helloworld" est généralement le plus élevé. Si le nombre de processus participant dépasse trop le nombre de cœurs, le coût de commutation de contexte entre les processus augmente, ce qui dégrade la performance. En général, pour les applications utilisant une base de données, avoir un nombre de processus fixé entre 3 et 6 fois le nombre de cœurs peut améliorer la performance.