Батчинг входящих запросов с неблокирующим ожиданием?

Да, Channel сработали хорошо. Удалось повысить производительность в два раза, уменьшив при этом загрузку БД.

Батчинг входящих запросов с неблокирующим ожиданием?

Спасибо за развернутый ответ. Извиняюсь за транслитерации.

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

Я составил диаграмму последовательности, отражающую концепцию "агрегации" входящих запросов с неблокирующим ожиданием в реализации на TaskCompletionSource.
OurService_T1 и OurService_T2 — это поток 1 и поток 2 сервиса соответственно.
Первая часть диаграммы показывает, как обычно происходит взаимодействие. Вторая часть диаграммы показывает предполагаемую оптимизацию при большом количестве запросов в короткий промежуток времени.



Реализация, показанная на второй части диаграммы, увеличивает задержку (latency). Очевидно, что такая оптимизация не будет работать, если количество запросов маленькое. Но когда запросов становится очень много, задержка и так начинает повышаться из-за повышенной нагрузки.

Мой вопрос состоит в том, стоит ли игра свеч. Есть ли готовые решения для описанной ситуации (много сервисов отправляют мелкие запросы и должны дождаться ответа)? Мы жертвуем задержкой в угоду большего количества обрабатываемых запросов.

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

PS Спасибо за наводку на WaitAny .