J'utilise un modèle epoll au bas de la communication. Ensuite, lorsque epoll traite la demande, il la transmet à un pool de threads pour traitement. Les threads du pool de threads appellent le service de couche supérieure. implique une communication réseau, elle est donc traitée grossièrement. Une requête prend moins de 10 ms
Un tel modèle provoquera-t-il une forte augmentation du processeur lorsque le trafic augmente ?
Contexte : Mon utilisation du processeur est d'environ 75 % (trafic : 20~22 Mbps) ; lorsque le trafic augmente à 25 Mbps, le processeur est directement plein. . Ce n'est pas tout à fait comme prévu, car l'augmentation du trafic est inférieure à 15 %, mais le processeur augmente de 25 %.
Laissez-moi vous expliquer brièvement mon point de vue, juste à titre de référence :
1 : Déterminez d'abord si votre demande est gourmande en E/S ou en CPU ? L'E/S intensive dont je parle fait référence aux E/S réseau qui nécessitent une lecture et une écriture pour envoyer et recevoir des messages, c'est-à-dire qu'une communication gourmande en CPU, par exemple, nécessite des calculs pour produire des résultats, et cela prend beaucoup de temps.
2 : S'il s'agit du premier type d'E/S gourmand en E/S, alors je ne pense pas que vous ayez besoin de transmettre toutes les requêtes au pool de threads pour traitement. S'il n'y a pas d'opérations d'E/S disque fastidieuses telles que la lecture et l'écriture de fichiers, le pool de threads peut même ne pas être utilisé. De cette manière, le modèle Une boucle par thread est sans aucun doute le plus efficace. Pour parler franchement, toutes les lectures et écritures (lecture et écriture des données réseau, pas lecture des fichiers) et les événements planifiés sont effectués dans un seul EPOLL.
3 : Si cela nécessite beaucoup de CPU, il n'y a aucun problème avec l'utilisation de thread_pool. Cela dépend du nombre de threads et du code que vous configurez.
Il est difficile de répondre à cette question sans l'environnement réel. J'essaie juste de dégager quelques idées et de signaler d'éventuelles erreurs.