Привет.
Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.
Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm.
Я хочу поднять простое приложение с Laravel проектом, которое устанавливается со всеми параметрами по умолчанию. Попробуем это приложение нагрузить пользователями с помощью простого Javascript скрипта и посмотрим как ему удастся справиться с нагрузкой и как мы можем повысить обрабатываемую нагрузку только конфигурированием php-fpm. В конце статьи можно будет найти ссылку на GitHub и попробовать своими руками.
Для начала посмотрим на стандартную конфигурацию php-fpm и попытаемся понять где могут быть проблемы в производительности с коробки.
Итак, у меня есть простое приложение на PHP с NGINX и PHP-FPM предустановленными в стандартных конфигурациях и маршрут Laravel.
Маршрут симулирует нагрузку через команду засыпания на одну секунду и возвращает простой json ответ.
Так же у меня есть Javascript файл который производит запрос на наш роут. Запускать его мы будем с помощью нагрузочной утилиты k6.
Для того чтобы провести нагрузочное тестирование давайте запустим утилиту k6 с пятью VU (virtual users)
k6 run --vus 5 --duration 30s script.js
Результат нагрузки:
Как видим в строке http_req_duration avg (среднее по всем показателям значение) равно 1.77 сек. Это сама нагрузка 1 секунда + время прохода запроса по сети и работа фреймворка.
Давайте проведём еще один такой же тест но на 10и пользователях
k6 run --vus 10 --duration 30s script.js
Результат нагрузки:
Как видим время возросло почти в два раза.
Давайте проведём еще один тест и будем разбираться в чём же дело.
На этот раз попробуем нагрузить сразу 50ью пользователями наше приложение.
k6 run --vus 50 --duration 30s script.js
Результат нагрузки:
Как видим результат стал совсем грустным. В среднем клиенту приходится ждать ответа от сервера 15.48 секунд. Давайте разбираться в чём дело.
Для начала давайте узнаем какая сейчас конфигурация php-fpm. Сделать это можно с помощью команды php-fpm -tt
Эта команда выведет все параметры php-fpm, самые важные параметры я обвел рамкой.
Самый важный параметр - это pm.max_children он равен сейчас 5. Этот параметр сообщает нашему php-fpm сколько он может максимально запустить дочерних процессов (обработчиков) запросов. Иными словами сколько параллельно процессов будет обрабатывать входящую нагрузку.
Для лучшей наглядности я нарисовал небольшую схему.
Когда в наше приложение одномоментно приходит 50 клиентов они сначала обращаются в наш NGINX, он является просто прокси сервером и пробрасывает запросы сквозь себя на PHP-FPM (за исключением запросов за статическими ресурсами/файлами) и дальше PHP-FPM пытается обработать все запросы с помощью своих процессов (воркеров). Если же ситуация как у нас, когда PHP-FPM располагает только пятью воркерами, то первые 5 клиентов обрабатываются, а остальные 45 становятся в очередь и ждут, когда первые 5 обработаются. Как только первые 5 отработали, следующие 5 зашли на их место и оставшиеся 40 ждут в очереди.
На этом этапе появляется две проблемы. Первая - мы заставляем таким образом ждать клиентов ответа, вторая - если время ожидания будет выше стандартного для NGINX в параметре fastcgi_read_timeout (стандартное 30 секунд) то мы можем получить 504 ошибку от NGINX. Вторую проблему мы можем исправить увеличив время ожидания, но это не спасет нас от первой проблемы.
Логичное решение проблемы - просто добавить воркеров для PHP-FPM и это вполне адекватная мысль, но стоит позаботиться о том, чтобы добавить достаточно воркеров и не добавить лишних воркеров, которые займут всю операционную память.
Давайте вернёмся к нашим конфигурационным параметрам и постараемся сделать правильную настройку.
Итак, нас интересуют следующие параметры:
pm = dynamic - php-fpm сам контролирует количество запущенных воркеров, при указанном параметре dynamic php-fpm будет в зависимости от нагрузки добавлять или удалять воркеры. Так же в этом параметре может быть значение static в таком случае количество воркеров будет статическим.
pm.max_children - максимальное количество процессов единовременно работающих. Часто это значение ставится в количестве 4 * на количество CPU. Для того чтобы узнать количество CPU можно воспользоваться командой lscpu.
Более правильно будет еще проверить количество свободной памяти, можно сделать это командой free -hl
Обязательно нужно понимать сколько памяти занимает один воркер.
Это можно сделать с помощью команды htop и посмотреть среднее количество памяти которое занимают воркеры php-fpm
pm.min_spare_servers - минимальное количество процессов в состоянии ожидания. Это количество нужно как резервное в случае внезапного появления нового количества клиентов. Чтобы клиенты не ждали пока новые процессы создадутся резервные процессы подхватят внезапную нагрузку. Значение обычно ставится в 2 * на количество CPU.
pm.max_spare_servers - максимальное количество процессов в состоянии ожидания. В случае если нет нагрузки на приложение php-fpm удалит лишние процессы с целью сохранить оперативную память.
Хорошо, давайте сконфигурируем наш PHP-FPM.
Для начала найдем где находится файл конфигурации с помощью команды
whereis php-fpm
Ставим start_server в 24.
min_spare_servers в 12.
max_spare_servers в 24.
Перезапускаем докер.
И повторим нагрузочное тестирование с 50ью пользователями.
Результат нагрузки:
Как видите результат нагрузки средний 1.6 секунд. Примерно как и был в первом тесте, с пятью пользователями.
Так же еще можно посмотреть как отрабатывает php-fpm при установке pm стратегии в dynamic. Если вы запустите htop, то увидите стартовое количество воркеров
и если запустите тест, то постепенно количество воркеров сначала увеличится до максимально доступного
и после окончания теста снизится до начального.
Комментарии (53)
anonymous
00.00.0000 00:00
hello_my_name_is_dany
05.09.2021 04:16+2Автор под ускорением имел ввиду увеличение RPS, а не скорость обработки одного запроса
DimNS
05.09.2021 07:18+13Ну не знаю, мне как новичку в этом деле данная статья очень полезна, всё по существу, без воды и с реальным примером, а главное формулами, а не просто описанием параметров конфига. Просто автору надо было сделать статью с тегом tutorial и озаглавить что тутор для новичков, чтобы devops-отцы не канючили что это должен знать каждый ))
TheCluster
05.09.2021 09:07+4Какая-нибудь аналогичная статья, здесь или на другом сайте за 2009-2013 года ничем не хуже.
catkaff
06.09.2021 00:31"Какая-нибудь"... Вы в курсе, что обычно в таких случаях дают ссылки, а не плескают свой токсичный яд?
Nnnnoooo
06.09.2021 00:58поиск по хабру сразу находит это:
https://habr.com/ru/company/southbridge/blog/460511/pm static м другие режимы раскрыты в разы полнее. Да перевод, но все равно лучше чем данная статья. Единственный минус — придется читать и думать, просто копипаст не получится сделать.
По оптимизации php-fpm просто куча материалов в инете, главное определиться для чего нужно оптимизировать, для высокой нагрузки, для ограниченных ресурсов и т.д.
mrBarabas
05.09.2021 13:20Где Вы там формулы увидели, 4х и 2х от количества ядер - это не формула, это пальцем в небо. Нужно все тестить и все зависит от каждой конкретной ситуации, в большинстве случаев оно сработает, но там где нагрузка присутствует, хотя бы кратковременная - это уже время на настройку. Приведу пример из практики, впервые про эти настройки я узнал от гугла во время поиска причин проблем из логов (когда не хватает воркеров, то в лог пишется предупреждение), при чем проблема была на не самом посещаемом сайте из-за разогрева кеша - курл обходил 100+ страниц в несколько потоков при этом запускался на этом же сервере, то есть сетевых задержек не было. Сервер - обычная дешевая ВПСка с одним vCPU и 1Гб ОЗУ, сайт при этом не падал, но начинать тупить. Подняли лимиты на макс.количество воркеров, ещё раз и ещё несколько раз пока воркеров не стало хватать для обхода всех страниц и установили минимальное количество для обычной нагрузки. Поэтому, вместо установки 4х от чего-то и так далее нужно установить логи в 1 в php.ini и указать путь и периодически их просматривать, а потом уже делать вывода на основании того насколько сервер справляется.
Nnnnoooo
05.09.2021 14:20Да статья очень далека от какого либо администрирования.
Мне кажется что автор просто решил себе создать полноценный аккаунт на хабре.
Nnnnoooo
05.09.2021 14:18К чему тут девопсы-отцы. Я не девопс, администрированием занимаюсь только потому что мне надо чтобы мои проекты работали именно так как мне надо. И базовые настройки настройки php-fpm в связке с nginx-ом это первое что приходится узнавать.
Пользы от этой статьи ровно ноль, я бы даже сказал что отрицательная польза, потому что какой-то новичок просто погуглив найдет эту "инструкцию" и решит "протюнить" например свой бложик на вордпресс на убитой вдс-ке. Надеюсь не стоит объяснять что у него после этого получится?
Если бы статья была по типу описание полезных настроек php-fpm и nginx, которые может понадобится изменить (типа расширенного мануала с примерами, но только учитывая особенно пхп приложений). Вопросов бы не возникало.
Nnnnoooo
05.09.2021 14:29как же достало последнее обновление хабра, после которого нельзя редактировать свой пост :(
Blumfontein
05.09.2021 08:34+2Мы на сервере на 16vcpu и 16RAM не стесняемся и ставим до 300 static воркеров. С ОЗУ никогда проблем не было, потому что первым умирает CPU. Понятное дело 300 одновремнных запросов сервер не потащит, но зато бОльшее количество воркеров поможет сгладить некоторый воркер-leak приложения, которые всегда бывают.
pOmelchenko
05.09.2021 10:44+1В конкретно описанном случае решением так же может стать переход на swoole или roadrunner, так как команда laravel подготовила фрэймворк к таким штукам.
ainu
05.09.2021 13:27В этом случае ожидаем статью вида "Я ускорил laravel на RR, поставив 20 воркеров в .rr.yaml вместо 8".
Goodwinnew
05.09.2021 11:04А смысл вообще обращать внимание на оперативную память и минимизировать число воркеров?
Если нормальная виртуалка KVM (или свой реальный железный сервер) - там можно своп сделать на диске на 20-30 гиг (уже как правило NVMe) - при исчерпании оперативки (в пике запросов) всё будет работать, но немного медленнее. И то не сильно - так как часть страниц уже заранее собрана и сервер отдает кэш HTML.
Если OpenVZ - то при исчерпании памяти будет краш (точнее будут выкинуты часть процессов) - но и изначально нет смысла использовать OpenVZ для таких нагруженных приложений, которые хотят одновременно много пользователей.
И как выше правильно написали - "первым умирает CPU" :)
karabanov
05.09.2021 17:38+1Но зачем же текст публиковать в виде картинки? Такой текст нельзя скопировать, нельзя увеличить, нельзя найти встроенным поиском.
Неужели действительно проще сделать скриншот, возможно как-то его обрезать, залить на хостинг и вставить ссылку, нежели чем скопировать и в ставить текст между тегами code?
<?php echo "Example code";
catkaff
06.09.2021 00:28Спасибо за статью. Лично мне она пригодится как то, отчего можно оттолкнуться для своих проектов.
Nnnnoooo
10.09.2021 11:51Т.к. от автора нет ни одного комментария ни в данном обсуждении, ни вообще на хабре, все больше склоняюсь что это еще один из аккаунтов ботнетов для плюсования/минусования.
Nnnnoooo
Мне вот интересно, сейчас 2010 год, когда подобные статьи имели хоть как-то смысл?
Все-таки такая статья с настройкой связки php-fpm + nginx это просто перебор для 2021 года, учитывая что это азы которые администратор обязан знать если он хоть каким-то боком имеет отношение к настройке пхп.
Или статья создана просто чтобы был аккаунт с публикацией?
IgorAlentyev
Бывают же ситуации когда админа нет и сервер настраивает и поддерживает сам разработчик.
Nnnnoooo
Так как раз разработчик и обязан знать эти настройки. И не просто заучить значения, а понимать за что они отвечают и в каких случаях на какие менять.
В других комментах ниже уже писали, что надо смотреть конкретный профиль приложения под нагрузкой а потом уже что-то менять.
Но вот самый простой пример, когда данный конфиг просто не будет работать (даже при условии озвученной в статье конфигурации сервера): если в приложении есть обращения к сторонним веб ресурсам (например какое либо веб апи) или еще какие либо операции которые легко могут занять все воркеры. Даже при небольшом увеличении задержки от внешнего апи, есть шанс полностью приложить все приложение, а сервер будет вообще не загружен. Это не значит что надо ставить динамический пул, это о том что настройки надо менять осознанно исходя из конкретного приложения (иногда даже приходится несколько пхп пулов для одного приложения делать, только чтобы критичные операции работали независимо от некритичных)
IgorAlentyev
Не могу согласиться - работа разработчика в основном заключается в написании кода. За поддержку серверов отвечают другие люди - админы, девопсы.
Nnnnoooo
Нормальный разработчик должен знать принципы как работает сервис на котором выполняется код. почему-то ни у кого не возникает вопросов, что разработчик на ReactPHP обязан знать как запустить и настроить ReactPHP демона и обязан понимать что такое ивентлуп. А вот когда речь о классическом php-fpm — понимание его работы и настройки внезапно не требуется.
Это имеет такое же отношение и к базе данных — разработчик обязан знать хотя бы в базовых понятиях как она работает (что такое индексы, как они работают, когда бывают блокировки и т.д.)
Надеюсь не стоит объяснять что криво написанный код никакой админ не сможет заставить нормально работать.
Но это речь только о нормальном разработчике, джуну на галере конечно это не надо.
К тому же у меня был ответ на это заявление:
В этом случае тем более разработчик обязан знать как настраивать и понимать что он делает. А не использовать такие "полезные" туториалы.
P.S. Здесь речь именно о связки php-fpm + nginx (другие языки, другой деплой, могут быть свои нюансы)
mSnus
Фрилансерам это очень полезно. У них нет толпы девопсов и админов.. да и лучше быть грамотным, даже когда они есть
Reshat
Примерно с этого момента начинаются отличия кодера от инженера программного обеспечения.
a0fs
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
027
Весной 2020 столкнулся с этой проблемой, когда студентов стали массово переводить на дистант. До этого у нас крутилась СДО Moodle на обычной VPS-ке средней паршивости (KVM / 6 Core / 4G), параллельно с основным сайтом, и каши не просила. На ней сидели какое-то курсы повышения и прочей переподготовки с малочисленными контингентами.
По мере аврального выкатывания все новых курсов, уже для основной массы студентов, пришлось пройти последовательные стадии перехода:
* bare metal (16 Core Xeon/ 16G);
* два облачных сервера (32 Core / 32G каждый, один под nginx + php-fpm, другой под mysql);
* уменьшение ресурсов до 24 Core / 16G и 8 Core / 24G по результатам трехмесячного мониторинга.
Типичная нагрузка в рабочее время ≈100 запросов в секунду, в пиках до 300 и более. 2300 студентов. Какой-никакой, но хайлоад.
Толкового и комплексного ликбеза рунете не нашел. Да и в буржуйнете тоже (правда, там не особо искал). По мере вылезания разнообразных ошибок и отказов находил разрозненные заметки и крутил настройки, сверяясь с мануалами. Дефолтные настройки под такую нагрузку не годятся категорически!
Настраивать пришлось буквально всё: nginx, php, memcached, mysql и параметры ядра linux. Возникала, было, мысль написать статейку на хабр в помощь таким же бедолагам, да так и ушла. И от банальной непроходящей усталости от работы (мне этот мудль сбоку припека, админить пришлось просто потому, что больше некому. И от атмосферы на нынешнем хабре — администрация такой контент безразличен, сообщество же активно хейтит.
Взять хотя бы этот пост: «разработчик должен знать! девопс должен знать! админ должен уметь это и намного больше!» — а откуда он должен все это познать, скромно умалчивается. Ну написал бы сам статью, раз такой крутой профессионал — но нет, одни пустые поучения: «обратитесь к специалисту», «работу должен делать профессионал». Спасибо, хоть, не «вон из профессии!»
Провинциальный бюджетный вуз, какие там крутые *nix-админы и девопсы… Сисадмин у нас классический мышевоз-виндузятник, ничем помочь не мог. Нанять кого-то со стороны вне штатного расписания — величайший геморрой с бюрократией. Да и найди еще такого, не говоря уж, чтобы заинтересовать. В общем, сам себе сисадмин, крутись, как хочешь.
027
P.S. Скажу еще, положа руку на сердце: ничего такого запредельно сложного для пользователя линукса со стажем в этой работе не оказалось. Трудность заключалась именно в отсутствии комплексного howto «как настроить вебсервер под внезапно подскочившую нагрузку» в условиях цейтнота.
Nnnnoooo
А вот скажите, а чем бы данная статья помогла в вашем случае?
ничем
027
В моем случае — ничем. Но эта статья и не для подобных тяжелых случаев.
Согласен, статья слабенькая, но зачем же автора ругать? Он хотя бы старался помочь таким, как он.
Ни вы, ни я ничего такого не сделали.
Nnnnoooo
Так это же медвежья услуга!
Вот еще раз повторюсь — это НИКАК не поможет новичкам, они просто скопируют все для своей вдски и угадайте что получится? Почему вдски — потому что именно с них начинают новички
bondeg
Почему никак? Довольно подробно расписано что и почему сделано, с примером. Новичку как раз самое то. А не сухое "ну вот тут поставим 42, потому что так будет хорошо".
Nnnnoooo
уже в комментах несколько расписали что не так со статьей:
И самая большая проблема, что эта статья будет забивать поисковую выдачу того же гугла, потому что во превых статья новая, а во вторых с трастового ресурса (с хабра). И в результате от статьи будет больше вреда чем пользы именно для новичков.
А и еще, если бы автор хотел он бы уже добавил уточнения в статью, но считает что и так все норм, значит цель была просто сделать акк со статьей на хабре и не важно каким именно материалом.
Nnnnoooo
А не может быть одинакового howto ответа для разных приложений.
Вам не кажется что именно в этом была проблема, а не в отсутствии howto?
027
Мне ничего не кажется, я просто знаю. Проблем в моем конкретном случае несколько, но ни к хабру, ни к теме howto по хайлоаду они не относятся.
Nnnnoooo
Тогда это будет уже не howto, а целая книга по администрированию, мониторингу и отладке приложений :)
Общие рекомендации конечно можно кратко расписать, но всегда есть нюансы, описание которых будет в разы больше основы.
027
В 2-3 раза больше, чем краткие рекомендации, это небольшая статья, а вовсе не книга. Раз в десять, может быть, больше, чем этот совсем коротенький пост. Что вы мне рассказываете, я такую статью обдумывал и даже черновички накидал по своим запискам.
(off)
А что за шняга с временем на редактирование — в этом свеженаписанном каменте остаток времени меньше 15 минут? Было же 30 раньше.
Проверил в другой статье — там 30 минут дается.
Nnnnoooo
Это результат последних обновлений на хабре :(
027
Черт его знает, пишу в старом интерфейса с компа. Новый, который с мобильного переделан, невыносимо кривой и тормозной.
Спасибо jarvis394 за его проект «habra.», там читать намного комфортнее.
vanxant
Лучше такие статьи, чем гуглопереводы разного шлака
Nnnnoooo
Ну это уже какая-то аксиома Эскобара получается.
Mozhaiskiy
А вот я с вами поспорю. Условный "хабр 2010" — это обилие дискуссий, руководств, методичек по настройкам, тонны объяснений азов (зачастую, не вполне правильных). Добрая часть ссылок на технические запросы гугла ведёт именно на те золотые посты. Но теперь ТЕ молодые люди, которые ТОГДА сидели на хабре, выросли и стали теперь мочить всё, что не укладывается в их идеальный мир узкого специалиста в крупной компании.
Реально, какую статью не напишут — 100% будут волны хейта, что "так не делают", что "это азы", что "для этого нужен отдельный специалист в команде". В итоге Хабр скатился до тупого перевода новостей и ретро-воспоминаний, по факту перестав публиковать новые посты-инструкции на актуальные темы, поскольку не получает минусов и хейта только тот, кто ничего "опасного" не пишет.
Блин, чуваки, вы тоже были молодыми и невежественными. Вы тоже делали конфиги копипастой из чужих мануалов. Давайте вообразим, что в условном 2005-2010-м все ваши проекты будут хейтить условные дяди, у которых 100500 сертификатов от IBM и Microsoft, и которые будут писать, что ваши велосипеды никому не нужны, что есть крупные команды и готовые библиотеки, что не надо лезть сюда со своим невежеством. Вы выросли, и стали считать, что весь мир вырос, поумнел и потяжелел вместе с вами, но это не так. Простите, но это называется страшным словом "старость".
Вокруг вас тысячи инди-разработчиков, которые тянут свои проекты в одиночку. Вокруг куча народу пишет на PHP и сидит на Windows. Люди не рождаются со знанием Linux и Golang и не попадают после детского сада сразу в фирму с 300 разработчиками. Но Хабр стал таким, что эти люди боятся постить статьи со своим опытом. Боятся, что их захейтит токсичное комьюнити. Не даром говорят: спроси на английском на Stackoverflow — получишь ответ и пример. Спроси на русском на тостере — услышишь, что ты м*дак и руки у тебя из ж**ы и так вообще в 2021-м не делают. У меня иногда ощущение, что вместо российского IT-комьюнити я попадаю в какую-то советскую школу, где нужно помалкивать и уметь держать удар, чтобы тебя не заклевали.
Nnnnoooo
На старом хабре такие статьи уходили в глубокий минус. И причина довольно банальна — довольно низкий технический уровень.
Здесь объективно довольно убогая инструкция, без объяснения того зачем это надо и без описания нюансов. И написано в стиле — делай именно так. И рассчитана на дальнейший копипаст. А зачем, почему и вообще будет ли это работать — это уже не важно.
Но, например статья по типу — берем такой-то хостинг (например бесплатный оракл клауд), такой-то конфиг и настраиваем вдс-ку для какого-то типичного пхп приложения. Т.е. настраиваем все, включая базу, пхп и т.д. С комментариями где что подкрутить в зависимости от нагрузки (ну вдс-ка ведь имеет ограниченные ресурсы и везде компромиссы) Такой вариант мануала был бы полезен как раз для новичков. Но не данная статья.
А данная статья кроме того что имеет очень низкий технический уровень, еще и в девопс хабе… ну просто нет слов.
Mozhaiskiy
Дорогой, а вы понимаете, что после фраз "убогая инструкция" и "довольно низкий технический уровень" человек, скорее всего, больше ничего постить на Хабре не будет?
В "том самом 2010-м" в комментах было бы "классная статья, но я бы сделал ещё так.." и "а добавь ещё вот это, а то маловато", "спасибо, сохранил" и "поправлю неточность". Да, это инфантильно, но это мотивирует людей развиваться, писать дальше и сеет добро. Он статью прислал, блин, не в Science, не в Nature и не в ВАКовский журнал, чтобы ему накидали разгромной критики, а в соцсеть. Даже в комментах Попову про Bolgenos люди когда-то умудрялись писать, что "молодец, мало кто в твоём возрасте может сделать сборку, но так не делают, это стыдно".
Вы реально в 2021-м хотите от Хабра уровня рецензируемого профессионального издания, где статья должна исходить от человека с опытом, с заслугами и не содержать скользких мест? А куда людям постить свои девелоперские опыты, где это обсуждать и как получать нетоксичную критику? Хабр был именно таким. Откройте любой пост лет 12-15 назад, да там половина постов уровня "как настроить PHP в Windows", половина комментов — смайлики от друзей, которые друг другу понавыдавали инвайтов. А сейчас даже RSND и VC стали дружелюбней для разработчика, чем "главный профессиональный ресурс рунета".
Мыль моя такая: с требованием материалов только высокого качества убивается и среда, в которой люди растут, не боятся пробовать и учиться. Добрее надо быть к людям.
Nnnnoooo
Не нужен уровень профессионального издания, но статья даже не пересказывающая правильно мануал для файла настроек php-fpm — это перебор. Зато куча картинок. Еще бы видосик — было бы вообще в тренде.
В последнее время пошел тренд — не важно какой херь творишь, но ни в коем случае нельзя критиковать. Ведь старается человек, это главное, а то что результат сомнительного качества — это уже не важно. Но это порочная практика в технических специальностях и плохо если вы этого не видите.
Mozhaiskiy
Я это как раз вижу и не вполне согласен с трендом выращивания снежинок. Но я хорошо помню и "тот хабр", где чуши было в разы больше, чем сейчас, но там была жизнь и энергия. А сейчас тут холодно, неуютно и сплошные переводы новостей.
Nnnnoooo
То что сейчас хабр это площадка коммерсов и журналистов копирайтеров — это следствие политики администрации хабра. И данная статья никак не может улучшить эту ситуацию, вернее она только ее подтверждает — формально это рерайт перевод c английского из внутренностей php-fpm.conf. То что было добавлено куча бесполезных скриншотов, не делает эту статью лучше. Т.е. от данной сттьи на хабре теплее не станет.
И еще судя по тому что автору не интересно участвовать в обсуждении, еще раз показывает что ему главное было сделать аккаунт со статьей и все, а что в статье и какого она качества — не важно.
OnYourLips
Сейчас, в 2021 после девопс-революции, это должен знать именно разработчик, а не админ. Потому что именно разработчик формирует результат своей работы в виде контейнера.