digital-garden/dev/architecture/Блокирующий вызов.md
Struchkov Mark be8fd578f3
All checks were successful
continuous-integration/drone/push Build is passing
Обновление
2024-10-09 09:23:45 +03:00

4.8 KiB
Raw Blame History

aliases tags date zero-link parents linked
блокирующие операции
блокирующая операция
блокирующий вызов
блокирующий ввод-вывод
блокирующего
блокирующей операции
блокирующих операций
maturity/🌱
2024-01-28
../../meta/zero/00 Архитектура ПО
Блокирующий вызов

Блокирующий вызов блокирует поток до того момента, как будут-получены данные. Во время блокировки процесс не потребляет процессорное время, но потребляет память. Например, для выполнения запроса к БД из пула потоков берётся поток, далее он ожидает, пока БД выполнит запрос и вернёт результат.

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

Почему простаивание потока — это проблема?

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

Кроме того, процессорное время, которое выделяется неработающим потокам, могло бы быть использовано для других задач. Если большое количество потоков простаивает, это может привести к увеличению загрузки процессора и снижению производительности, так как операционная система будет тратить больше времени на ../fundamental/Переключение контекста.

Если посмотреть на соотношение скорости ../fundamental/Центральный процессор и возможности сетевых соединений, то отличия на пару порядков. Например, на этом слайде сжатие 1 Кб данных занимает 3 мкс, в то время как round trip в одну сторону даже внутри одного дата-центра это уже 0,5 мс. Любое сетевое взаимодействие, которое нужно бэкенду (например, отправка запроса в БД), потребует, как минимум 2х round trip-ов и по сравнению с тем процессорным временем, которое он тратит на обработку данных, это совершенно незначительно. Большую часть времени обработки запроса бэкенд ничего не делает, просто ждет.

Заметки

  • Чтение с диска в linux может быть только блокирующим.

Мета информация

Область:: ../../meta/zero/00 Архитектура ПО Родитель:: Источник:: Автор:: Создана:: 2024-01-28

Дочерние заметки