Улучшит ли задержка обработка каждого TCP-соединения в отдельном потоке?

У меня есть FTP-сервер, реализованный поверх QTcpServer и QTcpSocket.

Я использую преимущества механизма сигналов и слотов для одновременной поддержки нескольких TCP-соединений, даже если у меня есть один поток. Мой код как можно скорее возвращается в цикл событий, он не блокируется (нет функций ожидания) и нигде не использует вложенные циклы событий. Таким образом, у меня уже есть совместная многозадачность, как в приложениях Win3.1.

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

С одной стороны, потоки увеличивают задержку, потому что вам нужно запускать новый поток для каждого нового соединения, но, с другой стороны, с моей совместной многозадачностью, другие соединения TCP должны ждать, пока я не вернусь в основной цикл, прежде чем их readyRead()/ bytesWritten() сигналы могут быть обработаны.


multithreading qt latency qtcpsocket
person sashoalm    schedule 26.02.2013    source источник
comment
Увеличить задержку? Нет. Улучшить отзывчивость? Только если вы блокируете чтение; а ввод-вывод сокета блокирует ваш пользовательский интерфейс. Кажется, это не тот случай.   -  person paulsm4    schedule 26.02.2013

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Теперь, однако, учтите, что в вашей системе, вероятно, доступно более одного процессора и что время ввода-вывода и время обработки могут перекрываться.

Чтобы в полной мере воспользоваться преимуществами многопроцессорной (ядерной) системы, вам потребуется параллелизм.

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

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

Если вы решите пойти по маршруту MT, я бы посоветовал вам подумать о зависимости от библиотеки ввода-вывода с поддержкой потоков. QT может предоставить это для вас (я не уверен). Если нет, взгляните на boost:: asio (или ACE для более старого, но все еще надежного решения). Вы обнаружите, что использование возможностей машинного перевода такой библиотеки требует значительных затрат времени на обучение; однако, как оказалось, время добавить многопоточность «вручную» и сделать это правильно еще хуже.

Поэтому я бы сказал, что оставайтесь с вашим существующим решением, если вы не беспокоитесь о неиспользуемых циклах процессора и/или джиттере, и в этом случае начните изучать поддержку многопоточности QT или boost::asio.

person Dale Wilson    schedule 26.02.2013

arrow_upward
1
arrow_downward

Вам нужно начинать новый поток для каждого нового соединения? Не могли бы вы просто иметь пул потоков, который действует на запросы по мере их поступления. Это должно уменьшить задержку. Я должен сказать, что в целом многопоточный FTP-сервер должен быть более отзывчивым, чем однопоточный. Возможно ли иметь FTP-сервер на основе событий?

person Cake or Death    schedule 26.02.2013