Архитектура соединителя Tomcat, пулы потоков и асинхронные сервлеты

Я хотел бы понять модель резьбы Tomcat для разъемов BIO и NIO. Я ссылаюсь на официальный Tomcat 7 documentaion для разъемов, которые можно найти здесь. Исходя из этого, это то, в чем я сомневаюсь:

  • acceptorThread(s) : это один или не более 2 потоков (как указано в документе), который отвечает только за принятие предстоящих соединений. Это можно настроить с помощью acceptorThreadCount, и предполагается, что для многопроцессорной машины можно использовать более двух -
    • почему это ?
    • означает ли это, что количество одновременных открытых соединений масштабируется с количеством процессоров по сравнению с количеством открытых файловых дескрипторов, разрешенных в серверной системе ?
  • maxConnections (s) :
    • какова связь между этой настройкой и acceptCount и число открытых файловых дескрипторов в системе.
    • почему значение по умолчанию для этого намного выше для соединителя NIO (10000 ), чем для био ( = значение maxthreads равно ) ?
  • acceptCount: это очередь для запросов, когда все потоки обработки запросов заняты.
    • когда запросы помещаются в эту очередь, назначается ли ему также файловый дескриптор ? Или только когда запрос активно обрабатывается, он использует файловый дескриптор ?
  • потоки обработки запросов : количество потоков в пуле настраивается с помощью значение maxthreads равно и minSpareThreads атрибуты.
    • какова связь между этим пулом потоков и acceptorThreads ? Порождает ли поток(ы) акцептора потоки в этом пуле ?
    • Как Я поймите, модель NIO более эффективна с потоками обработки запросов, чем модель BIO. Как он достигает этой эффективности ?
    • как я читал в различных источниках, потоки в модели NIO следуют за поток на запрос парадигмы против поток на соединение парадигма биологической модели. Кроме того, в модели соединителя NIO фактическая обработка запросов делегируется другому потоку, отслеживаемому приложением, в то время как запрос сервера поток обработки возвращается в пул потоков-бесплатно, чтобы принять больше соединений. Итак, означает ли это, что преимущество модели NIO будет очевидным только в том случае, если соединения с сервером имеют HTTP Keep-Alive природа или если приложение использует сервлет 3.0функция асинхронной обработки ?
  • сервлет 3.0 :
    • при использовании сервлета 3.0, каким должен быть размер применение пула потоков сервлета (относительно размера пула потоков соединителя) для достижения оптимальной эффективности ?
    • при использовании модели BIO и этого вместе, будет ли какая-либо разница в том, как обрабатываются запросы ( учитывая, что потоки соединителя по-прежнему будут использовать поток на соединение модель ) ?

обратите внимание: все обсуждения в отношении tomcat 7.

22
java multithreading servlet-3.0 servlets tomcat

1 ответов

  • acceptorThread(s) : это один или не более 2 потоков (как упоминается в документе), который отвечает только за принятие ближайшие связи. Это можно настроить с помощью acceptorThreadCount, и предлагается использовать более двух для многопроцессорной машины -

    почему это ?

признавать соединения очень деятельность низкой цены поэтому она как раз не делает смысл посвятить этой задаче не один поток.

Does this imply that the number of simultaneous open connections 
scales with the number of cpus versus the number of open file descriptors 
allowed on the server system ?

нет, это не так, потому что это очень низкая стоимость операции с точки зрения процессора. Что касается файловых дескрипторов, каждое принятое соединение будет использовать файловый дескриптор, поэтому максимальное число соединений, которые сервер может принять, ограничено количеством доступных файловых дескрипторов.

  • maxConnections (s) :

    какова связь между этой настройкой и acceptCount и номером открытых файловых дескрипторов в системе.

maxConnections не может быть больше количества открытых файловых дескрипторов в системе. Имейте в виду, что другие процессы также используют файловые дескрипторы, поэтому, возможно, захотите быть консервативными с maxConnections в отношении доступных файловых дескрипторов, скажем maxConnections 

Why is the default value for this so much higher for the NIO connector 
( 10000 ) than for the BIO ( = maxThreads ) ?

Это потому что в NIO один обрабатывает все IO, а в BIO серверу нужно создать/использовать отдельный поток для каждого соединения.

  • acceptCount: это очередь для запросов, когда все потоки обработки запросов заняты.

    когда запросы помещаются в эту очередь, назначается ли ему также файловый дескриптор ?

Да, это правильно, запрос на подключение принимается, но сервер не тем не менее, готов к обслуживанию запросов, поэтому соединение помещается в очередь. Это делается для предотвращения тайм-аута TCP/stack запросов на подключение, которые могут выглядеть как сервер вниз с точки зрения клиента. Другими словами, сервер говорит: "Я здесь и обработаю ваш запрос, как только у меня будут ресурсы для этого".

или только когда запрос активно обрабатывается, он использует файловый дескриптор ?

Неа.

надеюсь, что это помогает.

С уважением,

Слава Imeshev

10