В Manychat жили на curl_multi_exec для псевдоконкурентных запросов. Работало, пока AI-фичи не размножились. Каждый внешний вызов означал: сериализуй состояние бизнес-логики, отдай в очередь, дождись, десериализуй, восстанови контекст. Ревью кода превращались в квест — логика рвалась на куски вокруг async-границ.
Добил их апгрейд Ubuntu: OpenSSL 3.0 со своими мьютексами на обходе хранилища сертификатов выкатил +10% к CPU на ровном месте. Виноваты синхронные вызовы Meta API, т.к. каждый payload открывал новый TCP.
Решение — затащить Fibers поверх существующего event loop на Guzzle. Файбер приостанавливается на внешнем HTTP, воркер берёт следующий payload, при готовности ответа возобновляет нужный файбер с того же места:
$fiber = new Fiber(function() {
echo "Suspending\n";
$last = Fiber::suspend(16);
echo "Resuming with {$last}\n";
});
$last = $fiber->start(); // 16
$fiber->resume(42); // 42🚀 Что получили
Переиспользование одного HTTP/2 соединения на воркер (прощай, рукопожатия);
Асинхронный sleep вместо блокировки всего процесса при ретраях;
Линейный код без знания разработчиком про файбер под капотом.
💣 Расплата → радиус поражения. Раньше фатал клал воркер с одним payload. Теперь в полёте висят пятеро файберов, и OOM убивает всех. Catchable-ошибки переписали так, чтобы валить только свой файбер.
Если бы начинали с нуля, взяли бы Revolt или AMPHP. Но кастомный луп уже был, Fibers легли сверху.
🔗 Читать оригинал
🐸 Библиотека пхпшника