Используя Boost :: Beast для API-интерфейсов REST с высокой нагрузкой на процессор, следует ли использовать Async или Sync, чтобы реализовать их, чтобы ожидать большую задержку? - PullRequest
0 голосов
/ 27 февраля 2019

Я пытаюсь использовать boost::beast для реализации веб-службы, предоставляющей некоторые REST API.Эти API-интерфейсы сильно загружены процессором, почти не имеют дискового ввода-вывода.Моя цель - оптимизировать время ожидания с нормальной пропускной способностью.Должен ли я использовать синхронизацию или асинхронный способ их реализации?

Спасибо!

Ответы [ 3 ]

0 голосов
/ 27 февраля 2019

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

Причина этого проста: обычно плохая идея блокировать цикл обработки событий дляболее длительные периоды времени - как это происходит при использовании асинхронной модели для вычислений с большой нагрузкой на процессор.

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

0 голосов
/ 28 февраля 2019

Если вы хотите тайм-ауты, у вас нет другого выбора, кроме как использовать асинхронные API, предоставляемые Boost.Beast / Boost.Asio / Asio / Networking TS.

0 голосов
/ 27 февраля 2019

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

Полагаю, вам следует конкретным образом оценить, что вы подразумеваете под "ОК пропускной способностью", а затем сравнить ее в своей системе.

...