Ожидание и вычисление используют время по-разному
В Node.js цикл событий организует выполнение обработчиков. Неблокирующие операции ввода-вывода позволяют ожидать готовности результата, не занимая основной поток непрерывной пользовательской вычислительной работой. Когда результат готов, соответствующее продолжение ещё должно получить возможность выполниться. Длительный синхронный расчёт устроен иначе. Пока его код работает в основном потоке, другие обработчики не могут просто прервать его и выполнить свою часть JavaScript. Поэтому один тяжёлый участок способен задержать даже запросы, которым почти не нужны вычисления. Это относится к конкретному занятому потоку, а не означает, что во всём процессе вообще нет других потоков.
Асинхронная оболочка не меняет место работы
Представим вымышленный обработчик, который получает набор чисел и долго пересчитывает статистику обычным циклом. Добавление слова async к функции само по себе не переносит этот цикл в отдельный вычислитель. Аналогично нужно различать ожидание результата и фактическую организацию работы, которая его создаёт. В бумажной схеме допустим, что расчёт занимает основной поток от нулевой до восьмидесятой миллисекунды. Другой обработчик становится готов к выполнению на десятой. Он не выполнится посреди непрерывного расчёта только потому, что внешняя функция названа асинхронной. Это условная временная модель, а не измерение производительности настоящего сервера.
Способ изменения выбирают по характеру задачи
Для тяжёлых вычислений JavaScript можно рассматривать отдельные рабочие потоки. Они предназначены для выполнения такой работы параллельно; для обычного асинхронного ввода-вывода их добавление часто не даёт того же смысла. Также иногда возможно разделить работу на небольшие части с передачей управления между ними. Любое решение имеет затраты: передачу данных, организацию выполнения и управление ресурсами. Поэтому сначала полезно установить, где именно тратится время. Замедление внешнего сервиса, занятый основной поток и перегруженный исполнитель — разные причины. Само наличие обещания результата или ключевого слова не доказывает ни параллельность, ни отсутствие блокировки. Этот разбор объясняет принцип и не заменяет измерения конкретного приложения.
Попробуйте на практике
Нарисуйте временную схему двух вымышленных задач. Писать код и запускать сервер не нужно.
- На первой линии отметьте непрерывный расчёт JavaScript в основном потоке от нулевой до восьмидесятой миллисекунды.
- На второй отметьте готовность короткого обработчика на десятой миллисекунде. Укажите, почему в этой схеме он должен дождаться освобождения основного потока.
- Подпишите расчёт как находящийся внутри функции с обозначением async. Проверьте, изменилось ли от одной подписи место выполнения вычислений.
- Составьте два вопроса для дальнейшего исследования: где реально выполняется тяжёлая работа и какую часть задержки составляет ожидание внешнего результата.
Как проверить результат. Схема верна, если короткий обработчик не помещён внутрь непрерывно занятого интервала основного потока. Слово async не должно создать на рисунке второй поток без отдельно описанного механизма его появления.
Частые вопросы
Значит, асинхронность бесполезна?
Нет. Она важна для организации ожидания и работы с неблокирующими операциями. Ошибка состоит в ожидании, что одна форма записи автоматически распараллелит любые вычисления.
Нужно ли переносить каждый обработчик в рабочий поток?
Нет. Передача и организация работы тоже требуют ресурсов. Решение зависит от характера и объёма задачи, поэтому его проверяют измерениями, а не универсальным правилом.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.