2016-02-17 4 views
1

под заголовком: Почему netty использует один и тот же поток для чтения и записи на каждый сокет?Почему netty использует один и тот же поток для чтения и записи на каждый сокет?

, когда netty write, netty преобразуется в одну задачу и использует тот же поток для чтения. почему бы не открыть другой поток, предназначенный для записи, чтобы производительность могла улучшиться?

the old one: read1->write1->read2->write2. //read 1 will wait write 1 time to read 2. 

the new one: thread A read1->read2 //no wait to go to read2 

       thread B write1->write2 

поэтому начальные бассейны три нитки:

один для принимать один для чтения один для записи

+1

В большинстве сетевых ситуаций между данными, считываемыми и записанными, есть некоторые * отношения *. То есть данные для записи зависят от того, что только что было прочитано. Нет никакой пользы для использования нескольких потоков, если они неоднократно должны встречаться для обмена информацией. –

+0

Почему вы ожидаете использовать два потока для повышения производительности? Я бы подумал, что это ухудшит работу, поскольку обычно вы не получите некоторые данные, а затем отправляете некоторые данные без контекстного переключателя, а контекстные переключатели имеют ненулевую стоимость. –

+0

@Damien_The_Unbeliever, потому что я думаю, что запись повлияет на следующее время чтения. – jiafu

ответ

4

Есть много причин.

Во-первых, операции чтения и записи в любом случае не делают никакого тяжелого подъема. Операция чтения только собирает данные, которые уже были обработаны, и операция записи просто отправляет данные, которые должны быть записаны, насколько это возможно. Таким образом, для дополнительной сложности нет большой производительности.

Во-вторых, типичный календ сервера или клиента чередует отправку и получение в любом случае. С потоком отправки и потоком приема эта каденция требует передачи данных из одного потока в другой, который имеет тенденцию быть неэффективным. Вы также нуждаетесь в очередях для адаптации между потоками и противодавлением для обработки заполнения очереди. Если вы продолжаете читать, когда пишете, куда вы помещаете эти данные? Вы просто сохраняете его в памяти?

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

Наконец, если вы используете протокол TLS, ваша логика отправки и получения будет иметь взаимозависимости. Так что ваши потоки просто будут ждать друг друга в любом случае.

+0

В действительности, я должен использовать один пул потоков приложений для его поддержки. поэтому мне нужен два контекстных переключателя потока: io read thread-> my thread pool; мой пул потоков -> io написать нить. поэтому я думаю, что это не импорт, если поток чтения io такой же, как и поток записи. WDYT? – jiafu

+0

Я думаю, вы все еще неправы. Рассмотрим запись, за которой следует чтение. С двумя потоками это приложение, чтобы писать поток, чтобы читать поток в приложении. С одним потоком это приложение для чтения/записи потока обратно в приложение. Вам все еще нужен контекстный переключатель, чтобы перейти от записи к чтению. И у вас все еще есть ваш поток для чтения и напишите ответ на вопрос о подключении. –

+0

jiafu описывает серверное приложение, тогда как Дэвид Шварц описывает клиентское приложение. Они оба имеют смысл для меня в их собственном контексте. Интересно, существует ли такая ситуация, когда один поток слишком занят написанием и не может читать одновременно. –

Смежные вопросы