🚀 Тюнинг производительности PHP-FPM

Правильная настройка PHP-FPM имеет решающее значение для эффективного использования ресурсов сервера. Вот несколько ключевых параметров для оптимизации производительности:

🔧 Основные параметры:
pm = dynamic
Управляет количеством рабочих процессов. В режиме dynamic количество процессов изменяется в зависимости от нагрузки сервера.
pm.max_children = 1000
Максимальное количество рабочих процессов. Высокие значения могут привести к ошибкам из-за нехватки памяти. Пример: для 1000 процессов × 100MB/процесс потребуется 100GB RAM.
pm.start_servers = 80
Количество процессов, которое будет запущено при старте PHP-FPM для быстрой обработки начальной нагрузки.
pm.min_spare_servers = 40
Минимальное количество «запасных» процессов, которые должны оставаться в ожидании.
pm.max_spare_servers = 120
Максимальное количество неактивных процессов. Если их больше, лишние процессы будут завершаться.
request_terminate_timeout = 300s
Ограничение времени для запроса — если выполнение длится более 5 минут, процесс будет завершен.
request_slowlog_timeout = 5s
Все запросы, которые выполняются более 5 секунд, записываются в лог для анализа производительности.

📊 Рекомендации:
Для серверов с меньшим объёмом памяти, например 8GB RAM, настройте:

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

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

👉 Поделитесь этим постом с коллегами!

🔗 Ссылка на статью

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

#лучшее2025

💻 Первый дайджест новостей в этом году:​

🔹 Laravel 12.44 — в HTTP-клиенте появились колбэки afterResponse(), позволяющие обрабатывать ответ после его получения. Также добавлены ассерты заголовков для TestResponse, новые fluent-методы валидации дат и другие улучшения.

🔹 Laravel News: итоги 2025 — редакция подвела итоги года, отметив ключевые события экосистемы: релиз Laravel 12, запуск Laravel Cloud, крупные обновления инструментов и рост сообщества.

🔹 Symfony: итоги 2025 года — команда Symfony рассказала о главных достижениях проекта за год, поблагодарив сообщество за вклад в развитие фреймворка.

🔹 Symfony 29 декабря 2025 — 4 января 2026 — выпущены maintenance-версии Symfony 6.4.31, 7.3.9, 7.4.3 и 8.0.3, а также опубликован официальный годовой обзор Symfony за 2025 год.

🔹 Symfony UX 2.32.0 — представлен новый Toolkit Package с настраиваемыми UI-компонентами (на базе Shadcn UI): Button, Dialog, Card, Table, Pagination и другие.

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

#свежак

💡Совет по Laravel: методы dot и undot

При работе с коллекциями Laravel может возникнуть необходимость преобразовать многомерную коллекцию в одноуровневую или наоборот. К счастью, для этого существуют два метода: dot() и undot() 🚀.

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

#vardump

🧵 PHP и многопоточность: куда всё реально движется (TrueAsync)

Статья — не про «давайте добавим async». Она отвечает на более жёсткий вопрос: способен ли PHP вообще эволюционировать к настоящему параллелизму — и какой ценой.
Коротко и без иллюзий 👇

❓ Зачем эта статья
RFC TrueAsync 1.7 упирается в будущее PHP Core. Асинхронность нельзя проектировать в вакууме — нужно понимать:
где у PHP фундаментальные ограничения,
можно ли выйти за рамки корутин,
возможна ли реальная многопоточность без слома экосистемы.

🧪 Эксперимент, который всё прояснил
Попытка обрабатывать CPU-тяжёлую телеметрию через корутины (Swoole):
I/O — отлично
CPU (сжатие, сериализация) — просадка throughput ×2

Вывод жёсткий, но честный:

Корутины не решают CPU-bound задачи.

Решение с выносом вычислений в отдельные процессы оказалось быстрее, несмотря на IPC.

🧠 Базовая модель: Single-threaded + offload
Рабочая архитектура, уже доказавшая эффективность:
Event Loop (1 поток)
I/O, сеть, БД, ожидание
Workers (несколько потоков / процессов)
сжатие, криптография, парсинг, ML
Так работают:
🔸Node.js (Worker Threads)
🔸Python (asyncio + executors)
🔸 PHP (Swoole Request Workers + Task Workers)

✅ Плюсы модели
🔹 тысячи I/O-операций без mutex’ов
🔹 простота reasoning’а (нет гонок)
🔹 минимум требований к компилятору
🔹 контроль над нагрузкой
❌ Минусы
🔻 ручное разделение задач
🔻 легко ошибиться и положить event loop
🔻 плохо подходит для вычислительных систем

🧱 Почему PHP не готов к потокам «из коробки»
Главная проблема — память и GC:
🔸глобальный object_store
🔸refcount + stop-the-world GC
🔸память одного VM нельзя освобождать из другого потока
🔸ZTS ≠ настоящая многопоточность
PHP — строго single-VM модель.

🧠 Ключевая идея: не делить память, а передавать владение
Вместо shared mutable state:
🔸move-семантика объектов
🔸если refcount = 1 → перенос без копии
🔸иначе → deep copy с сохранением идентичности
Это:
🔸безопасно
🔸без сериализации
🔸прозрачно для разработчика

🧵 Что реально нужно в core
🔸многопоточный memory manager
🔸адаптация GC под параллельный режим
🔸поддержка shared immutable объектов (GC_SHARE)
🔸исследование region-based memory

Это не «хотелки», а необходимые условия.

🧩 Корутины + потоки вместе

Поток = Awaitable.

🔸корутина не блокируется
🔸CPU-задача уходит в thread pool
🔸event loop остаётся отзывчивым
Код выглядит последовательно, но работает параллельно.

🎭 Самая сильная абстракция — Actors
Actors дают:
🔸изолированное состояние
🔸последовательную обработку сообщений
🔸отсутствие mutex’ов
естественное OOP-мышление

Каждый actor:
🔸может жить в своём потоке
🔸имеет собственный регион памяти
🔸безопасно масштабируется

Это реальный путь к безопасной многопоточности в PHP.

🔗 Medium

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

Что будет выведено на экран?

⚖️ whereHas() vs whereRelation() в Laravel

короче — не значит понятнее

Laravel-разработчики любят шорткаты. Меньше кода, меньше шума — приятно.
Но в реальных проектах с командой и постоянно меняющимися требованиями выигрывает ясность, а не длина строки.

Часто советуют заменить whereHas() на whereRelation():

// было
User::whereHas('profile', function ($q) {
    $q->where('is_verified', false);
})->get();

// стало
User::whereRelation('profile', 'is_verified', false)->get();

Формально — да, код короче.
Практически — не всё так радужно.

🧠 В чём реальная разница
whereHas() — явно про отношения

User::query()
    ->whereHas('profile', fn ($q) => $q->where('is_verified', false))
    ->get();

С первого взгляда понятно:

🔸фильтрация по relation

🔸логика живёт внутри профиля

🔸условия легко расширяются

🔸запрос честно отражает намерение

whereRelation() — скрывает сложность

User::whereRelation('profile', 'is_verified', false)->get();

Читается как фильтр по колонке users.
Но на деле — это подзапрос к связанной таблице.

❗️ Это вводит в заблуждение, особенно при чтении чужого кода.

🧩 Масштабирование условий

С whereHas() — естественно и прозрачно:

->whereHas('profile', fn ($q) => $q
    ->where('is_verified', false)
    ->whereNotNull('phone')
    ->where('age', '>', 18)
)

С whereRelation():

🔸либо цепочка вызовов

🔸либо возврат к whereHas()

🔸либо каша из стилей

🔍 Поиск и поддержка кода

Реальный кейс:

«Эндпоинт тормозит, ищем фильтрацию по отношениям»

whereHas() — легко найти поиском

whereRelation() — прячется среди обычных where

Для поддержки и отладки это критично.

⚙️ Производительность — миф

whereRelation() не быстрее.
Под капотом — тот же whereHas() и почти идентичный SQL.

Если медленно:

🔸нет индексов

🔸не тот подход к запросу

Метод тут ни при чём.

🧱 Проблема консистентности

Что происходит в проектах:

1. Сначала whereRelation() — «быстро и красиво»

2. Потом требования растут

3. Появляется whereHas()

4. В коде — два стиля без причины

5. В ревью — споры

Если сразу использовать whereHas():

🔸один паттерн

🔸единый стиль

🔸код готов к росту

🧠 Внутренности Laravel

Без магии:
whereRelation() — это обёртка над whereHas().
Не умнее. Не быстрее. Просто без closure.

📌 Правило на практике

Можно whereRelation(), если:

🔸один простой фильтр

🔸скрипт, отчёт, админка

🔸логика точно не вырастет

Лучше whereHas(), если:

🔸бизнес-логика

🔸командная разработка

🔸код придётся читать и менять

Экономия пары символов — плохой аргумент.
Пишите код для того, кто откроет файл через полгода.
В реальных проектах честный whereHas() почти всегда выигрывает.

👉 Ссылка на статью

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

#элементарный_выбор

🔍 Can I PHP: проверяем доступность фичи налету

Расширение позволяет проверить доступность определенной функции/метода в различных версиях PHP и получить краткое описание возможностей.

👉 Сайт

#инструменты