Вчера с Даней отсмотрели все дизайнерские работы на конкурс страницы релиза PHP 8.5.
Чтобы не смотреть 2 часа видео, вот мой топ:

1. Работа ben-joostens

Как я понимаю, за основу взята страница релиза PHP 8.4, но с доработками: рамки на блоках кода, расположение, интересная задумка с затенением "старого" кода; по наследству органично вписывается в текущий дизайн php.net.
Немного отделяется последний блок, но это легко можно пофиксить.
В общем, получилась достаточно приятная страница

2. Работа thiagoolivier

Release Page здорового PHPшника. Вся страница пропитана духом бэкенда. Всё чистенько, ни одного лишнего элемента, просто ноль бесполезных свистоперделок, которые часто добавляют по принципу "прикольную штуку нашёл, надо куда-то повесить" или "смари как могу".

Это тупик эволюции того дизайна, который получается у бэкендера или фуллстека, накидывающего веб-морду на коленке с мыслью "самое основное сделаю, а блёстки пусть дизайнер рисует".

Выбрал бы его на первое место, но есть только одно но: есть ощущение, что шапка php.net тут ну ни как не впишется.

3. Работа lumnn
Да, выглядит ужасно и недоделано, как будто пилилось в последние 4 часа: контент с лопаты накидан или вообще недокидан, какие-то эмоджи в шапке...
Вот если убрать 4 кнопки из шапки, отформатировать код, добавить текст и всё, то получится твёрдое третье место.

Но важно в этой работе совсем другое. Автор предложил очень интересную идею, как можно минимальными усилиями освежить весь php.net: банально добавить зумерский градиент, немного подкрутить шрифты и ещё что-то по-мелочи. Главная страница тоже выглядит интересно.


5. Отдельно прокомментирую продвигаемую инфлюенсерами работу от nunowar, которая в моём рейтинге занимает 5-7 место.

Меня поймут те, кто раньше распечатывал интернет-странички в режиме экономии тонера: весь цветно фон пропадал или становился серым; местами ещё продрисью виднелись какие-то элементы; в целом, это получалось как блоки текста, раскиданные по бумаге.

Вот примерно так выглядит светлая тема в этом дизайне.

В тёмной теме лучше: блоки кода, блоки блоков кода и сегменты страницы уже имеют разный фон. Видны текстуры, орнаменты и анимация. Я не падкий на орнамент и анимацию, по мне это лишнее, но пофиг. Пофиг даже на бесполезный блок "PHP is used by the world's leading companies".
Мене здесь не нравится конкретно другое: нельзя просто наложить на сайт синюю плёнку и продвигать это решение как лучшее или современное. Спасибо, что шрифт не голубой, но почему-то в других работах догадались добавить в палитру третий цвет.

Я понимаю, что о вкусах не спорят, но... надеюсь PHP Foundation поступит как в той присказке: "послушай женщину сообщество и сделай наоборот как надо".

Призываю фартанов тоже пощёлкать по работам и поставить лайки понравившимся.

Ничего личного, просто #ТоксикСреда

Оказывается, у нашего канала есть Telegram-подарок!

Спасибо, Тринчик. Этот комментарий — лучший знак признания!
Не сомневайся, мы будем и дальше с тем же усердием делать laravel-workflow.

По итогу конкурса победил Nunowar, продвигаемый ларавелем.

Кто-то удивился? :)

А вот и Podlodka всплыла.

Даты: 1..5 декабря
Тема: «Ускоряем PHP-разработку»

Там и Павел выступать будет (что-то про AI-разработку).

Ай да за билетами!
Промокод PHP_FART в силе! (спасибо, Толик)

💀 Как один ORM-запрос съел 300 МБ навсегда

История из нашего проекта: неоптимальный запрос через ORM загрузил ~100К записей из базы. Worker в RoadRunner вырос с 80 до ~500 МБ... и больше никогда не вернулся обратно.

Звучит как утечка памяти? Спойлер: это не баг, а особенность архитектуры PHP.

💡 Неочевидный факт: PHP никогда не возвращает память ОС в long-running процессах

Zend Memory Manager выделяет память большими блоками — чанки по ~2-4 МБ. Когда вы делаете unset($data) или переменная выходит из scope — память освобождается ВНУТРИ PHP, но операционная система об этом не узнаёт.

Чанки остаются закреплёнными за процессом до его завершения. Это сделано ради производительности: повторное использование уже выделенной памяти быстрее, чем постоянные запросы к ОС.

Почему это критично для RoadRunner, Laravel Queue, демонов?

В PHP-FPM каждый запрос = новый процесс, память автоматически очищается. В long-running процессах один worker обрабатывает тысячи задач — и каждый "пик" памяти становится новым baseline навсегда.

Ну а теперь про то, как себя обезопасить от всего этого?
- Использовать батчинг для выборок
- Ограничивать объём данных в памяти в рамках одной операции
- Обрабатывать данные потоково, без загрузки всего набора сразу
- Выносить тяжёлые операции в отдельные функции для автоматического освобождения локальных переменных
- Применять gc_mem_caches() для очистки внутренних пулов, и молиться, что поможет именно в вашем случае)
- Анализировать участки кода, создающие единовременные всплески в десятки МБ. Лучше не игнорировать всплески памяти, надеясь что “само освободится”

Что можно сделать на уровне PHP воркеров:
1. Можно использовать ротацию по количеству задач, например в RoadRunner pool.max_jobs=1000, Laravel Queue --max-jobs=1000. После выполнения 1000 задач, воркер будет перезапущен. Но не стоит полагаться на ротацию как на замену оптимизации, ведь пик может возникнуть в первых же запросах.
2. В RoadRunner — при необходимости включать soft-лимиты по памяти, при достижении которого воркер перезапускается.

Куда ещё может утекать память:
- Статические переменные, накапливающие данные
- Глобальные массивы, в которых растёт состояние
- Singleton-сервисы с неограниченными кешами
- ORM-кеши, которые не сбрасываются
- Списки подписчиков/слушателей, которые не удаляются
- Циклические ссылки объектов друг на друга.