Уменьшить потребление памяти php
pm = dynamic – количество дочерних процессов устанавливается динамически, основываясь на следующих директивах: pm.max_children , pm.start_servers , pm.min_spare_servers , pm.max_spare_servers .
pm = ondemand – процессы плодятся по требованию (при необходимости, в отличие от динамического варианта, где pm.start_servers запускаются при запуске сервиса).
pm = static – количество дочерних процессов фиксировано директивой pm.max_children .
…вы можете посмотреть полный список директив php-fpm.conf для получения дополнительной информации.
Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor
Это может показаться немного не по теме, но я надеюсь связать его с нашей оптимизацией PHP-FPM. Да, все мы когда-то натыкались на проблемы с производительностью процессора, будь то ноутбук, виртуальная машина или выделенный сервер. Помните масштабирование частоты процессора? (CPUFreq governor) Эти параметры, доступные на *nix и Windows, могут повысить производительность и отзывчивость системы путем изменения настройки CPU governor с ondemand на performance . Сейчас давайте сравним описания и поищем сходства:
Governor = ondemand – Динамически увеличивает/уменьшает тактовую частоту процессора в зависимости от загруженности системы. Выводит до максимальной частоты, а потом уменьшает по мере увеличения времени простоя.
Governor = conservative – Похож на ondemand, но более экономный (предпочтение отдаётся меньшим тактовым частотам). Частота растёт более плавно.
Governor = performance – Поддерживает процессор(ы) на максимальной тактовой частоте.
… для дополнительной информации см. полный список настроек CPUFreq governor.
Заметили сходство? Я хотел сначала использовать это сравнение, чтобы более наглядно и лучше описать рекомендацию использовать pm static для PHP-FPM в качестве вашего первого выбора.
Настройка performance в CPU governor – это довольно безопасный прирост производительности, потому что это почти полностью зависит от предела процессора вашего сервера. Но есть несколько побочных эффектов (при постоянном удерживании частоты вашего процессора на 100%) – такие, как нагрев, время автономной работы (ноутбук) и другие. Однако это действительно самый быстрый параметр для вашего процессора.
Использование pm = static для максимальной производительности вашего сервера
Настройка pm = static в PHP-FPM сильно зависит от того, сколько свободной памяти на сервере. В основном, если вы страдаете от нехватки памяти сервера, то pm ondemand или dynamic могут оказаться лучшими вариантами. С другой стороны, если у вас достаточно свободной памяти, вы можете избежать большей части накладных расходов менеджера процессов, установив pm static до максимальной емкости сервера. Другими словами, когда вы делаете расчёты, pm.static нужно установить на максимальное количество PHP-FPM процессов, которые могут выполняться без создания проблем доступности памяти или кеша; однако, не так высоко, чтобы перегрузить процессор(ы) и иметь кучу отложенных операций PHP-FPM-а.
Тут отображаются не все процессы, а только та часть, что вместилась в ваше терминальное окно. В нашем случае отсортированных по %CPU (потреблению процессора). Чтобы увидеть все 100 PHP-FPM процессов, вы можете использовать что-то вроде этого:
Когда использовать pm ondemand и dynamic
Используя режим dynamic , вы можете наткнуться на подобные ошибки:
Вы можете попытаться увеличить/изменить настройки и по-прежнему видеть ту же ошибку. Подобная ситуация описана в этом вопросе на Serverfault. В таком случае, pm.min была слишком низкой, а т. к. трафик сильно колеблется, режим dynamic достаточно сложно настроить правильно. Общий совет: используйте ondemand , как советуют в этом же вопросе. Однако что еще хуже, т. к. ondemand будет завершать процессы в простое вплоть до 0 когда мало трафика, то после вы получите настолько много накладных расходов, насколько скакнёт трафик. Если, конечно, вы не установите время ожидания чрезвычайно высоким. В этом случае вам просто нужно использовать pm = static + высокий pm.max_requests .
Заключение
Когда дело доходит до PHP-FPM, раз вы начали получать серьезный трафик, то режимы ondemand и dynamic могут ограничить пропускную способность из-за свойственного оверхеда. Исследуйте вашу систему и установите количество процессов в наибольшее, с которым справится ваш сервер. Начните с pm.max_children , установленным на основе максимального использования режимов dynamic или ondemand , а затем увеличивайте до точки, где память и процессор остаются не перегруженными. Вы заметите, что с pm = static , т. к. вы держите всё в памяти, всплески трафика со временем будут меньше влиять на всплески загрузки процессора, а показатели загрузки и средней загрузки станут более сглаженными. Средний размер вашего PHP-FPM-процесса будет зависеть от конкретного веб-сервера, требующего ручной настройки, вот почему автоматизированные режимы – dynamic и ondemand – являются более популярными рекомендациями. Надеюсь, это была полезная статья.
Стандартные библиотеки PHP умеют генерировать только целые случайные числа. Однако, возникают задачи где нужно не целое рандомное число с максимально…
Иногда при обработке с помощью PHP больших и не очень данных, можно словить досадную ошибку посреди выполнения скрипта: PHP Fatal…
Для уменьшения потребления памяти PHP и ускорения его работы рекомендуется использовать различные акселераторы. Особенно это актуально для бюджетных VPS с небольшим количеством оперативной памяти на которых крутятся сайты на прожорливых CMS типа WordPress, Bitrix или MODx.
Zend OPcache — расширение для PHP, основное назначение которого — увеличение производительности интерпретатора при обработке сценариев путем кэширования их байт-кода.
В данной статье расскажу как установить Zend OPcache на Ubuntu Server 20.04 LTS
Если вы используете PHP 5.5 и выше, то в нем по-умолчанию идет Zend OPcache и ничего дополнительно ставить не нужно.
Проверяем установлен ли ZendOpCache на вашем сервере, вот так:
Вывод должен быть примерно такой:
Настройка Zend OPcache
В интернете множество статей в которых описывается оптимальная настройка Zend OPcache. Почитав их, я решил объединить их в своей статье и найти золотую середину. На моем сервере установлен php 7.4 + nginx в связке с Apache. И так, открываем файл конфигурации php. :
Находим следующие строки и выставляем значения как у меня (хотя можете поэкспериментировать)
Описание значений Zend OPcache
opcache.enable — включаем наш Zend OPcache.
opcache.enable_cli — включает OPcache в CLI-версии PHP.
opcache.memory_consumption — задает использование памяти для расширения (если ОЗУ позволяет, то можно увеличить значение).
opcache.interned_strings_buffer — задает объем памяти для хранения интернированных строк, в мегабайтах.
opcache.max_accelerated_files – максимальное количество скриптов в памяти (тут тоже можно увеличить, если памяти хватает).
opcache.revalidate_freq — это валидация кэша в секундах, в интернете все рекомендуют значение 60, я же использую 2, но иногда рекомендуют ставить 0 (ноль), то есть постоянно проверять на изменения. К примеру в Joomla OPcache кэширует все файлы и будет отдавать кэш после сохранения файлов еще то время, которое в этой строке. То есть вы сохранили файл, но все равно в течении указанного времени будете видеть старую копию из кеша. Поэтому не жалуйтесь, что файлы не сохраняются, подождите выставленное вами время.
opcache.fast_shutdown — определяет включено или выключено быстрое завершение последовательности ускоренного, кода, дает возможность использовать Zend Engine Memory Management
Перезапуск web-сервера
Чтобы изменения вступили в силу нужно перезапустить вэб-сервер:
Изменение скорости работы сайта после установки акселератора PHP
Блог на WordPress, до настройке Zend OPcache, страница генерировалась за 0,55 сек., потребление памяти составляло 51 МБ.
После установки акселератора Zend OPcache скорость генерации страницы снизилась до 0,18 сек, потребление памяти при этом составило 17 МБ.
Комментарии излишни. Использование PHP акселератора положительно сказывается на скорости работы сайта и снижает потребление оперативной памяти.
Настройки потребления ресурсов в PHP скриптах можно установить в главном конфигурационном файле php.ini, а также в самих скриптах.
В файле php.ini за это отвечают директивы из раздела Resource Limits (ограничение потребления ресурсов).
Как увеличить память для PHP скриптов
Для этого в файле php.ini найдите и отредактируйте директиву:
Эта директива задаёт максимальное время в секундах, в течение которого скрипт должен полностью загрузиться. Если этого не происходит, парсер завершает работу скрипта. Этот механизм помогает предотвратить зависание сервера из-за плохо написанного скрипта. По умолчанию на загрузку даётся 30 секунд. Если PHP запущен из командной строки, это значение по умолчанию равно 0.
На максимальное время выполнения не влияют системные вызовы, потоковые операции и т.п.
При работе в безопасном режиме эту настройку нельзя изменить функцией ini_set(). Если значение все же нужно изменить, надо либо выключить безопасный режим, либо изменить значение прямо в php.ini.
Веб-серверы обычно имеют свои настройки тайм-аута, по истечении которого сами завершают выполнение скрипта PHP. В Apache есть директива Timeout, в IIS есть функция CGI timeout. В обоих случаях по умолчанию установлено 300 секунд. Точные значения можно узнать из документации к веб-серверу.
Функция для увеличения и ограничения времени выполнения PHP
Функция set_time_limit ограничивает время выполнения скрипта.
Она задает время в секундах, в течение которого скрипт должен завершить работу. Если скрипт не успевает, вызывается фатальная ошибка. По умолчанию дается 30 секунд, либо время, записанное в настройке max_execution_time в php.ini (если такая настройка установлена).
При вызове set_time_limit() перезапускает счетчик с нуля. Другими словами, если тайм-аут изначально был 30 секунд, и через 25 секунд после запуска скрипта будет вызвана функция set_time_limit(20), то скрипт будет работать максимум 45 секунд.
- СЕКУНДЫ (максимальное время выполнения в секундах. Если задан ноль, время выполнения неограничено)
Возвращаемые значения: возвращает TRUE в случае успеха, иначе FALSE.
Внимание: эта функция не работает, если PHP работает в безопасном режиме. Обойти это ограничение можно только выключив безопасный режим или изменив значение настройки в php.ini.
Замечание: функция set_time_limit() и директива max_execution_time влияют на время выполнения только самого скрипта. Время, затраченное на различные действия вне скрипта, такие как системные вызовы функции system(), потоковые операции, запросы к базам данных и т.п. не включаются в расчет времени выполнения скрипта. Это не относится к системам Windows, где расчитывается абсолютное время выполнения.
Увеличение выделенной памяти для PHP скриптов
Директива в файле php.ini
задаёт максимальный объем памяти в байтах, который разрешается использовать скрипту. Это помогает предотвратить ситуацию, при которой плохо написанный скрипт съедает всю доступную память сервера. Для того, чтобы убрать ограничения, установите значение этой директивы в -1.
В версиях до PHP 5.2.1 для использования этой директивы, она должна была быть указана на этапе компиляции. Так, ваша строка конфигурации должна была включать: --enable-memory-limit. Эта опция компиляции была также необходима для использования функций memory_get_usage() и memory_get_peak_usage() до версии 5.2.1.
Если используется целое число, то значение измеряется байтами. Вы также можете использовать сокращённую запись.
Доступные опции: K (для килобайт), M (для мегабайт) и G (для гигабайт; доступна начиная с PHP 5.1.0); они регистронезависимы. Все остальное считается байтами. 1M равно одному мегабайту или 1048576 байтам. 1K равно одному килобайту или 1024 байтам. Эти сокращения вы можете использовать в php.ini и в функции ini_set(). Обратите внимание, что числовое значение приводится к типу integer; например, 0.5M интерпретируется как 0.
Увеличение времени парсинга данных из запроса.
Директива в файле php.ini
задаёт максимальное время в секундах, в течение которого скрипт должен разобрать все входные данные, переданные запросами вроде POST или GET. Это время измеряется от момента, когда PHP вызван на сервере до момента, когда скрипт начинает выполняться. Значение по умолчанию -1, что означает, что будет использоваться max_execution_time. Если установить равным 0, то ограничений по времени не будет.
При запуске в командной строке значение директивы установлено на -1 (неограниченно).
Увеличение глубины вложенности входных переменных
Директива в файле php.ini
задаёт максимальную глубину вложенности входных переменных (то есть $_GET, $_POST.). По умолчанию данная директива закомментирована.
Ограничение на количество входных переменных
Директива в файле php.ini
определяет, входных переменных может быть принято в одном запросе (ограничение накладывается на каждую из глобальных переменных $_GET, $_POST и $_COOKIE отдельно). Использование этой директивы снижает вероятность сбоев в случае атак с использованием хеш-коллизий. Если входных переменных больше, чем задано директивой, выбрасывается предупреждение E_WARNING, а все последующие переменные в запросе игнорируются. По умолчанию данная директива закомментирована.
Внимание: после внесения изменений в файл php.ini необходимо перезагрузить веб-сервер, чтобы изменения вступили в силу.
Проверка использование ресурсов
Функция getrusage получает информацию об использовании текущего ресурса.
Возвращаемые значения: возвращает ассоциативный массив, содержащий данные возвращённые из системного вызова. Имена элементов соответствуют документированным именам полей.
Пример использования getrusage():
Увеличение разрешённого размера файлов для загрузки на сервер
Кроме описанных ограничений на потребление непосредственных ресурсов веб-сервера, также имеются ограничения, которые оказывают косвенное воздействие на ресурсы: например, загрузка слишком большого файла на сервер может потребовать большого количества ресурсов для его обработки, либо привести к переполнению дискового хранилища сервера. Поэтому существуют дополнительные лимиты, включённые в другие разделы конфигурационного файла помимо Resource Limits.
В частности, директива
устанавливает максимальный размер закачиваемого файла.
Если используется целое число, значение измеряется байтами. Вы также можете использовать сокращённую запись, которая описана чуть выше.
Максимально допустимый размер данных, отправляемых методом POST
Методом пост могут отправляться как текстовые данные (например, при отправке комментария на сайт), так и файлы. Если вы увеличили значение upload_max_filesize чтобы иметь возможность загружать файлы большего размера на сайт, то также нужно увеличить и значение директивы:
Замечание: PHP разрешает сокращения значений байт, включая K (кило), M (мега) и G (гига). PHP автоматически преобразует все эти сокращения. Будьте осторожны с превышением диапазона 32-битных целых значений (если вы используете 32-битную версию), так как это приведёт к ошибке вашего скрипта.
Для полного снятия лимитов значение можно установить на 0.
Значение этой настройки игнорируется, если чтение данных POST отключено с помощью enable_post_data_reading.
Увеличение количества файлов, выгружаемых на сайт за один раз
устанавливает максимально разрешённое количество одновременно закачиваемых файлов. Начиная с PHP 5.3.4, пустые поля загрузки не рассматриваются этим ограничением.
Имеются ввиду не общее количество одновременно закачиваемых файлов, которые могут выполнять различные пользователи, а именно количество файлов за один запрос.
Программистам очень нравится последняя версия PHP — одного из наиболее быстрых языков сценариев. В этом можно убедиться, прочитав, например, статью « Сравнение производительности PHP 7.0 и HHVM » на Хабрахабре или статью на английском языке « PHP 7 vs HHVM – Which One Should You Use? ».
Однако поддержание оптимальной производительности PHP — это не только быстрое выполнение кода. Лучший инструмент для улучшения производительности PHP не найти среди готовых программ. Необходимо знать, на какие именно проблемы производительности обратить внимание и как их решать . В этой статье мы постарались собрать все, что нужно для успешной работы с PHP-приложениями.
Производительность PHP - один из краеугольных камней скорости сайта. Производительность PHP не может быть так же легко улучшена, как браузерные (клиентские) аспекты скорости сайта - для улучшения которых существуют специализированные сервисы - и требует отдельного внимания веб-разработчиков и системных администраторов.
Краткая история PHP
В ходе дальнейшей работы над языком Лердорф существенно расширил функциональность 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 ?
Следует иметь ввиду, что производительность и скорость - не являются синонимами. Оптимальная производительность балансирует между скоростью, безошибочностью и масштабируемостью. Например, при написании веб-приложения придется выбирать между двумя приоритетами:
1) приоритетом скорости , написав скрипт, который заранее загружает все в память;
2) приоритетом масштабируемости со скриптом, который загружает данные блоками.
На следующем рисунке 1 показан теоретический компромисс между скоростью и масштабируемостью.
Красная линия представляет сценарий, оптимизированный для скорости , а синяя линия — для масштабируемости . На горизонтальной оси отложена скорость выполнения скриптов ), на вертикальной — количество одновременных вызовов сайта ).
Рис. 1. Теоретический компромисс между скоростью и масштабируемостью
Из нижней части рисунка видно, что малом числе одновременных вызовов сайта скорость выполнения скриптов на красной линии выше, чем на синей. Из верхней части рисунка следует, что когда число пользователей растет, скорость выполнения скриптов на красной линии становится ниже, чем на синей. Скорость замедляется и на синей линии, когда трафик растет, но гораздо медленнее, чем на красной.
Получаем, что когда трафик превышает определенный порог, сценарий для скорости становится медленнее сценария для масштабируемости . Этот порог хорошо виден на рисунке как пересечение красной и синей линий.
Здесь можно провести аналогию с бегунами на разные дистанции: со спринтером (бегуном на короткие дистанции) и стайером (бегуном на длинные дистанции). Спринтеры намного быстрее бегут на короткие дистанции, но на более длинных они утомляются. Стайеры держат более медленный, но более стабильный темп, который позволяет им сохранять энергию на больших расстояниях . Аналогично, разные скрипты работают лучше в различных ситуациях. Правильный выбор скрипта для конкретного приложения требует наблюдения за активностью пользователей на сайте. При росте трафика придется переходить с одного скрипта на другой.
Когда следует начинать оптимизировать PHP -код?
Опытные программисты время от времени сохраняют протестированный код, заканчивая тем самым цикл проекта. Но это разумно делать только при хорошей производительности PHP-приложения!
Как добиться хорошей производительности PHP-приложения? Необходимо проводить тесты во время процесса разработки . Иначе придется переписывать большие блоки кода, чтобы заставить приложение нормально функционировать.
Оптимизировать PHP -код следует начинать перед созданием PHP-приложения! Необходимо сразу оценить состояние вашего железа и программного обеспечения, чтобы определить параметры их производительности. Эта информация при кодировании приложения позволит оценить риски и выигрыш конкретных компромиссов. Причем необходимо использовать адекватные тестовые данные , иначе код приложения окажется бесперспективным.
Советы по оптимизации PHP -скриптов
Просто написание хорошего кода — важный первый шаг создания быстрых и стабильных PHP-приложений. Применяя с самого начала методы, описанные ниже, вы сэкономите время при поиске ошибок.
1. Используйте готовые функции PHP
Везде, где это возможно, используйте готовые функции PHP. Избегайте написания ваших собственных функций. Для этого потратьте немного времени на изучение функций PHP. Тогда код приложения получится более быстрым и эффективным.
2. Используйте JSON вместо XML
Функции PHP json_encode() и json_decode() просто невероятно быстры. Поэтому использование JSON предпочтительнее использования XML.
Если вам все же приходится разбираться с XML, лучше использовать шаблонные регулярные выражения, чем манипуляции с DOM.
3. Используйте методы кэширования
Кэш-память особенно полезна для сокращения объема загружаемых данных.
Кэширование байт-кода с помощью APC или OPcache сильно экономит время выполнения скомпилированного сценария.
4. Уберите лишние вычисления
Если одно и то же значение выражения используется многократно, вычислите его заранее и присвойте переменной. Тогда не придется его вычислять каждый раз.
5. Используйте isset()
Проводите сравнения с помощью пар count () , strlen() и sizeof() , isset() . Это быстрый и простой способ поиска значений, больше нуля.
6. Отключите ненужные классы
Если не планируется использовать классы или методы многократно, то они вообще не нужны. Если необходимо все же использовать классы, лучше использовать методы производного класса , поскольку они быстрее методов базовых классов.
8. Закрывайте соединения с базой данных
Сбрасывание переменных и закрытие соединений с базой данных сэкономит драгоценную память.
9. Ограничьте обращения к базе данных
Старайтесь использовать совокупности запросов к базе данных. Это сокращает количество обращений к базе данных, приложение будет работать быстрее.
10. Используйте строковые функции Str
str_replace быстрее, чем preg_replace , а strtr в четыре раза быстрее, чем str_replace .
11. Используйте одинарные кавычки
Когда только возможно, используйте одинарные кавычки, а не двойные. Двойные кавычки проверяются компилятором на переменные, что понижает производительность.
12. Используйте три знака равенства
Поскольку « = = =» проверяет величины только одного типа, это делает оператор сравнения « = = =» более быстрым, чем оператор « = =» .
Узкие места производительности PHP
Бывает, конечно, что переделка сценариев выгодна. Однако есть проблемы, которые понижают производительность PHP, не связанные с кодом приложения. Поэтому разработчикам нужно разбираться в подсистемах их сервера, чтобы определить и устранить узкие места . Ниже перечислены области, которые нужно проверять при появлении проблем с производительностью.
1. Сеть
Один из очевидных источников узких мест — это сети. Может просто не хватить ресурсов сети для обработки передаваемого объема данных.
2. Центральный процессор
Передача простых страниц HTML через сеть не истощает центральный процессор сервера, тогда как PHP-приложения перегружают его. Можно, по крайней мере, использовать многопроцессорный сервер, чтобы обработать PHP-код более эффективно.
3. Совместно используемая память
Отсутствие совместно используемой памяти снижает межпроцессорный обмен данными, что приводит к падению производительности. Поэтому, имея многопроцессорный сервер, не забывайте использовать совместную память.
4. Файловая система
Файловая система со временем становится фрагментированной. Поэтому используйте файловый кэш RAM, который ускорит доступ к диску, если этот кэш достаточного размера.
5. Управление процессами
Удостоверьтесь, что сервер не перегружен ненужными процессами. Удалите любые неиспользованные сетевые протоколы, антивирусные сканеры, почтовые серверы и драйверы оборудования.
Выполнение PHP в многопоточном режима также улучшает время отклика на запросы (но не рекомендуется, в общем случае, для высоконагруженных систем, потому что создает дополнительные издержки на переключение контекстов разных ядер).
6. Другие серверы
Если приложение зависит от внешних серверов, их узкие места будут снижать производительность. В такой ситуации, увы, мало что можно изменить. Тем не менее, всегда можно придумать какие-то изменения на своей стороне, чтобы смягчить такое падение производительности.
Еще советы по улучшению производительности PHP
1. Используйте расширение ядра Zend OPCache
Так как PHP интерпретируется в выполняемый код, программисту приходится повторно компилировать код даже при небольшом его изменении на работающем сайте. К сожалению, такая повторная компиляция практически одинакового кода снижает производительность. Отсюда понятно, почему кэширование промежуточного кода — OPCache — очень полезно.
Zend OPCache — это расширение, которое сохраняет скомпилированный код в памяти. Это позволяет PHP в следующий раз при выполнении кода проверять разметки времени и размеры файла, чтобы определить, были ли части исходного файла изменены. Если таких изменений не было, то будет запущен сохраненный код.
Более подробную информацию можно получить в статье на Хабрахабре « PHP Performance Series: Caching Techniques »
На рисунке 2 показано различие во времени выполнения и использовании памяти между PHP-приложением, выполняемым: 1) без кэша; 2) с OPcache; 3) с eAccelerator (другой инструмент PHP-кэширования).
Правый график показывает время выполнения в миллисекундах ( Execution Time (ms) ), левый — использование памяти в мегабайтах ( Memory usage (mb) ). Столбики синего цвета соответствуют отсутствию кэширования , красного — кэшированию OPcache , зеленого — кэшированию eAccelerator.
Из рисунка 2 следует, что кэширование OPcache снижает как время выполнения, так и использование памяти примерно в два раза по сравнению с отсутствием кэширования. Кэширование eAccelerator немного уступает кэшированию OPcache.
Рис. 2. Столбиковые диаграммы различия во времени выполнения и использовании памяти между PHP-приложением, выполняемым без кэширования, с OPcache и с eAccelerator
2. Выявите задержки базы данных
Как уже сказано выше, проблемы производительности не всегда связаны с кодом. Большинство узких мест возникает при обращении приложения к ресурсам. Обслуживание доступа к данным PHP-приложения может составлять до 90 процентов времени выполнения . Поэтому в первую очередь необходимо проанализировать все случаи доступа к базе данных.
Удостоверьтесь, что лог медленных запросов SQL включен, чтобы иметь возможность выявить их. Затем изучите эти медленные запросы, чтобы оценить их эффективность. Если обнаружится, что выполняется слишком много запросов или одни и те же запросы необоснованно повторяются, внесите соответствующие изменения. Такие изменения должны повысить производительность приложения, сокращая время доступа к базе данных.
3. Очистите файловую систему
Проанализируйте файловую систему на неэффективность, то есть удостоверьтесь, что файловая система не используется для хранения сессий. Самое главное - внимательно следите за функциями статистики файлов: file_exists(), filesize() и filetime(). Попадание этих функций внутрь цикла приводит к проблемам с производительностью.
4. Тщательно контролируйте показ API
Большинство веб-приложений, которые зависят от внешних ресурсов, используют удаленный API . Хотя удаленный API находится вне вашего контроля, однако можно смягчить проблемы API-производительности. Например, можно кэшировать API-вывод или делать фоновые вызовы API. Установите разумные интервалы для API-запросов и, если это возможно, показывайте на дисплее API -вывод без ответа API.
5. Профилируйте PHP
Использования OPcache и управления внешними ресурсами достаточно, чтобы большинство приложений выполнялись благополучно. Но если ваши потребности растут, пора профилировать PHP. Конечно, полное профилирование PHP-кода отнимает много времени, но оно дает всестороннюю информацию о производительности PHP-приложения. Имеются общедоступные программы для профилирования PHP-кода, такие, как Xdebug.
Xdebug рассматривается в статье на Хабрахабре « Introducing xdebug »
Необходимо уметь контролировать производительность PHP
Веб-приложение может хорошо работать минуту, но внезапные проблемы с трафиком могут прервать его нормальную работу. Правда, к этому можно подготовиться. Понятно, что внесение изменений всегда требует времени, усилий и денег, и всегда трудно сказать, стоят ли того инвестиции. Лучший способ обосновать принятие решений — постоянно собирать данные.
Программное обеспечение по контролю производительности PHP немедленно оценивает эффекты любых вносимых изменений. Конечно, нужно знать, что именно оценивать. В этом плане скорость и использование памяти — лучшие индикаторы производительности, так как они влияют на время загрузки страницы, что весьма критично для веб-приложений.
Несмотря на то, что сбор данных важен, необходимо выключить систему контроля, когда она не нужна, поскольку поток логов замедляет выполнение приложения. С другой стороны, эти логи дают ценную информацию об улучшении производительности. Таким образом, необходимо периодически контролировать пиковые периоды трафика.
Перспективы улучшения производительности PHP
Эволюция PHP продолжается. Новейшее изменение в разработке PHP 8 — это добавление компиляции «на лету», или JIT -компиляции, которая позволит создавать еще более быстрые веб-приложения. Так как темп технологического прогресса растет, растут ожидания пользователей. Поэтому разработчики должны всегда внимательно следить за последними изменениями.
Строя веб-приложения, помните, что сегодняшние приложения могут не работать следующем году. Вероятно, придется вносить изменения, чтобы обеспечить стабильную производительность PHP. Представление полной картины процесса развития — лучшая стратегия массового строительства PHP-приложений и веб-сайтов.
Речь в статье пойдет о версиях PHP на вашем сайте или сервере. Присутствует сводная таблица результатов моих эксперементов.
Немного вводной информации
Я и сам ранее не обращал внимание насколько сильно версия PHP влияет на скорость загрузки страницы и нагрузки на сервак. Случайно увидел цифры, когда тестировал AdsPlace'r Pro после жалоб клиентов, что в новом апдейте перестал работать корректно. Как раз проблема и заключалась в том, что большинство использует старые версии PHP и пришлось нам "перекраивать" быстро код.
В общем, ниже информация для размышления и некоторые подсказки.
Результаты тестирования
Итак, вот что получилось:
| Версия PHP | Сайт 1 | Сайт 2 | Сайт 3 |
|---|---|---|---|
| Потребляемая память, Mb | |||
| PHP 5.3 | 22.1 | 11 | 15.4 |
| PHP 5.4 | 15.4 | 7.5 | 10.4 |
| PHP 7.1 | 11 | 5.5 | 7.2 |
| Скорость загрузки страницы, сек. | |||
| PHP 5.3 | 0.385 | 0.153 | 0.196 |
| PHP 5.4 | 0.3 | 0.135 | 0.162 |
| PHP 7.1 | 0.135 | 0.062 | 0.071 |
Как видим: чем новее версия PHP, тем меньше идет нагрузка на сервер (потребляемая память самой CMS WordPress и установленными плагинами), а так же быстрее грузится страница.
Как определить версию PHP на сервере
Самый простой способ - это найти данную информацию у себя в панели хостера в аккаунте.
Если такой информации нет, то:
- Создаете новый файл phpinfo.php
- В нем размещаете следующее
В результате откроется страница, где будет выведена нужная нам информация:
Если не выводит такой информации, а показывает содержимое файла phpinfo.php, значит для сервера/сайта не установлен PHP-обработчик и вам надо обратиться в техподдержку.
Не забудьте потом удалить файл phpinfo.php в целях безопасности.
Как поменять версию PHP
Делается это в панели хостера, если у них есть такая услуга вообще. Быть может потребуется обратиться в техподдержку, чтобы они поменяли.
Если же вы хоститесь у Beget , то сделать можете сами в пару кликов: пункт Сайты -> находите свой домен и кликаете по иконке версии PHP -> выбираете версию PHP и Применить.
Изменения вступят в силу в течении минуты.
Подводные камни при смене версии PHP
Есть вариант, что как только вы смените версию PHP - у вас перестанет работать сайт или часть его функционала, плагинов. Это может случиться из-за использования в теме сайта или установленных плагинах старых функций.
Паниковать не стоит. Верните назад старую версию PHP на боевом сайте и попробуйте на тестовом с новой PHP разобраться в причине. Вначале на пустой теме, без плагинов. Убедитесь что причина не в ней.
Далее подключаем поочередно плагины и смотрим какой "косячит". Таким образом можно вычислить проблему и уже дальше самостоятельно или при помощи специалистов решить задачу.
Читайте также: