Java netty ne peut prendre X nombre de demandes par seconde? Avec l'approche du sélecteur est-il vrai que cela peut être un goulot d'étranglement en termes de service de requête par seconde? Nous constatons que lorsque le trafic est élevé, les clients sont incapables de se connecter, ce qui entraîne un délai d'attente.Java netty ne peut prendre X nombre de demandes par seconde?
Ceci n'est probablement pas dû au fait que le sélecteur soit un goulot d'étranglement, mais soit parce que TCP a trop peu de ephemeral ports sur les clients ou parce que le serveur a frappé the file descriptor limit.
Il est de plus en plus répandu que vous ne devriez pas utiliser les sélecteurs, seulement des centaines de milliers de threads. Les sélecteurs déplacent le processus de planification dans l'application, où il est probable que cela n'appartient pas. En outre, ils ont été conçus lorsque l'alternative était un processus par client. Un thread par client est des ordres de grandeur moins cher.
Je sais que c'est vieux, mais les modèles de TPC ne tombent-ils pas? J'ai lu presque partout que l'utilisation de TPC pour les applications de réseau à grande échelle est une mauvaise idée, c'est pourquoi la plupart des gens suggèrent de s'éloigner d'OIO. – Hobbyist
Ce n'est pas le client, chaque client ne fait qu'une connexion. Ce n'est pas le descripteur de fichier parce que je suis capable de me connecter à ce serveur sur un autre port sans temps mort. – erotsppa
Pourquoi est-ce la bonne réponse quand il dit clairement que ce n'était pas le problème? Quelqu'un m'aide ici. – Hobbyist