Привет.
Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.
Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm.
Привет.
Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.
Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm.
class Number {
private int|float $number;
public function setNumber(int|float $number): void {
$this->number = $number;
}
public function getNumber(): int|float {
return $this->number;
}
}
В одном из выпусков подкаста "Цинковый прод" мы мельком обсуждали, что нового будет в языке PHP8. После записи я решил написать статью, чтобы сформулировать свои мысли по положению PHP в современной разработке.
Давайте определимся в целом, какую нишу занимал/занимает язык, и куда он движется
Изначально язык позиционировался как простой инструмент, в котором из коробки есть всё необходимое для web.
С одной стороны, это действительно так: без дополнительных библиотек можно, например, вытащить из суперглобальной переменной $_POST параметры POST-запроса и вставить их в mysql с помощью встроенных функций, и это вроде как здорово.
Также очень важно, что модель "рожден, чтобы умереть" (например, в php-fpm) упрощала и упрощает разработку до безумия: не нужно знать, что такое локи, дедлоки, утечки памяти и т.д. Не надо писать await перед каждой строкой кода и т.д.
Скрипт начал работать над входящим HTTP-запросом, поработал в отдельном процессе, ни с кем не общаясь, и сдох, очистив все после себя. Очень просто программировать. Порог входа — около нуля.
Опять же, можно обойтись без роутинга: имя файла — это уже описание роутов.
С другой стороны, увы, есть нюансы. Веб не стал ждать и ушел далеко вперед.
Десять лет назад у нас был классический LAMP-стек: Linux, Apache, MySQL, и PHP, который работал в медленном режиме mod_php. Мир менялся, а с ним и важность скорости. Появился PHP-FPM, который позволил значительно увеличить производительность решений на PHP, а не срочно переписывать на чем-то побыстрее.
Параллельно велась разработка библиотеки ReactPHP с применением концепции Event Loop для обработки сигналов от ОС и представления результатов для асинхронных операций. Развитие идеи ReactPHP — AMPHP. Эта библиотека использует тот же Event Loop, но поддерживает корутины, в отличие от ReactPHP. Они позволяют писать асинхронный код, который выглядит как синхронный. Возможно, это самый актуальный фреймворк для разработки асинхронных приложений на PHP.
Но скорости требуется всё больше и больше, инструментов уже не хватает, поэтому идея асинхронного программирования в PHP — одна из возможностей ускорить обработку запросов и лучше утилизировать ресурсы.
Об этом и поговорит Антон Шабовта (zloyusr) — разработчик в компании Onliner. Опыт больше 10 лет: начинал с десктопных приложений на С/С++, а потом перешел в веб-разработку на PHP. «Домашние» проекты пишет на C# и Python 3, а в PHP экспериментирует с DDD, CQRS, Event Sourcing, Async Multitasking.
Читать полностью »
Скорее всего, рассказывать, что такое вебхуки (webhooks) — никому не нужно. Но на всякий случай: вебхуки — это механизм оповещения о событиях во внешней системе. Например, о покупке в интернет-магазине через онлайн-кассу, отправке кода в GitHub-репозиторий или действиях пользователей в чатах. В типичном API нужно постоянно опрашивать сервер, написал ли пользователь что-нибудь в чате. С помощью механизма вебхуков можно «подписаться» на оповещения, и сервер сам отправит HTTP-запрос, когда произойдет событие. Это удобнее и быстрее, чем постоянно запрашивать новые данные на сервере.
ManyChat — это платформа, которая помогает бизнесу общаться со своими клиентами через чаты в мессенджерах. Вебхуки — одна из важных частей ManyChat, потому что именно через них бизнес общается с клиентами. А общаются они много — например, через систему бизнесы отправляют своим клиентам миллиарды сообщений в месяц.
Основная масса сообщений отправляется через Facebook Messenger. У него есть особенность — медленный API. Когда клиент пишет сообщение, чтобы заказать пиццу, Facebook отправляет в ManyChat вебхук. Платформа его обрабатывает, отправляет запрос обратно и пользователь получает сообщение. Из-за медленного API некоторые запросы идут несколько секунд. Но когда платформа долго не отвечает, бизнес теряет клиента, а Facebook может отключить приложение от вебхуков.
Поэтому обработка вебхуков — это одна из главных инженерных задач платформы. Чтобы решить проблему, в ManyChat за три года работы несколько раз меняли архитектуру обработки с простого контроллера в Yii до распределенной системы с «Галактиками». Подробнее об этом под катом расскажет Дмитрий Кушников (cancellarius).
Читать полностью »
Всем привет!
Меня зовут Михаил Мазеин, я — ментор Backend community ManyChat. 5 декабря в нашем офисе пройдёт первый Backend Meetup.
В этот раз мы поговорим не только про разработку на PHP, но и затронем тему использования баз данных.
Начнём с истории про выбор инструментов для вычисления математических формул. Продолжим фундаментальной темой выбора подходящей базы данных. А закончим встречу большим докладом о тюнинге сервера высоконагруженного проекта с помощью тонкой конфигурации nginx и php-fpm на основе данных о движениях запросов вместо постоянного увеличения количества серверов.
Участников ждут доклады от инженеров ManyChat и, конечно, общение. Встречать гостей будем в 18:30, а начнем митап в 19:00. Регистрация доступна по ссылке, а подробная программа мероприятия — под катом.
Читать полностью »
Не так давно тимлид нашей команды сказал: ребята я хочу, чтобы у всех была одинаковая среда разработки для наших боевых проектов + мы должны уметь дебажить всё — и web приложения, и api запросы, и консольные скрипты, чтобы экономить свои нервы и время. И поможет нам в этом docker.
Сказано — сделано. Подробности под катом.
Читать полностью »
Привет!
Мы часто пишем и говорим о производительности PHP: как мы ей занимаемся в целом, как мы сэкономили 1 млн долларов при переходе на PHP 7.0, а также переводим разные материалы на эту тему. Это вызвано тем, что аудитория наших продуктов растёт, а масштабирование PHP-бэкенда при помощи железа сопряжено со значительными затратами — у нас 600 серверов с PHP-FPM. Поэтому инвестирование времени в оптимизацию для нас выгодно.
Прежде мы говорили в основном об обычных и уже устоявшихся способах работы с производительностью. Но сообщество PHP не дремлет! В PHP 8 появится JIT, в PHP 7.4 — preload, а за пределами core-разработки PHP развиваются фреймворки, подразумевающие работу PHP как демона. Пора поэкспериментировать с чем-то новым и посмотреть, что это может нам дать.
Так как до релиза PHP 8 ещё далеко, а асинхронные фреймворки плохо подходят для наших задач (почему — расскажу ниже), сегодня остановимся на preload, который появится в PHP 7.4, и фреймворке для демонизации PHP — RoadRunner.
Это текстовая версия моего доклада с Badoo PHP Meetup #3. Видео всех выступлений мы собрали в этом посте.Читать полностью »
Холдинг Modesco — это более 300 инфосайтов и 5 крупных Интернет-сервисов. Проекты регулярно покупаются и продаются. Как вы понимаете, поддерживать качество кода на высоком уровне в данной ситуации физически невозможно. Да и основное внимание программистов, как правило, сосредоточено на самих сервисах. Взломы, shell, заражения сайтов прочими вредоносными штуками… Все это наносит ощутимый вред пользователям и компании. Чтобы избежать этого, частенько приходится искать довольно нестандартные способы для уменьшения рисков.
Всем привет!
Я Павел Мурзаков, тимлид серверной команды Badoo. Мы обожаем PHP, вкладываемся в его развитие и развитие сообщества вокруг него. 21 сентября планируем провести третий Badoo PHP Meetup. Приглашаем спикеров и гостей!
В этот раз в качестве общей темы встречи выбрали производительность PHP-кода и PHP-бэкенда в целом. Для нас эта область важна, так как, с одной стороны, у нас большая инфраструктура на PHP, и вопрос производительности — это вопрос экономии денег. С другой — нам важно предоставлять пользователям сервис высокого качества, поэтому бэкенд должен отвечать достаточно быстро, ведь от этого зависит активность пользователей и их впечатления от сервиса.
На митапе хотим обсудить, как решают подобные вопросы в разных компаниях, а именно: как следить за производительностью, профилировать и локализовывать проблемы, когда и что стоит оптимизировать и как это делать.
Регистрация по ссылке, начало в 12:00, гостей встречаем с 11:00.
Читать полностью »
Так уж случилось, что нужно мне было где-то хранить более 1.5тб данных, да еще и обеспечить возможность скачивания их обычными пользователями по прямой ссылке. Поскольку традиционно такие объемы памяти идут уже на VDS, стоимость аренды которых не слишком вкладывается в бюджет проекта из категории «от нечего делать», а из исходных данных у меня был VPS 400GB SSD, куда при всем желании 1.5тб картинок без loseless сжатия поместить не удастся.