Привет. 

Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.

Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm. 

Я хочу поднять простое приложение с Laravel проектом, которое устанавливается со всеми параметрами по умолчанию. Попробуем это приложение нагрузить пользователями с помощью простого Javascript скрипта и посмотрим как ему удастся справиться с нагрузкой и как мы можем повысить обрабатываемую нагрузку только конфигурированием php-fpm. В конце статьи можно будет найти ссылку на GitHub и попробовать своими руками.

Для начала посмотрим на стандартную конфигурацию php-fpm и попытаемся понять где могут быть проблемы в производительности с коробки.

Итак, у меня есть простое приложение на PHP с NGINX и PHP-FPM предустановленными в стандартных конфигурациях и маршрут Laravel.

Я тимлид вот уже десять лет. И год назад я получил предложение о работе, которое звучало как очень интересный вызов. Но вместе с тем меня терзали сомнения, поскольку был разгар пандемии и я понятия не имел, как стать лидером для новой команды в условиях удаленки. Не добавляли уверенности в успехе новый для меня стек и длинная, 20-летняя история проекта.

Но факторы в пользу успеха тоже были. Во-первых, предыдущий тимлид остается, вернувшись в роль разработчика. Во-вторых, по отзывам, в компании отлаженные и очень “человечные” процессы.

Поразмышляв, я сделал этот прыжок, и в данной статье поделюсь полученным опытом. Душераздирающей истории здесь не будет. Статья задумана как полезная, и, надеюсь, такой она и получилась.

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

Да, я понимаю, что уже 2021-й год, и многие уже сами во всём разобрались. Но практика показывает, что это успешно удалось не стольким, скольким хотелось бы.

Всё это я проговаривал в подкасте Кода Кода.

Однако я уверен, что есть такие люди, которым не хочется полчаса слушать подкаст, а хочется за 5-10 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде на то, что он найдет своего заинтересованного читателя

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

Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.

На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.

Введение

Источник всех утверждений статьи взят из данной видео-конференции Левика. В ней язык живой, а не "доклад под бумажку". Не поленитесь послушать, чтобы заранее не писать глупости (про теорию заговора и аргессивного продвижения).

Независимо от того, сколько вложений компании-разработчики могут потратить на инструментарий и обучение своих разработчиков, «C++, по своей сути, не является безопасным языком», сказал Райан Левик (Ryan Levick) 'cloud developer advocate' из Microsoft на виртуальной конференции AllThingsOpen в прошлом месяце, объясняя в виртуальной беседе почему Microsoft постепенно переходит с C/C++ на Rust для создания своего инфраструктурного программного обеспечения. И вдохновляет других гигантов индустрии программного обеспечения задуматься о том же.

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.