Долгое время я делал все свои побочные проекты с помощью специально созданного PHP-фреймворка (или, скорее, набора библиотек). В начале моего путешествия по PHP (в 2011 году) написание этих библиотек было хорошим упражнением в изучении языка. Однако в последнее время я начал сталкиваться со всевозможными ограничениями:
- проблемы безопасности
- постоянная потребность в исправлении для крайних случаев
- создание простой функциональности вместо того, чтобы сосредоточиться на создании продукта
Единственными фреймворками, с которыми я работал раньше, были Zend Framework 1 и Symfony 5.
В моем предыдущем проекте у меня был непосредственный опыт запуска веб-сайта с относительно высокой нагрузкой. Самый высокий уровень трафика, который я видел, составлял 10 миллионов просмотров страниц в день и до 10 000 одновременных сеансов. В бэкэнде у нас было 7 веб-узлов, обслуживающих PHP-запросы (Linux, Nginx+php-fpm, MySQL, MongoDB, PHP 7, Memcache). И застрять с Zend Framework 1 было совсем не весело:)
Другой, Symfony 5, я пробовал для небольшого проекта в течение месяца и оставил его с ощущением, что за сценой происходит слишком много волшебства, на мой вкус. И кривая обучения была довольно крутой.
Поэтому я решил взглянуть на текущую сцену PHP-фреймворков, чтобы почувствовать всех и проверить производительность (на случай, если мне посчастливится снова получить высокий трафик).
Вот список Я выбрал, что тестировать.
Цель
Я хочу ответить на следующие вопросы:
- Сколько запросов может последовательно обслуживать платформа на дешевом VPS?
- Каковы затраты на производительность при использовании фреймворка по сравнению с обычным PHP или самописным набором библиотек или даже простым HTML?
Результаты
Сколько простых HTTP-запросов может последовательно обслуживать фреймворк на сравнительно дешевой цифровой капле океана (40 долларов, выделенный процессор, 2 ядра, 4 ГБ памяти)?
| HTML | 77 | 982127520 | 11367 |
| PHP 7.2.24 | 77 | 224406720 | 2597 |
| Без жира 3.7.0 | 78 | 182544480 | 2113 |
| Фалкон 3.4.5 | 78 | 182409120 | 2111 |
| Тонкий 4.3.0 | 79 | 133248960 | 1542 |
| Yii 2.0.26 | 79 | 108002880 | 1250 |
| Тонкий (скелет) 4.3.0 | 80 | 100347840 | 1161 |
| Симфония 5.0.1 | 82 | 34727040 | 402 |
| Ларавель 5.8.35 | 83 | 28455840 | 329 |
| Laravel 6.5.2 Ларавель 6.5.2 | 85 | 27502560 | 318 |
| CakePHP 3.8.6 | 83 | 15973920 | 185 |
| CodeIgniter 4.0.0-rc3 | 89 | 14906880 | 173 |
| Зенд (скелет) 3.1.13 | 87 | 9365760 | 108 |
Установка
- 2 сервера: “Веб” (регион SF1) и “Клиент” (регион NYC1)
- Nginx 1.14.0, PHP 7.2.24 (Php-fpm), Ubuntu 18.04.3.
- Оба сервера принимают соединения только друг от друга через HTTP
- Сервер “Клиент” открывает соединение с сервером “Web” с помощью wrk (версия 4.1.0), добавляя еще 1 соединение каждые 10 секунд.
- Использование PHP “Веб” сервера ограничено 50% (подробнее об этом позже)
Правила
Тестирование фреймворков PHP сложно, потому что есть много возможностей для изучения: шаблонизаторы, ORM, кэширование… На данный момент я решаю протестировать простой ответ “Привет, мир!” с помощью PHP. Я предполагаю, что это идеальная установка для тестирования накладных расходов на производительность различных фреймворков – способ проверить стоимость “взлета” фреймворка.
- Тестовый пример представляет собой простой текст “Привет, мир!” ответ
- Так никаких шаблонизаторов
- Без Оружия
- Никаких контроллеров (если возможно)
- Нет различий между уровнями сложности фреймворков (микро, полный стек)
- Я стараюсь оптимизировать каждую платформу в соответствии с разделом документации “Развертывание”, если таковой имеется. Обычно он запускает “composer install –optimize-автозагрузчик –no-dev” и запускает команду фреймворков для кэширования конфигурации
Меня интересует, сколько HTTP-запросов фреймворк может последовательно обслуживать:
- Без значительного увеличения задержки (<10%)
- Без ошибок (тайм-ауты, ошибки подключения)
- Использование не более 50% процессора сервера
Примечание о производительности фреймворков, процессоре, памяти
Неинтуитивный факт о фреймворках заключается в том, что каждый из них может обслуживать примерно равное количество запросов с примерно одинаковой задержкой.
Позвольте мне повторить это: в идеальном мире с бесконечным количеством вычислительных ресурсов все фреймворки работают почти одинаково.
Дело не в том, что одна структура по своей сути медленнее другой. Некоторые фреймворки работают медленнее только потому, что они потребляют больше процессора или памяти или выполняют больше операций чтения с диска или базы данных.
Исходя из моего опыта работы с сайтами с высоким трафиком, когда мы имеем дело с запуском php-fpm + Nginx, обычно нам следует беспокоиться о процессоре, а не о памяти. Если мы возьмем пример конфигурации с 1 ядром процессора и 4 ГБ памяти, php-fpm + Nginx может легко потреблять 100% процессора при использовании менее 5% памяти.
Вот почему я выбираю DigitalOcean droplet стоимостью 40 долларов: он самый дешевый с выделенным, а не общим процессором.
В реальной жизни мы не хотим максимизировать производительность процессоров. Это приводит к увеличению времени отклика сервера (латентности), что ужасно. И это не оставляет нам никакого запаса для всплесков трафика, что неправильно. Обычно для производственных веб-узлов рекомендуется оставаться значительно ниже 50% от лимита ЦП.
Для этого теста я решил ограничить использование PHP на “Веб” сервере до 50%.
Отношение
Я не подразумеваю, что фреймворки, которые работают медленнее, хуже:
- Как показывают результаты, если вы обслуживаете менее 10 000 000 просмотров страниц в день, вы можете использовать любую платформу.
- Часто это компромисс: чем быстрее создать что-то на основе фреймворка, тем больше синтаксического сахара, тем больше функций, тем сложнее – тем медленнее.
Наблюдения
Ларавель
Laravel – единственный фреймворк, который был смехотворно медленным и подверженным ошибкам из коробки. Я не мог заставить его обслуживать даже 10 запросов в секунду без множественных ошибок тайм-аута и задержки, мгновенно превышающей 100 мс.
Затем я просмотрел медленный журнал и обнаружил, что у Laravel возникли некоторые проблемы с обработкой сеансов (конечно, папки сеансов имели все необходимые права и назначенные им пользователи/группы).
После изменения значений конфигурации для SESSION_DRIVER с “файл” на “массив” производительность Laravel увеличилась в 10 раз.
Может быть, я пропустил там что-то важное, поэтому, пожалуйста, дайте мне знать, если это так.
Фалькон
Фалкон – это зверь. Это единственный фреймворк, который поставляется в виде расширения Zephyr/C. И в некоторых случаях это быстрее, чем обычный PHP.
Без жира
Единственная структура, которую я не смог создать, чтобы принимать запросы с завершающей косой чертой (например, http://domain.com/fatfree/ ). Только http://domain.com/fatfree сработало.
Оригинал: “https://dev.to/pixelbot/php-frameworks-test-249g”