У меня возникли проблемы с управлением работой .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, чтобы сетевой адаптер справился с этим?
Мой вопрос (ы), скорее всего, плохо информирован, поскольку я не эксперт в сетевом программировании, и я знаю, что это сложная проблема, я был бы признателен, если бы кто-то оставил мне указатели, чтобы посмотреть, прежде чем закрывать вопрос или создавать его " мертвых".
Спасибо.