Renseignez-vous sur le fonctionnement de la jetée intégrée dans maven

Il s'agit d'un cas d'optimisation prématurée et de ne pas comprendre comment Jetty, ni votre propre application Web fonctionne réellement.

Conseil, ne configurez pas prématurément le QueuedThreadPool .

Laissez-le par défaut, testez et testez à nouveau, puis effectuez des tests de charge, puis recommencez les tests de charge, mais d'une manière différente. Rassemblez constamment des informations sur le comportement du QueuedThreadPool par défaut.

Ensuite, et alors seulement, vous devez régler QueuedThreadPool en fonction de vos besoins.

Mais n'arrêtez jamais de surveiller votre serveur et votre application Web, car vous ajusterez souvent votre configuration. (en particulier si vous configurez le QueuedThreadPool pour qu'il soit plus petit que la valeur par défaut)

Important: Si vous devez limiter le nombre de requêtes ou de connexions, ou contrôler le nombre ou le taux de requêtes ou de connexions, tenter de le faire au niveau de ThreadPool ne fonctionnera jamais.

Ce diagramme est erroné (ou au moins 10 ans désuet).

Depuis Jetty 7, il n'y a pas de file d'attente de connexion, il n'y a pas de séparation des threads Accepteurs et Request.

Le pool de threads (qui n'est en réalité qu'un java.util.concurrent.Executor ) est utilisé pour TOUTES les demandes de thread sur le serveur Jetty. Cela peut être l'acceptation d'une connexion, la gestion du sélecteur géré par nio, le traitement des sélecteurs nio individuels, le traitement des événements de lecture du réseau, le traitement de l'envoi initial d'une demande, le traitement des événements d'écriture de l'application Web vers le réseau, la gestion du traitement asynchrone de Servlet 3.0, QoSFilter, DoSFilter, gestion des E / S asynchrones depuis Servlet 3.1, connexions mises à niveau, websocket, gestion HttpSession, traitement de déploiement à chaud, analyse de bytecode, etc.

Avec une limite de 50 threads maximum:

• Vous n'aurez jamais besoin d'un autre accepteur.
• Vous affamerez les clients et causerez d'énormes problèmes.
• Une page Web typique chargée par un navigateur utilisera entre 8 et 12 connexions, ce qui signifie que sur cette configuration de 50 threads maximum, elle pourra traiter entre 4 et 6 clients simultanément.

Les types d'applications qui nécessitent un autre accepteur sont ceux qui gèrent d'énormes quantités de nouvelles connexions (pour Eclipse Jetty, vous avez généralement besoin d'un autre accepteur lorsque vous franchissez le seuil de 30 000 nouvelles connexions par seconde).

Le nombre d'accepteurs que Jetty utilise est configuré au niveau ServerConnector, pas au niveau ThreadPool.

Examinez les constructeurs ServerConnector et choisissez le constructeur le mieux adapté à votre environnement.

@Joakim Erdfelt, Merci beaucoup pour la réponse !!

Mon serveur vit dans des microservices de diagramme et non en tant que serveur Web, le nombre de connexions ne serait pas atteint à 30 000 qui pourraient être Google ^. ^.

Je veux juste que la séquence de tâches sorte du serveur Web dans le diagramme, car j'ai reçu TIMEOUT de réponse du serveur du partenaire si ce n'est pas la séquence de tâches.

Temps de réponse d'environ 10 secondes pour ne pas avoir de threads occupés fil min.

J'utilise:

int cntThread = server.getThreadPool().getThreads();
LOGGER.info("idleThread server : "+cntThread);

Je pense que le diagramme ci-dessus est au cœur de la jetée car je trouve toujours qu'il permet de le faire, mais j'ai diagramme avancé de la solution avec la configuration de mon serveur:

boolean checkOOM = threadPool.getThreadPoolBudget().check(StaticConfig.JETTY_MAX_THREADS);
LOGGER.info("check maxThread allow with memory : "+checkOOM);
if(!checkOOM) {
   LOGGER.info("please increase merory server or decrease maxThread.");
   System.exit(1);
}
//depend info system
//get core processor of server
int coreProcessor = Runtime.getRuntime().availableProcessors();
LOGGER.info("coreProcessor : "+coreProcessor);

Server server = new Server(threadPool);
int port = 0;

try {
   port = Integer.parseInt(System.getProperty("server.port"));
} catch (NumberFormatException ex) {
  LOGGER.error("Property server.port not found. " + ex.getMessage(), ex);
  System.exit(1);
}
// if acceptor 0 then the selector threads are used to accept connections
// selector backup for acceptor
// only init with limit system
try (ServerConnector httpConnector = new ServerConnector(server, coreProcessor, coreProcessor)) {
    httpConnector.setAcceptQueueSize(StaticConfig.JETTY_MAX_QUEUED);
    LOGGER.info("acceptors : "+httpConnector.getAcceptors());
    LOGGER.info("queueSize : "+httpConnector.getAcceptQueueSize());
    httpConnector.setPort(port);
    server.setConnectors(new Connector[]{httpConnector});
} catch (Exception e) {
    LOGGER.error(e.getMessage(), e);
    System.exit(1);
}
server.start();
server.join(); << init thread pool.

Au-dessus du code init avec la configuration autorisée dans le serveur en cours d'exécution, j'aurai des accepteurs de numéro coreProcessor et des sélecteurs de numéro coreProcessor pour les accepteurs. p >

J'ai utilisé ServerConnector similaire à votre suggestion.

J'essaye avec QueueThreadPool par défaut (le constructeur d'init Server n'entre pas le paramètre threadPool dans le code ci-dessus), je n'ai pas enregistré l'impression en tant que 4 threads init:

<jetty.version>9.4.30.v20200611</jetty.version>

I Je me demande juste que le rôle du pool de threads dans le diagramme fonctionne correctement!

ps: vous avez des informations sur le nouveau diagramme de la version actuelle de la jetée?

Merci beaucoup.

Cher @Joakim Erdfelt,

Je ne comprends pas pourquoi la mémoire est aussi pleine? parce que lorsque le thread est fermé lorsque HeapByteBuffer se réinitialise gratuitement !!

Et j'ai ouvert 8 accepteur et 8 sélecteur, quand la classe Serveur de package jetty je vois que le sélecteur de commentaires utilisera quand l'accepteur est plein, mais je surveille les threads que j'avais vu sélecteur utilisé, accepteur comme libre :(

Veuillez me suggérer, merci.