Как ограничить память Boost.Asio

У меня возникли проблемы с управлением работой .post() для io_context Boost.Asio, и у меня есть несколько вопросов по этому поводу (предупреждение для новичков).

Предыстория: я пишу библиотеку, которая подключается к большому количеству разных хостов на короткие периоды времени каждый раз (подключение, отправка данных, получение ответа, закрытие), и я решил использовать Boost.Asio . Документация скудная (слишком СУХАЯ?)
Мой текущий подход таков: (при условии, что машина четырехъядерная): два физических ядра выполняют операции синхронизации, привязанные к ЦП, и post() дополнительных рабочих элементов к io_context. Два других потока .run()ing и выполняют обработчики завершения.

1 – Планировщик работы
Согласно этому удивительному ответу,

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

Что делает boost.asio? На каком основании позже обрабатывается поставленная в очередь работа?

2 — несколько производителей/несколько потребителей

Согласно этой статье,

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

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

3- Действительно ли необходимы пряди? Как их «отключить»
Как подробно описано в этом ответе, boost использует неявную цепочку на связь. Делая потенциально миллионы соединений, экономия памяти за счет «обхода» нитей имеет для меня смысл. Поскольку запросы, которые я делаю, независимы (разные хосты для каждого запроса), операции, которые я делаю в рамках одного соединения, уже сериализованы (цепочка обратных вызовов), поэтому у меня нет перекрывающихся операций чтения и записи, и от Boost.Asio не ожидается синхронизации. Есть ли смысл пытаться обойти пряди? Если да, то как?

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

  • Скомпилировано asio с помощью BoringSSL (OpenSSL — серьезное узкое место)
  • Написал свой собственный сервис резолвера c-ares, чтобы избежать асинхронных DNS-запросов, выполняющихся в цикле потоков.

Но все же случается, что мой сетевой драйвер начинает отключаться при открытии нескольких подключений. Так как же динамически настроить пропускную способность boost.asio, чтобы сетевой адаптер справился с этим?

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

Спасибо.


person Wahib Mkadmi    schedule 05.05.2020    source источник
comment
Отличный вопрос, хорошо изученный. Одно немедленное исправление: boost использует неявную цепочку для каждого соединения, это просто неправильно. Если вы используете однопоточность, существует неявная (глобальная) цепочка. Вы получаете подразумеваемую цепочку (следовательно, без фактической пряди), если ваши обработчики цепляются строго последовательно (например, полудуплексная цепочка записи). Более того, в последних версиях Asio вы можете укажите подсказку о параллелизме), если вы хотите оптимизировать внутренние накладные расходы.   -  person sehe    schedule 05.05.2020
comment
Затем это отвечает на мой третий вопрос, поскольку фактической нити нет. Спасибо!   -  person Wahib Mkadmi    schedule 05.05.2020