🧵 PHP Fibers вместо ада сериализации

В 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 легли сверху.

🔗 Читать оригинал

🐸 Библиотека пхпшника

🔍 Работа с awk

Логи сервера в plain text, нужно быстро подсчитать количество запросов по HTTP-статусам? awk — ваш Swiss Army Knife для обработки текстовых данных прямо в терминале.

🔹 Зачем это нужно

— Мгновенная агрегация данных из логов без загрузки в БД или Python.
— Работает с любым текстовым форматом.
— Есть на каждом сервере.

🔹 Как использовать

— Подсчёт по статусам (nginx access.log): awk '{print $9}' access.log | sort | uniq -c | sort -rn
— Среднее время ответа: awk '{sum+=$NF; n++} END {print sum/n}' access.log
— Только 5xx ошибки: awk '$9 ~ /^5/' access.log
— Топ-10 IP по количеству запросов: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10
— Вывести конкретные поля: awk -F',' '{print $1, $3}' data.csv

⌛ Сохраняйте шпаргалку по Kubernetes

⌨️ Топ-вакансий по PHP за неделю

Middle/Senior PHP-разработчик (Laravel + высоконагруженные системы) — от 200 000 до 350 000 ₽ — офис (Москва)

Team Lead PHP/Go — 3 000 —‍ 4 000 € — удалёнка

Senior PHP Developer — от 4 000 € — удалёнка

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

🐘 Работа с PostgreSQL

Таблица разрослась до десятков гигабайт, но данных в ней на пару гигов после массовых DELETE? VACUUM FULL перепишет таблицу и вернёт место на диск. Но есть нюансы.

🔹 Зачем это нужно

— PostgreSQL при DELETE не освобождает место на диске, а помечает строки как мёртвые.
— Обычный VACUUM чистит мёртвые строки для переиспользования, но файл не уменьшает.
— VACUUM FULL физически переписывает таблицу, реально освобождает место.

🔹 Как использовать

— Проверить «раздутие»: SELECT pg_size_pretty(pg_total_relation_size('my_table'));
— Мёртвые строки: SELECT n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname = 'my_table';
— Обычный VACUUM: VACUUM VERBOSE my_table; (не блокирует таблицу)
— Полная перезапись: VACUUM FULL my_table; (⚠️ блокирует таблицу полностью!)
— Обновить статистику: ANALYZE my_table;

💡 VACUUM FULL берёт эксклюзивный лок — таблица полностью недоступна. На проде используйте pg_repack, он делает то же самое, но без блокировки. Ставится как расширение: CREATE EXTENSION pg_repack;

🐸 Библиотека пхпшника