Зачем нужен асинхронный ввод-вывод при чтении сокетов для не HTTP-сервера

Вы на правильном пути. Разумно спросить «почему», особенно со всей шумихой вокруг асинхронности и управления событиями. Есть приложения кроме веба. Подумайте об очередях сообщений и финансовых транзакциях, таких как высокочастотная торговля. По сути, любой случай, когда ожидание стоит денег или теряется возможность обслужить клиента, является кандидатом на асинхронность. Веб — большой пример, потому что сеть намного быстрее, чем база данных. Как всегда, спросите «имеет ли это смысл» для вашего приложения. Асинхронность добавляет много сложности, если вы не получаете от этого пользы.

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

Надеюсь, это поможет.

Использование шаблона блокировки вызовов повлечет за собой:

1. Listening on a socket vector of size N
2. When a message arrives, you wake up with a start in time K, find and start processing the message, employing a time T (it does not matter if the processing is offloaded to another thread: in this case T becomes your offloading time)
3. You finish examining the vector and GOTO 1

Таким образом, вы можете сказать, что если прибывает M сообщений, а другое сообщение поступает в течение времени отправки K+M*T, то M+1-е сообщение будет ожидать K+M*T времени. Приемлемо ли это для ваших ожидаемых значений K (постоянная), M (функция трафика) и T (функция ресурсов и загрузки системы)?

Асинхронной обработки на самом деле не существует. Всегда будет где-то "синхронный" цикл ввода-вывода, только он будет настолько хорошо интегрирован в ядро ​​(или даже аппаратное обеспечение), что будет работать в 10-100 раз быстрее, чем ваш собственный, и, следовательно, будет вероятно, будет лучше масштабироваться при больших значениях M. Задержка по-прежнему имеет форму K1+M*T1, но на этот раз K1 и T1 намного меньше. Или, может быть, K1 немного выше, а T1 значительно ниже: архитектура «лучше масштабируется» при больших значениях M.

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

Примите во внимание еще один фактор: если количество сообщений становится действительно большим, асинхронность имеет свои преимущества; но если сами сообщения независимы (изменения, вызванные сообщением A, не влияют на обработку сообщения B), то вы можете оставаться синхронными и масштабироваться по горизонтали, подготавливая количество Z «концентраторов сообщений», каждый из которых получает долю M/Z от общий трафик.

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