Разбираемся с opcache

ОЧИСТИТЕ OPCACHE С ПОМОЩЬЮ WP ROCKET

Когда вы изменили код PHP или добавили новые сценарии, вам может потребоваться очистить кеш кода операции на своем веб-сайте. Хотя вы можете сделать это через терминал, WP Rocket имеет встроенную опцию, позволяющую сделать это одним нажатием кнопки.

Для этого перейдите в « Настройки»> «WP Rocket» на панели администратора WordPress и нажмите кнопку « ОЧИСТИТЬ OPCACHE» .

Простая очистка OPcache с помощью WP Rocket

Если у вас нет этой опции на панели настроек WP Rocket, значит, либо ваш сервер не настроен для использования OPcache, либо хост отключил очистку OPcache через API, добавив директиву opcache.restrict_api в php.ini файл. Вы можете прочитать больше об этой функции в документации WP Rocket .

Установка и настройка Memcache:

Модуль Memcached для PHP доступен в репозитории уже скомпилированным (php5-memcached), но я опишу процесс установки из исходного кода, так как не все репозитории настолько богаты, как дебиановский.

Устанавливаем сервер Memcached:

#apt-get install memcached

Для начала, хватит следующих правок конфигурационного файла:

#/etc/memcached.conf

Memcached будет работать, как демон:

-d

Путь для лога:

logfile /var/log/memcached.log

Отведём 256 мегабайт ОЗУ под хранилище:

-m 256 <code>
<code | Слушать будет этот порт:>
-p 11211

В последствии желательно поменять:

-u nobody

Слушаем localhost:

-l 127.0.0.1

Перезапускаем memcache

 #/etc/init.d/memcached restart
# max connection 2048 MAXCONN="2048" # set ram size to 2048 - 2GiB CACHESIZE="4096

Далее проверяем, запустился ли memcached:

# netstat -tap | grep memcached

В случае успеха, получим результат:

tcp 0 0 localhost:11211 *:* LISTEN 13036/memcached

Компилируем и устанавливаем модуль для PHP:

apt-get install php5-memcached
apt-get install php5-dev libmemcache-dev
pecl download memcache
tar xzvf memcache-2.2.6.tgz
cd memcache-2.2.6/
phpize && ./configure --enable-memcache && make
cp modules/memcache.so /usr/lib/php5/20060613/
echo 'extension=memcache.so' >> /etc/php5/apache2/php.ini
/etc/init.d/apache2 restart

При перезапуске memcached весь кэш теряется.

Настройки memcached:

STAT maxbytes 134217728
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT inter 127.0.0.1
STAT verbosity 0
STAT oldest 0
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol auto-negotiate
STAT auth_enabled_sasl no
STAT item_size_max 1048576

Актуальность: 2015/01/26 10:35

Существующие акселераторы PHP

Для PHP версий 5.3, 5.4 актуальны следующие акселераторы:

APC — Alternative PHP Cache. Бесплатный и открытый opcode кэшер для PHP. Поддерживает PHP4 и PHP5, включая 5.3 и 5.4.
eAccelerator. Свободный открытый проект, выполняющий роли акселератора, оптимизатора и распаковщика. Поддерживает PHP4 и PHP5, включая 5.4
PhpExpress. Бесплатный ускоритель обработки php-скриптов на веб-сервере. Поддерживает PHP4 и PHP5, включая 5.3
XCache. Бесплатный. Поддерживает функции оптимизации скриптов, кэширования байткода. Поддерживает PHP4 и PHP5, включая 5.6
Zend OPcache. Обеспечивает более быстрое выполнение PHP кода операции через кэширование и оптимизации. Улучшает PHP производительность, сохраняя скомпилированные сценариев байт-кода в разделяемой памяти. Zend OPcache включен в PHP 5.5 по умолчанию. Как расширение PECL поддерживает версии 5.2, 5.3 и 5.4.

Если вы используете PHP 5.5, то в нем по-умолчанию идет Zend OPcache и ничего дополнительно ставить не нужно.
В сети полно тестов и сравнений различных акселераторов. Но в данной статье я не буду их приводить.

Ускорение работы Apache изменениями во время выполнения

Чтобы повысить производительность сервера, нужно регулярно измерять производительность и осуществлять тонкую настройку конфигурации. Наиболее важные параметры, которые нужно оптимизировать:

Поиск DNS

Apache может тратить время на определение хоста каждого IP, с которого приходит запрос. Это замедляет обработку запроса, а также приводит к пустой трате ресурсов. Чтобы избежать этого, нужно отключить опцию HostnameLookups.

При настройке директив Allow from или Deny from используйте IP-адреса вместо доменных имён. Иначе будет осуществляться двойной поиск имени DNS, который уменьшит производительность сервера.

Настройка AllowOverride

Если задана опция AllowOverride, то Apache попытается открыть файл .htaccess в каждой папке, которую он посещает. Эти дополнительные запросы к файловой системе увеличивают время отправки ответа с сервера.

Поэтому лучше отключить эту опцию. Если переопределение настроек в файлах .htaccess необходимо в определённой папке, нужно разрешить это только для данного каталога.

Настройки FollowSymLinks и SymLinksIfOwnerMatch

Настройка Apache FollowSymLinks сообщает серверу, что нужно проверять символические ссылки и проходить по ним. Если она имеет значение Off, Apache придётся выполнять дополнительные проверки, что замедлит его работу.

Если установлена директива SymLinksIfOwnerMatch, сервер будет проходить по символическим ссылкам, только если владелец целевого файла тот же, что и владелец ссылки. Это также влияет на скорость работы Apache.

Лучше всего активировать директиву FollowSymLinks и выключить директиву ‘SymLinksIfOwnerMatch’. Но это может привести к проблемам с безопасностью, поэтому окончательное решение остается за вами.

Согласование содержимого (Content Negotiation)

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

Если согласование содержимого необходимо для сайта, можно снизить задержки, используя файлы type-map вместо директивы Options MultiViews. Ее применение увеличивает задержку.

Настройка MaxClients

Настройка MaxClients устанавливает лимит количества одновременных запросов, которое может поддерживаться Apache. Если это значение слишком мало, запросы станут в очередь, и не будут обрабатываться.

Большое значение параметра может загрузить оперативную память и повлиять на скорость ответов Apache. Необходимо выбрать оптимально значение исходя из объёма доступной памяти и ресурсов, потребляемых процессом.

Настройки MinSpareServers, MaxSpareServers и StartServers

MaxSpareServers и MinSpareServers определяют количество дочерних процессов, которые будут находиться в состоянии ожидания обработки запросов. Эти параметры важны, потому что создание дочернего процесса отнимает ресурсы.

Если значение MinSpareServers слишком низкое, и на сервер поступает одновременно несколько запросов, Apache создаст дополнительные дочерние процессы. Это снижает возможность быстрого ответа на запрос клиента.

Значение MaxSpareServers не должно быть слишком большим. Так как стоящие в очереди на обработку дочерние процессы потребляют лишние серверные мощности. Нужно установить эти значения в оптимальном диапазоне, чтобы сбалансировать использование ресурсов и производительность.

Директива StartServers устанавливает количество дочерних серверных процессов, которые создаются при старте сервера. Если запросов много, а Apache часто перезагружается, нужно установить относительно большое значение.

Настройка MaxRequestsPerChild

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

Настройка KeepAlive и KeepAliveTimeout

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

KeepAliveTimeout определяет время ожидания следующего запроса. Если значение большое, дочерние процессы могут расходовать ресурсы, ожидая следующего запроса. Оптимальное значение – 2-5 секунд для небольших объемов трафика и 10 секунд для высоконагруженных серверов.

Timeout

Устанавливает время ожидания запроса от посетителя. При больших объемах трафика значение параметра должно быть не менее 120 секунд. Но лучше держать это значение минимальным. Это позволяет предотвратить излишнее расходование ресурсов.

Бенчмарки PHP 8.0 и 7.4 на Symfony: повышение производительности JIT до +9% вместе с предварительной загрузкой OPCache +8

29.12.20 13:30

•
MaxRokatansky
•
#535526
•
Хабрахабр

•
Перевод

•

1800

Программирование, PHP, Symfony, Блог компании OTUS. Онлайн-образование

PHP 8.0 должен увидеть свет 26 ноября 2020 года, а вскоре за ним и последняя версия фреймворка Symfony 5.2. Здесь представлена серия бенчмарков, выполненных на последних версиях обоих проектов. Это чистый hello world сценарий, и его следует воспринимать как таковой. Имеет значение только относительная производительность. В реальном мире YMMV (ваши результаты могут отличаться от приведенных).

Бенчмарки проводились на и Symfony 5.2-RC2. Обе версии не являются окончательными, но это самые последние кандидаты на релиз, которые могут быть очень близки к финальным версиям. Средой выполнения послужил датацентр Hetzner Helsinki с виртуальным сервером CCX11 (2 выделенных виртуальных процессора, 8 ГБ ОЗУ), выполняющим работу, и еще одним для выполнения бенчмарков. В качестве ОС использовалась Ubuntu 20.20 с PHP, установленным из пакетов от Ондржея Сури.

Целью бенчмарка было простое приложение Symfony 5.2 с в корне. Экшн выводит фрагмент HTML со случайным числом от 100 до 999. Я провел нагрузочный тест с пятью параллельными задачами (1, 10, 25, 50, 100) три раза для каждой конфигурации и использовал в отчете среднее значение.

В общей сложности были протестированы пять конфигураций с использованием PHP-FPM и сетапом Nginx:

PHP 7.4 без предварительной загрузки OPCache

PHP 7.4 с предварительной загрузкой OPCache

PHP 8.0 без предварительной загрузки OPCache

PHP 8.0 с предварительной загрузкой OPCache

PHP 8.0 с предварительной загрузкой OPCache и включенным JIT

Такой же конфиг OPCache используется для пост-бенчмаркинга предварительной загрузки OPCache:

Результаты и заключение

Балансировка нагрузки осуществлялась с помощью hey, и я дополнительно привожу показатели пропускной способности (req/s) и время отклика (мс). Приложение не подключается к удаленным службам, таким как базы данных.

Что касается пропускной способности, как PHP 7.4, так и 8.0 значительно выигрывают от включения предварительной загрузки OPCache. В среднем PHP 7.4 немного более производительный, но ненамного. Что касается пропускной способности, похоже, изменений при параллелизме от 10 до 100 нет, но PHP 8.0 с JIT, как ни странно, менее эффективен на небольшом параллелизме, но оживает и превосходит 7.4 с предварительной загрузкой OPCache, начиная с 25+ параллелизма и далее.

Что касается времени отклика, то здесь история аналогична производительности. Включение предварительной загрузки OPCache дает лучшие результаты, чем обновление с PHP 7.4 до 8.0. По времени отклика (чем меньше, тем лучше) PHP 8.0 немного лучше, чем 7.4, но незначительно. Время отклика выше при низком параллелизме, но остается постоянным от 10 до 100. 8.0 с JIT похожа: хуже при низком параллелизме, но лучше при высокой нагрузке.

В целом улучшения базовой производительности для такого приложения, как Symfony, очень похожи между PHP 8.0 и 7.4. Это неудивительно, поскольку известно, что JIT в PHP 8.0, который уже существовал в ранней форме для PHP 7.0, более полезен для вычислений и других задач обработки данных, завязанных на процессоре.

Что касается производительности, JIT здесь выглядит неоднозначно, замедляясь при низком уровне параллелизма и обеспечивая значительное улучшение пропускной способности только с предварительной загрузкой OPCache. Требуется дополнительные исследования, но здесь дело обстоит неясно, так как это может снизить производительность. Кажется, что JIT следует рассматривать в индивидуальном порядке для PHP.

Так что пока можно с уверенностью сказать, что торопиться обновляться с 7.4 до 8.0 из соображений производительности не следует. Будет лучше, если вы обновите PHP 7.3 до 7.4 и включите предварительную загрузку OPCache. Это не значит, что PHP 8.0 в разочаровал нс. Он укомплектован новыми языковыми фичами и важными депрекейшенами. Самое главное, приятно видеть, что не было никаких падений в производительности (как это было при переходе с 4.4 на ). Это отличное начало для 8.x.

Ваши комментарии и отзывы приветствуются на Discourse: бенчмарки PHP 8.0 и 7.4

PHP.ini

Если Вы только установили PHP, убедитесь, что Вы настроили наиболее важные параметры под Ваш сайт. Это также может сэкономить ресурсы:

— не стоит устанавливать этот параметр слишком большим. Увеличивайте его только в крайних случаях.
, — компрессию лучше использовать на стороне Web сервера.
— максимальное время работы скрипта не должно быть больше 5 секунд. Увеличивайте только в крайних случаях.
— включает сборщик мусора (будет оптимизировать память на фоне).
не будет отправлять свою версию вместе с ответом.
— будет отправлять в лог ошибок информацию об обнаруженных утечках памяти.
, — настройте максимальный размер запросов и файлов для загрузки. Защитит от обработки громадных запросов, которых не должно быть в приложении.

Отладка JIT (opcache.jit_debug)

PHP JIT обеспечивает способ выдачи отладочной информации JIT путем установки конфигурации INI. Когда установлен определенный флаг, он выводит код сборки для дальнейшей проверки.

Директива opcache.jit_debug принимает значение битовой маски для включения определенных функций. В настоящее время он принимает значение в диапазоне от 1 (0b1) до 20 двоичных разрядов. Значение 1048576 представляет максимальный уровень вывода отладки.

JIT поддерживает несколько других параметров конфигурации, чтобы настроить, сколько вызовов функций делает ее «горячей» функцией, которая затем компилируется JIT, и порог для определения того, какие функции следует «JIT’ировать», на основе процента общих вызовов функций.

Полный список см. В разделе Конфигурация Opcache.

5 шагов для ускорения работы Apache

Ускорить работу Apache можно на двух основных стадиях:

Во время компиляции – настройки при установке сервера.
Во время выполнения — установка параметров, влияющих на сервер во время его работы.

Настройки для ускорения Apache во время компиляции

Нужно выбирать вариант установки Apache, исходя из ваших требований. Это поможет создать быстрый и эффективный веб-сервер.

Загружайте только нужные модули

В Apache функциональность реализуется путем добавления модулей. Они бывают двух типов: статические и динамические (общие).

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

Статические и динамические модулиключевые различия

Статические модули	Динамические модули
Компилируются в бинарные файлы	Добавляются во время выполнения
Требуют перекомпиляции кода	Перекомпиляция не требуется
Быстро загружаются	Замедляют веб-сервер

Чем больше статических модулей в бинарных файлах, тем быстрее работает веб-сервер. Но они требуют перекомпиляции Apache каждый раз, когда нужно что-то изменить. Из-за этого динамические модули или DSO используются чаще, поскольку они могут быть скомпилированы отдельно и загружены во время выполнения.

Но большое количество динамических или общих модулей может замедлить работу сервера Apache и сайта

Поэтому при выборе модулей требуется соблюдать осторожность

Чтобы увеличить скорость работы и производительность, используйте минимальное количество динамических модулей, поскольку они уменьшают объем доступной памяти.

Выберите правильный MPM

В Apache используются MPM (мульти-процессинговые модули), которые обрабатывают запросы, приходящие на сервер. Они прослушивают сетевые порты сервера, принимая запросы и создавая дочерние процессы.

MPM бывают двух типов: Prefork и Worker. В MPM Prefork каждый процесс httpd обрабатывает один сетевой запрос. Это более безопасно по сравнению с MPM Worker, но требует большего количества памяти и ресурсов.

MPM – Prefork и Worker

MPM Prefork	MPM Worker
Один поток	Несколько потоков
Использует больше ресурсов	Использует меньше памяти
Отказоустойчив	Справляется с большим трафиком

При использовании MPM Worker Apache работает в режиме многопоточного сервера, где каждый отвечает за свой запрос. Этот вариант подходит для обработки большего трафика при ограниченных мощностях сервера.

По умолчанию большинство установок Apache используют модуль Prefork. Он применяется для обработки больших объемов трафика. Вы можете проверить, какой модуль MPM использует ваш сервер при помощи следующей команды:

Определение типа MPM на вашем веб—сервере Apache

В Apache 2.4 появилась поддержка э MPM модуля Event, который может обрабатывать множественные запросы внутри одного потока. Поэтому он работает даже быстрее, чем модуль Worker.

Настройка MySQL / MariaDB server

От правильной настройки MySQL / MariaDB зависит насколько быстро будет работать ваш сервер / сайт. Все, что вы делали раньше может “превратиться в тыкву” если оставить параметры по умолчанию. Настройки mysql можно найти в /etc/mysql/my.cnf. Перед тем как вы будете создавать базы данных или переносить существующие стоит выполнить несколько простых действий:

Решите какой “движок” будет по умолчанию. Если у вас таблицы MyISAM, возможно стоит перейти на Aria, но лучше использовать InnoDB.
Установите последнюю версию MySQL / MariaDB
Отредактируйте /etc/mysql/my.cnf:

Данные параметры оптимальны для VPS с 3 гб оперативной памяти и двумя CPU. Для серверов с большим количеством оперативной памяти и CPU некоторые значения стоит изменить. Если используются NVMe диски то можно включить задокументированные параметры.

Нам осталось только изменить (увеличить) приоритет mysql и увеличить лимит на открытие файлов. Раньше это можно было сделать параметром nice и open_file_limits в my.cnf. В новых версиях это не работает.

Часть настроек теперь находится в /lib/systemd/system/. Отредактируйте файлы mariadb.service и [email protected]:

Проблема настроек SQL server

Это тот самый случай, когда сделали (перенесли настройки), а задокументировать забыли… Вот все и гадают, почему nice или не работает, или вызывает ошибку при запуске сервера БД.

Сохраните и перезапустите systemd:

Не знаю, баг это или фича, но настройки сбрасываются “по умолчанию” после обновления SQL сервера. Так что будьте внимательны.

В идеале, если вы все сделали правильно, mysqltuner должен выдавать вот такую информацию:

Есть полная уверенность в том, что сервер баз данных работает максимально производительно. При этом он очень экономно расходует ресурсы, при этом не нагружая дисковую подсистему, память и процессор.

Кэширование PHP

Особенность интерпретируемых языков в том, что при каждом запуске скрипта интерпретатор должен скомпилировать программу и проверить ее на ошибки. Но мы можем обойти. Есть два основных вида кэширования:

Кэширование готовых страниц — страница генерируется php, а потом пользователю отдается готовая страница без обращения к php. Я расскажу как это сделать через fastcgi, но не рекомендую применять такой метод для wordpress или других движков, их лучше кэшировать с помощью специальных плагинов;
Кэширование байт кода и инструкций — а это уже интересно, кэшируется не вся страница, а только некоторые инструкции, и куски байт кода, которые не изменяются при вызовах скрипта. Перед тем как выполнять скрипт, интерпретатор должен преобразовать его в понятный для него формат, при кэшировании такое преобразование выполняется только первый запуск, а дальше берется версия из кэша;
Кэширование сессий — по умолчанию php сохраняет сессии пользователей в файлы и мы можем немного ускорить его работу, если будем сохранять сессии в оперативную память.

Дальше рассмотрим более подробно, как настроить каждый вид кэширования для вашего сервера. Начнем с кэширования opcode php.

Настройки PHP

Для php нужны следующие настройки, которое мы разберем, и посмотрим, что они означают.

1) Если вы собираетесь устанавливать 1С-Битрикс в кодировке utf-8 (рекомендуется делать именно так), то необходимо, чтобы была указана внутренняя кодировка и перегрузка почтовой и строковых функций (становятся доступны функции с префиксом mb_, например mb_strlen), если же продукт будет установлен в кодировке windows-1251, то эти строки не нужны

mbstring.func_overload=2mbstring.internal_encoding=utf-8

2) Эта строка нужна для прохождения теста на корректность работы 1С-Битрикс (длина регулярных выражений)

pcre.recursion_limit = 1000

3) Кеширование реальных путей скриптов, а также время кеширования в секундах

realpath_cache_size = 4096Krealpath_cache_ttl = 3600

4) Временная зона. В рекомендациях 1С-Битрикс по синхронизации времени указана несколько устаревшая информация, попытка добавлять требуемые строки в файлы настроек системы приводят к неработоспособности продукта, поэтому реально нужна только эта настройка (используйте необходимую именно вам временную зону!) и настройка для базы данных, о чем будет сказано ниже

date.timezone = "Europe/Moscow"

5) Максимальное ограничение на число одновременно передаваемых переменных

max_input_vars = 15000

6) Настоятельно рекомендуется 1С-Битрикс, чтобы вывод ошибок по-умолчанию был включен. Редактировать настройку вывода ошибки и/или предупреждения можно и нужно в настройках главного модуля 1С-Битрикс в системе администрирования

display_errors = On

7) Настройки php-акселератора, например, у вас установлен акселератор APC (настройки для разных акселераторов, естественно будут разные, приведенные ниже настройки, рекомендованы 1С-Битрикс)

apc.num_files_hint = 30000 – максимальное число файлов для кешированияapc.user_entries_hint = 30000 – максимальное число переменных для кешированияapc.ttl = 86400 – время кешированияapc.max_file_size = 4M – максимальный размер кешируемых файловapc.shm_size = 256M – размер выделяемый системе для кеширования суммарный

memory_limit = 1024M

9) Эти настройки индивидуальные для каждого проекта, отвечают за размер загружаемых файлов через систему администрирования (максимальный размер файла и максимальный размер, передаваемый через формы методом POST)

upload_max_filesize = 128Mpost_max_size = 128M

Важно! После того, как вы настроили php-акселератор, нужно указать его в настройках 1С-Битрикс.

Это 2 файла:

1. /bitrix/php_interface/dbconn.php

Нужно добавить строчки (для акселератора APC):

define("BX_CACHE_TYPE", "apc");define("BX_CACHE_SID", $_SERVER."#01");

2. /bitrix/settings.php

'cache' => array(      'value' => array(           'type' => 'apc',           'sid' => $_SERVER."#01"      ),      'readonly' => false,),

Symfony + 0

Symfony — это набор повторно используемых PHP-компонентов и PHP-фреймворк для создания веб-приложений, API, микросервисов и веб-сервисов. Выпущен 22 октября 2005 г.

Для тестирования Symfony мы использовали Symfony Demo с MySQL (по умолчанию используется SQLite). Тесты были проведены несколько раз, и были взяты средние значения.

URL: /en/blog/posts/hello-world
Пост содержит заголовок, дату, имя автора, 2 тега и 5 комментариев.
Самая ранняя версия Symfony/demo, которую нам удалось получить — 3.3.6, но её поддержка уже не осуществляется. Мы использовали её, так как это единственное оставшееся демо-приложение Symfony, которое может работать на PHP 5.6. Последняя версия может работать только в версии 7.1 и выше. Результат немного медленнее по сравнению с тестом проводимым ранее. Возможно, это связано с тем, что на одной странице запрашивается больше таблиц, чем на главной странице (комментарии).

— Symfony 3.3.6, производительность PHP

Результаты тестов

Symfony 3.3.6, PHP 5.6 производительность: 71,71 запрос./сек.
Symfony 3.3.6, PHP 7.0 производительность: 155,08 запрос./сек.
Symfony 3.3.6, PHP 7.1 производительность: 158,88 запрос./сек.
Symfony 3.3.6, PHP 7.2 производительность: 169,78 запрос./сек.
Symfony 3.3.6, PHP 7.3 производительность: не поддерживается.

Поскольку Symfony 3.3.6 не поддерживает PHP 7.3, в этом тесте выигрывает PHP 7.2.

Важно отметить, что для Symfony 4.2.0 требуется PHP 7.1 или выше. — Symfony 4.2.0, производительность PHP

— Symfony 4.2.0, производительность PHP

Результаты тестов

Symfony 4.2.0, PHP 5.6 производительность: не поддерживаются
Symfony 4.2.0, PHP 7.0 производительность: не поддерживается
Symfony 4.2.0, PHP 7.1 производительность: 123,64 запрос./сек.
Symfony 4.2.0, PHP 7.2 производительность: 126,76 запрос./сек.
Symfony 4.2.0, PHP 7.3 производительность: 140,09 запрос./сек.

PHP 7.3 снова на высоте.

Кэширование страниц fastcgi

Я не советую использовать кэширование fastgci для сайтов WordPress, потому что там есть специальные плагины, которые могут точно контролировать кэш, очищать его когда нужно и вовремя обновлять. Но во всех остальных случаях кэш fastcgi может очень сильно ускорить работу сайта. Настраивается он в конфиге, где вы включаете fastgci, например, в конфигурации веб-сервера Nginx. Минимально для настройки кэша fastgci достаточно добавить в блок server такие строки:

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

Теперь нужно настроить блок обработки php:

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

С помощью таких методов ваши страницы будут загружаться намного быстрее. Если вам понадобится отключить кєширование php для отдельных страниц, то сначала создаем переменную no_cache со значением 0:

Затем проверяем нужные параметры, и если соответствует, то устанавливаем значение в 1:

И на завершение передаем значение этой переменной таким директивам, это отключит кэширование когда не нужно:

Не забудьте перезапустить Nginx перед тем как проверять:

Краткая история PHP

PHP — это язык сценариев, изобретенный Расмусом Лердорфом (Rasmus Lerdorf) в 1995 году. Первоначально этот язык разработчики написали для себя. Поэтому язык получил соответствующее название PHP как аббревиатуру от “Personal Home Page” — «Личная Домашняя Страница».

В ходе дальнейшей работы над языком Лердорф существенно расширил функциональность PHP, поэтому считается, что PHP теперь является рекурсивной аббревиатурой от “PHP: Hypertext Preprocessor” — PHP: Гипертекстовый Препроцессор».

За последние два десятилетия группа разработчиков PHP улучшила производительность PHP в следующих направлениях:

1. Прежде всего, в 1999 году появился новый PHP-движок Zend Engine;

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

3. В2004 году был выпущен PHP 5. Кроме прочего — обновилось ядро Zend (Zend Engine 2), что существенно увеличило эффективность этого интерпретатора;

4. В 2015 году появился обновленный PHP 7.0 с улучшенным движком Zend Engine и уменьшенным потребления памяти;

5. В момент написания статьи доступна новейшая версия PHP 7.1 от декабря 2016 года. Веб-сайт классов PHP содержит подробное описание всех изменений, внесенных между PHP 5 и PHP 7.1 (также в Википедии ).

Перспективы улучшения производительности PHP

Эволюция PHP продолжается. Новейшее изменение в разработке PHP 8 — это добавление компиляции «на лету», или JIT-компиляции, которая позволит создавать еще более быстрые веб-приложения. Так как темп технологического прогресса растет, растут ожидания пользователей. Поэтому разработчики должны всегда внимательно следить за последними изменениями.

Строя веб-приложения, помните, что сегодняшние приложения могут не работать следующем году. Вероятно, придется вносить изменения, чтобы обеспечить стабильную производительность PHP. Представление полной картины процесса развития — лучшая стратегия массового строительства PHP-приложений и веб-сайтов.

Настройка и оптимизация Open LiteSpeed

Настраивать OLS и хосты можно текстовыми конфигурационными файлами. На мой взгляд гораздо удобнее и нагляднее настраивать сервер из WebAdmin в браузере. он доступен по адресу https://ip-servera:7080/ . Вы получите сообщение о том, что ваше соединение не защищено.

Жмем <Advanced>. Подтверждаем согласие продолжить использовать небезопасное соединение. (Не составляет труда установить ssl сертификат, но это можно сделать и позже). Вводим логин и пароль (они у вас были созданы на этапе создания сервера).

Проблема доступа в WebAdmin

Если вы не можете получить доступ к консоли, вам необходимо разрешить соединение на порт 7080 в firewall. Сделать это можно в Cyberpanel.

Log in to Cyber Panel – Security – Firewall
Add Rule Name ” webpanel “
Select TCP
IP Address ” 0.0.0.0/0 “
Port ” 7080 “
Click on Add – Then, Reload The Page and Confirm Port 7080 is Added.

Или в терминале:

PHP JIT

JIT в PHP появилась давно. На самом деле он находился в разработке в течение нескольких лет и почти был выпущен в PHP 7.4. Работа по созданию JIT в PHP была тем импульсом, который привел к серьезному переписыванию движка, что дало версии 7.0 значительный прирост производительности.

PHP JIT построен как расширение кеша опкодов. Это означает, что его можно включать и отключать либо при сборке самого PHP, либо во время выполнения через php.ini.

Честно говоря, настройка JIT — один из самых запутанных способов настройки расширения PHP, который я когда-либо видел. К счастью, есть несколько сокращений конфигурации, которые упрощают настройку. Тем не менее, будет очень полезным знать как настраивать JIT, так что приступим.

Вывод

Несмотря на то, что Opcache значительно улучшил производительность PHP, мы все еще можем ее улучшить. В этой статье подробно рассказывается об использовании opcache_get_status и конфигурации opcache в документе php.

Вышеупомянутый контент надеется помочь всем,Многие PHP-разработчики всегда сталкиваются с некоторыми проблемами и узкими местами, когда они продвинуты. При написании слишком большого количества бизнес-кода нет ощущения направления. Я не знаю, с чего начать улучшать. Я собрал некоторую информацию по этому поводу, включая, но не ограничиваясь: распределенную архитектуру , Высокая масштабируемость, высокая производительность, высокий уровень параллелизма, настройка производительности сервера, TP6, laravel, YII2, Redis, Swoole, Swoft, Kafka, оптимизация Mysql, сценарии оболочки, Docker, микросервисы, Nginx и другие дополнительные знания. Галантерею можно раздать всем бесплатно, Вы можете присоединиться при необходимостиМоя официальная группакликните сюда。