{
  "index": 369,
  "slug": "особенности-vibe-d",
  "title": "Vibe.d: как не заблокировать event loop в сервере на D",
  "excerpt": "Vibe.d прячет асинхронное ожидание за последовательным кодом. Разберём, где это ускоряет разработку, где обычный вызов блокирует event loop и как проверить границу между запросом, worker-потоком и внешним ресурсом.",
  "contentHtml": "<h2>Симптом: короткий handler, длинный ответ</h2>\n<p>Сервис на vibe.d принимает HTTP-запросы, но под нагрузкой ответы начинают ждать друг друга. Один endpoint отвечает быстро, пока другой читает большой файл или считает хеш. Затем растёт очередь, увеличивается p95, а клиент получает timeout.</p>\n<p>Цена ошибки — не только медленный ответ. Занятый worker перестаёт обслуживать другие соединения. Повторные запросы создают ещё больше работы. Внешний сервис видит всплеск повторов, а оператор получает ложный сигнал о проблеме в сети или базе данных.</p>\n<figure><img src=\"/assets/illustrations/vibe-async.svg\" alt=\"Волокно передаёт управление event loop во время ожидания\" /><figcaption>Волокно возвращает управление циклу событий только в точке, где операция действительно умеет ждать.</figcaption></figure>\n<p>Тезис статьи простой: vibe.d делает асинхронный код похожим на последовательный, но не превращает любой вызов в асинхронный. Вызов освобождает поток только тогда, когда библиотека или адаптер явно передаёт управление планировщику. Синхронный диск, тяжёлый CPU-код и неизвестная библиотека остаются синхронными.</p>\n<h2>Механизм: fiber не равен потоку</h2>\n<p>Fiber хранит отдельный стек вызовов и выполняется в контексте потока, который его запустил. В каждый момент этот поток исполняет только одну fiber-задачу. Переключение происходит кооперативно: текущая задача сама уступает управление, а планировщик запускает другую.</p>\n<p>Для HTTP-сервера это удобно. Обработчик может выглядеть линейно: получить запрос, дождаться внешнего ответа, сформировать результат. Внутри ожидания сетевой операции поток спит, а event loop принимает другое соединение. Так разработчик не размазывает состояние по цепочке callback-функций.</p>\n<p>Это работает только на границе, которую понимает runtime. Асинхронный HTTP-клиент может зарегистрировать сокет и вернуть управление. Поддержанный таймер может поставить продолжение в очередь. Вызов <code>read</code> из обычной файловой библиотеки может удерживать поток до окончания чтения. Цикл с миллионами итераций тоже не уступит управление сам.</p>\n<p>Поэтому у запроса есть два независимых свойства. Первое — его логический срок жизни: от входа в router до ответа или исключения. Второе — место ожидания: event loop, async-клиент или worker. Если эти свойства не назвать явно, короткий код создаёт длинную очередь.</p>\n<h2>Учебный пример: быстрый путь и опасный путь</h2>\n<p>Ниже показан минимальный HTTP-сервер. Он демонстрирует форму обработчика и не является production-конфигурацией: в нём нет TLS, аутентификации, структурированного логирования, лимитов тела запроса и настройки graceful shutdown.</p>\n<pre><code>import vibe.http.server;\nimport vibe.http.router;\n\nvoid health(HTTPServerRequest req, HTTPServerResponse res)\n{\n    res.writeBody(`{\"status\":\"ok\"}`, \"application/json\");\n}\n\nvoid report(HTTPServerRequest req, HTTPServerResponse res)\n{\n    // Учебный контур: быстрый CPU-путь допустим только\n    // для малого фиксированного объёма данных.\n    auto body = `{\"ready\":true}`;\n    res.writeBody(body, \"application/json\");\n}\n\nvoid main()\n{\n    auto router = new URLRouter;\n    router.get(\"/health\", &amp;health);\n    router.get(\"/report\", &amp;report);\n\n    auto settings = new HTTPServerSettings;\n    settings.port = 8080;\n    listenHTTP(settings, router);\n    runApplication();\n}</code></pre>\n<p>Оба маршрута здесь завершаются быстро. Но добавление обычного чтения файла меняет поведение всего процесса. Пока обработчик ждёт диск, тот же worker не может перейти к другой задаче. Асинхронная оболочка вокруг router не исправляет синхронный вызов внутри handler.</p>\n<p>Безопасный вариант начинается не с названия функции, а с контракта зависимости. Если библиотека даёт async-операцию, используйте её и проверьте, где она уступает управление. Если библиотека синхронная, вынесите вызов в worker-поток или отдельный процесс. Для CPU-нагрузки применяйте тот же принцип. Увеличение числа fibers не ускорит вычисление, которое не делает yield.</p>\n<h2>Диагностика: симптом → причина → проверка → действие</h2>\n<table>\n<thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead>\n<tbody>\n<tr><td>Все endpoints замедляются одновременно</td><td>Один handler блокирует event loop</td><td>Сопоставить время handler с профилем потока и очередью задач</td><td>Убрать синхронный вызов или перенести его в worker</td></tr>\n<tr><td>Задержка появляется на больших файлах</td><td>Чтение идёт через блокирующий API</td><td>Сравнить малый и большой файл, записать время системного вызова</td><td>Использовать async-адаптер или отдельный worker с лимитом</td></tr>\n<tr><td>CPU одного потока держится около 100%</td><td>Длинный расчёт не уступает управление</td><td>Снять CPU-профиль и найти длинный участок без ожидания</td><td>Разбить работу, применить worker-пул или очередь</td></tr>\n<tr><td>После ошибки растёт число открытых соединений</td><td>Исключение обрывает путь закрытия ресурса</td><td>Проверить счётчики соединений до, во время и после ошибки</td><td>Закрывать ресурс в гарантированном cleanup-пути</td></tr>\n<tr><td>Клиент ждёт дольше таймаута</td><td>Нет общего deadline для запроса и внешнего вызова</td><td>Протрассировать deadline от входа до ответа</td><td>Передать timeout вниз и вернуть контролируемую ошибку</td></tr>\n</tbody>\n</table>\n<p>Таблица помогает не подменять измерение догадкой. Высокая задержка сама по себе не доказывает проблему event loop. Виноват может быть внешний сервис, блокировка базы или ограничение диска. Проверка должна разделить время в handler, время ожидания внешней системы и время постановки задачи в очередь.</p>\n<h2>Граница запроса и ресурсов</h2>\n<p>Обработчик владеет не только response. Он отвечает за все ресурсы, которые получил для выполнения запроса: соединение с базой, временный файл, буфер, задачу в очереди и таймер. Если внешний вызов завершился исключением, ресурс должен закрыться или вернуться владельцу. Если клиент разорвал соединение, продолжение не должно бесконечно работать в фоне.</p>\n<p>Практическая схема выглядит так. На входе создайте контекст с request id и deadline. Передайте его во внешние вызовы. На успешном пути сформируйте ответ. На ошибочном пути преобразуйте известные исключения в статус и лог. В cleanup-пути закройте соединение и отмените то, что больше не нужно. Конкретные имена API зависят от версии vibe.d и пакета клиента, поэтому их нужно сверять с документацией проекта.</p>\n<p>Исключение полезно, когда оно проходит через последовательный стек и попадает на границу, где его могут обработать. Оно не заменяет timeout и отмену. Непойманная ошибка не должна оставлять задачу, удерживающую сокет или временный файл. Особенно опасен код, который создаёт fiber для запроса и не хранит способ дождаться его завершения или отменить его.</p>\n<h2>Порядок действий перед выводом о производительности</h2>\n<ol>\n<li>Назовите все операции внутри handler: сеть, база, файл, сериализация и CPU-расчёт.</li>\n<li>Для каждой операции укажите владельца ожидания: event loop, async-клиент, worker-поток или отдельный процесс.</li>\n<li>Проверьте исходный код или документацию зависимости и найдите точку, в которой она уступает управление.</li>\n<li>Добавьте единый deadline запроса и передайте остаток времени во внешние вызовы.</li>\n<li>Сделайте ошибочный путь явным: обработайте исключение, отмените продолжение и освободите ресурс.</li>\n<li>Запустите учебный сценарий с несколькими параллельными запросами: один должен ждать, другой — быстро отвечать.</li>\n<li>Снимите профиль и метрики очереди. Сравните время handler, внешнего ожидания и CPU.</li>\n<li>Только после этого решите, нужен ли async-адаптер, worker-пул, кеш или изменение самого endpoint.</li>\n</ol>\n<p>Отрицательный путь нужно проверять отдельно. Запрос к недоступной базе, медленный диск, отмена клиента и исключение сериализации должны завершаться ограниченно. Если тест проверяет только успешный ответ, он не проверяет владение ресурсом.</p>\n<h2>Когда vibe.d подходит, а когда нет</h2>\n<p>vibe.d подходит, когда команде нужен сервер на D с компактным HTTP-слоем и асинхронными операциями, а команда готова проверять поведение зависимостей. Fibers упрощают последовательное описание долгого сетевого сценария. Event loop позволяет обслуживать много ожидающих операций небольшим числом потоков.</p>\n<p>Выбор хуже подходит, когда основная работа endpoint — непрерывный CPU-расчёт, а архитектура не предусматривает worker-пул или очередь. Он также рискован, если в проекте много библиотек с неизвестной блокирующей семантикой. Простая сигнатура функции не сообщает, уступает ли вызов управление.</p>\n<p>Нельзя обещать меньшую задержку только потому, что код использует fibers. Кооперативное переключение уменьшает стоимость большого числа ожидающих задач, но не меняет время ответа внешней базы и не параллелит код внутри одного потока. Параллельное выполнение требует потоков или процессов. Большое число fibers не заменяет лимит очереди и backpressure.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Считайте endpoint готовым к дальнейшему тестированию, если для каждого вызова внутри handler записан владелец ожидания, задан deadline, а ресурс имеет путь закрытия при успехе, timeout, отмене и исключении. На контрольном сценарии быстрый endpoint отвечает во время медленного ожидания другого запроса. Профиль не показывает длинный синхронный участок в event loop. Этот критерий не доказывает production-производительность, но делает главный риск измеримым.</p>\n<p>Отдельно проверьте, что учебный пример не попал в конфигурацию без нужной защиты. Минимальный сервер показывает форму API, а не готовые настройки эксплуатации. Реальные лимиты, TLS, наблюдаемость и версия компилятора должны пройти собственную проверку.</p>\n<h2>Проверяемые источники</h2>\n<p><a href=\"https://github.com/vibe-d/vibe.d\">Официальный репозиторий vibe.d</a> — исходный код, документация в репозитории и актуальные версии проекта.</p>\n<p><a href=\"https://dlang.org/book/fibers.html\">D Programming Language: Fibers</a> — официальное объяснение отдельных стеков, кооперативного переключения и применения fibers для асинхронного ввода-вывода.</p>\n<p><a href=\"https://dlang.org/library/core/thread/fiber.html\">D Library: core.thread.fiber</a> — справочник по Fiber и условиям выполнения в потоке, который вызвал fiber.</p>"
}