Содержание

Оптимизация PHP скриптов // Антон Шевчук

Оптимизация – это процесс модификации системы для улучшения её эффективности (wikipedia). Так давайте приступим к делу…

Нет, вначале прочитайте статью “Оптимизация программ на PHP”. Читайте-читайте, я подожду…

Я так понимаю вы прочитали и решили “оптимизировать” ваш текущий проект? Похвально, только перед тем как начать рефакторинг – посмотрите сколько времени и памяти кушает ваш проект, а теперь вперед – оптимизируем… После того как нелегкий труд будет закончен замерим результаты – поразительный прирост производительности – процентов 5-6% – удивлены? Давайте немного проанализируем советы приведенные в данной статье:

Выносите $переменные из “текстовых строк” – ускорение 25-40%
Посчитайте кол-во таких строк в вашем проекте, я думаю их кол-во будет стремиться к нулю, если вы используете какой-нить шаблонизатор (Smarty).

Короткие переменные не более 7 символов – ускорение 15%


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

Тормозят ли массивы в PHP? Вернее, как именно. Ускорение 40%
Процитирую “Доступ к элементу одномерного ассоциативного массива по имени, не заключенному в кавычки”, если вы сейчас будете так писать – то неприменно получите Notice. Notice‘ы тормозят приложение.

Выносите многомерные массивы из “текстовых строк” – ускорение 25-30%
Да и читабельность повыше будет.

Регулярные выражения: PHP(POSIX) vs Perl. Ускорение 60-200%


Много у вас в проекте таких? В любом случае – лучше избегать регулярок в узких местах.

Циклы: for, foreach, while, count/sizeof() – ускорение 15%-30%
Если нет необходимости в foreach используйте for.

Для чтения файла file() быстрее, чем fopen+цикл – ускорение 40%
У меня в последних проектах не так часто приходиться считывать файлы, а у Вас?

К чему я клоню? Статья хороша, стоит помнить о такой мелкой оптимизации, особенно в “узких” местах. Почему мелкой? Посмотрите на результаты такой оптимизации – менее 10% прироста скорости, ведь тесты производительности показаны относительные, а если перевести в секунды: count() выполняется 0.0002 сек., а sizeof 0.00018 – много мы выиграем? Так что же необходимо оптимизировать?…

Архитектура
Тут есть где разойтись, и начать писать весь проект заново 😉 но лучше чуть-чуть напильником пошаманить – зачастую эффект будет поразительным. Для начала – не подключайте сразу все библиотеки используемые в проекте – всё только по требованию. Старайтесь разделить проект на составляющие – шаблоны проектирования еще никто не отменял.

Работа с БД
Очень много времени уходит на работу с БД, как сам факт обращения к ней, так и сама выборка из БД происходит не моментально. И что же делать? Необходимо убирать лишнее, где это возможно, а где нет – стараемся кэшировать. И уберите же обращение к БД в цикле!

Парсинг XML
У вас есть конфигурационный файл в XML формате и он каждый раз парсится? Ой как не хорошо – давайте-ка будем это дело кэшировать!

Вывод:
1. Потратьте на разработку архитектуры проекта чуть больше, чем пару часиков
2. Уберите лишние обращения к БД (если первый пункт займет у вас несколько дней – то и этот не появится)

3. Используйте кэширование данных получаемых из БД или XML
4. Используйте кэширование готовых HTML страничек
5. Установите какой-нить оптимизатор PHP (XCache или Zend Optimizer)

И еще – где-то упоминалось, что страничка не должна грузиться более двух секунд – значит PHP не должен тратить более одной секунды на её генерацию.

|

Проекты

  • Charts Builder
  • Photo Blog
  • Syntax Highlighter

Блогролл

  • NIX Solutions Ltd.
  • Мысли с самого низа
  • Прохождение игр

© Антон Шевчук 2007-2023

Оптимизация производительности в Composer 2.2 — Пятиминутка PHP

В декабре 2021 года вышло обновление пакетного менеджера Composer, версия 2.2. Заявлено увеличение производительност в некоторых случаях на 90%.

https://blog.packagist.com/composer-2-2/

Как это возможно и почему Composer раньше был на столько прожорливым? Я изучил изменения в исходном коде и вот что я нашел…

Релиз ноты содержат ссылки на два Pull Request:

  • https://github.com/composer/composer/pull/9261
  • https://github.com/composer/composer/pull/9620

Я изучил эти Pull Requests, хотел найти что-то интересное и полезное, возможно, применимое в моей работе. Например, какие-то хитрые трюки по использованию SplFixedArray вместо Array или определённый стиль работы с объектами, помогающий PHP интерпретатору или JIT компилятору лучше оптимизировать исполняемый код.

На деле всё оказалось банальнее: алгоритмы и ещё раз алгоритмы, ничего PHP-специфичного.

Внутри Composer есть некий объект Pool в который записывается информация о всех версиях пакетов удовлетворяющих граничным условиями описанным в composer.json. Позже этот Pool передаётся на вход некоему Solver, который решает задачу выбора не противоречивого набора версий. Чем больше пакетов передадим в Solver, тем сложнее Solver’у найти решение. Как пишет автор PR сложность возрастает экспоненциально.

Решение: передавать в Solver как можно меньше вариантов пакетов. Но разве можно просто так взять и выкинуть часть пакетов из Pool? Автор этого улучшения предположил, что можно. Он приводит следующий пример: если в нашем проекте используется пакет symfony/routing и в composer.json указана версия 4.4, то скорее всего нам подойдёт любая минорная версия в интервале от 4.4.0 и до последней 4.4.х. Подойдёт с точки зрения удовлетворения зависимостей. Какую выбрать, первую или последнюю зависит от флагов --prefer-stable и --prefer-lowest.

Раньше Pool содержал в себе информацию от всех версиях пакета symfony/routing от 4.4.0 вплоть до последней 4.4.x и это создавало много работы для процесса разрешения зависимостей в Solver.

После оптимизации, т. е. начиная с Composer 2.2, в Pool содержится только одна версия пакета, и это значительно упрощает работу для Solver.

Оптимизация будет работать надёжно и верно лишь в том случае, если в рамках минорных версий пакет не менял свои зависимости описанные в require, replace, provide и conflict. В противном случае, нельзя просто так взять и выкинуть из Pool часть минорных версий. Оптимизация не 100% надёжна, поэтому если на вашем проекте после перехода на Composer 2.2 не удаётся обновить зависимости из-за конфликтов, возможно Solver не смог подобрать подходящую комбинацию версий разных пакетов именно из-за того, что часть минорных версий была выброшена из анализа. Поэтому предусмотрена переменная окружения COMPOSER_POOL_OPTIMIZER=0 отключающая данную оптимизацию.

Естественно, всё это имеет значение только для команды composer update, когда требуется выбрать наилучшие версии пакетов подходящие под ограничения в файле composer.json. Если же мы делаем composer install – эти оптимизации не применяются, т. к. устанавливаются конкретные версии зафиксированные в composer.lock файле.

Тут мне в голову пришло интересное размышление. Мы знаем, что чем меньше версий пакетов требуется для анализа, тем быстрее composer update отработает. Значит при выпуске новой мажорной версии фреймворка, как только мы на него переходим и минорных версий пока нет, команда composer update должна отрабатывать максимально быстро. А с течением времени и появлением минорных версий пакетов composer update должен был работать всё медленнее и медленнее. Интересно, кто-нибудь замечал этот эффект?

Я лично сравнил работу composer update на одном из своих Laravel проектов с включённой оптимизацией Pool’а и с выключенной. Запускал командой composer update -v –dry-run–profile.

Без оптимизации максимальное использование памяти составило 2Гб и время работы 19 секунд. При этом было проанализировано 19 471 пакетов и 3 635 420 правил для разрешения зависимостей.

С оптимизацией максимальное использование памяти составило 1.3Гб и 80 секунд. При этом было проанализировано 5 715 пакетов и 2 190 540 правил для разрешения зависимостей.

Неожиданные результаты – уменьшение потребления памяти на 35%, уменьшение кол-ва пакетов для анализа почти в 4, но при этом увеличение времени работы в 4 раза!  Запускал несколько раз. И это точно не проблема с сетью, для тестов я использовал переменную окружения COMPOSER_DISABLE_NETWORK=1, полагаясь исключительно на локально закешированную информацию.

Выводы: если после обновления composer до версии 2. 2 вы внезапно столкнётесь с увеличением времени работы команды composer update, попробуйте отключить новую оптимизацию пула с помощью переменной окружения COMPOSER_POOL_OPTIMIZER=0.

Что дальше? Я проверил issues в репозитории composer и не нашел похожего случая. Некоторые выкладывают свои бенчмарки, бывают просадки по времени установки на 10-15%, но не в 4 раза!

Надо собрать минимально воспроизводимый пример и засабмитить.

Повышение производительности PHP для веб-приложений

Коди Арсено

Обновлено 10 февраля 2023 г.

Как веб-разработчик, вы должны всегда искать способы повысить производительность своих приложений. В связи с растущим спросом на более быстрые и эффективные веб-приложения оптимизация производительности PHP стала важнейшим аспектом веб-разработки. В этом блоге мы рассмотрим некоторые из лучших практик и советов по улучшению производительности PHP для веб-приложений. Лучший инструмент для повышения производительности PHP — это не отдельная программа; это знание какие проблемы искать и как их решать . Это руководство охватывает все, что вам нужно знать, чтобы ваши приложения PHP всегда работали без сбоев.

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

PHP — это язык сценариев, изобретенный Расмусом Лердорфом в 1995 году. Первоначально предназначенный для личного использования разработчиком, «PHP» изначально был аббревиатурой от «Personal Home Page». Первоначально Лердорф разработал PHP как набор сценариев Common Gateway Interface (CGI) для отслеживания посетителей своего личного веб-сайта. Со временем он добавил в язык дополнительные функции, такие как динамическая генерация HTML-страниц, и выпустил его как проект с открытым исходным кодом в 1995.

В 1997 году два разработчика, Энди Гутманс и Зеев Сураски, переписали ядро ​​PHP и превратили его в более надежный и эффективный язык. Эта новая версия PHP, известная как PHP 3, быстро завоевала популярность и стала широко использоваться для разработки динамических веб-страниц.

С тех пор PHP продолжал развиваться и совершенствоваться, добавляя новые функции, такие как улучшенное объектно-ориентированное программирование, улучшенные функции безопасности и улучшенная производительность. Сегодня PHP является одним из наиболее широко используемых языков сценариев на стороне сервера, на котором работают некоторые из крупнейших веб-сайтов в Интернете, включая Facebook, Wikipedia и WordPress.

В последние годы появились новые версии PHP. В 2015 году был выпущен PHP 7.0 с обновлениями, включая улучшения Zend Engine и общее сокращение использования памяти на . На момент написания этой статьи самой новой доступной версией был PHP 8.2, о котором было объявлено в декабре 2022 года. Веб-сайт PHP Classes содержит подробную информацию обо всех изменениях, внесенных в PHP 8.2.

Что такое хорошая производительность PHP?

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

На основе представления phplens на приведенном ниже изображении показан теоретический компромисс между скоростью и масштабируемостью:

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

Аналогией в реальном мире было бы сравнение между спринтером и бегуном по пересеченной местности. Спринтеры намного быстрее в коротких забегах, но устают в более длительных соревнованиях. Бегуны по пересеченной местности поддерживают более медленный, но более стабильный темп, что позволяет им экономить энергию и преодолевать большие расстояния . Два спортсмена лучше подходят для разных ситуаций. Точно так же некоторые сценарии работают лучше в разных сценариях. Выбор правильного для вашего приложения потребует внимательного отношения к вашим пользователям. Возможно, вам придется со временем корректировать сценарии по мере увеличения трафика.

Когда начинать оптимизировать PHP-код

Опытные программисты иногда откладывают тонкую настройку кода на конец проектного цикла. Однако это целесообразно только в том случае, если вы уверены в параметрах производительности вашего PHP-приложения. Более разумный подход — проводить тесты в процессе разработки ; в противном случае вы можете столкнуться с необходимостью переписывать большие куски кода, чтобы ваше приложение функционировало должным образом.

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

Советы по оптимизации PHP-скриптов

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

1. Используйте преимущества собственных функций PHP

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

2. Используйте JSON вместо XML

Говоря об этом, собственные функции PHP, такие как json_encode() и json_decode() , невероятно быстры, поэтому использование JSON предпочтительнее использования XML. Если вы привержены XML, обязательно анализируйте его с помощью регулярных выражений, а не манипуляций с DOM.

3. Получение выгоды от методов кэширования

Memcache особенно полезен для снижения нагрузки на базу данных, в то время как механизмы кэширования байт-кода, такие как OPcache, отлично подходят для экономии времени выполнения при компиляции скриптов.

4. Избавьтесь от ненужных вычислений

При многократном использовании одного и того же значения переменной вычисляйте и присваивайте значение в начале, а не выполняйте вычисления для каждого использования.

5. Используйте

isset()

По сравнению с count() , strlen() и sizeof() , isset() — более быстрый и простой способ определить, является ли значение больше 0.

6. Вырезать ненужные классы

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

7. Отключите уведомления об отладке

Оповещения, которые обращают ваше внимание на ошибки, пригодятся в процессе написания кода, но станут еще одним процессом, замедляющим работу после запуска. Отключите такие уведомления перед выходом в эфир.

8. Закройте соединения с базой данных

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

9. Ограничьте число обращений к базе данных

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

10. Используйте самые сильные функции

str

В то время как str_replace быстрее, чем preg_replace , функция strtr в четыре раза быстрее, чем str_replace .

11. Используйте одинарные кавычки

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

12. Попробуйте три знака равенства

Поскольку === проверяет только закрытый диапазон, это быстрее, чем использование == для сравнений.

Типы узких мест, влияющих на производительность PHP

Изменение сценариев, безусловно, может быть полезным. Однако есть также проблемы, не имеющие ничего общего с кодом, которые также могут снизить производительность PHP. Вот почему разработчикам необходимо глубокое понимание подсистем своего сервера, чтобы выявить и устранить узкие места . Ниже приведены области, которые вы должны проверить, если у вас есть проблемы с производительностью.

1. Сеть

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

2. ЦП

Передача обычных HTML-страниц по сети не истощает ваш ЦП, в отличие от PHP-приложений. В зависимости от ваших требований, вы можете по крайней мере иметь сервер с несколькими процессорами для эффективной обработки вашего PHP-кода.

3. Общая память

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

4. Файловая система

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

5. Управление процессами

Убедитесь, что ваш сервер не перегружен ненужными процессами. Удалите все неиспользуемые сетевые протоколы, антивирусные сканеры, почтовые серверы и драйверы оборудования. Запуск PHP в многопоточном режиме также может привести к лучшему времени отклика.

6. Другие серверы

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

Дополнительные советы по повышению производительности PHP

1.

Воспользуйтесь преимуществом OPcache

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

OPcache — это расширение, сохраняющее скомпилированный код в памяти. Поэтому при следующем выполнении кода PHP проверит временные метки и размеры файлов, чтобы определить, был ли изменен исходный файл. Если это не так, закэшированный код будет запущен.

На изображении ниже показана разница во времени выполнения и использовании памяти между приложением PHP, работающим без кэша, OPcache и eAccelerator (еще один инструмент кэширования PHP).

Источник: PrestaShop

2. Выявление задержек в базе данных

Как обсуждалось выше, проблемы с производительностью не всегда вызваны кодом. Большинство узких мест возникает, когда ваше приложение должно получить доступ к ресурсам. Поскольку на уровень доступа к данным приложения PHP может приходиться до 90 процентов времени выполнения , одним из первых шагов, которые вы должны предпринять, является просмотр всех случаев доступа к базе данных в вашей кодовой базе.

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

3. Очистите файловую систему.

. Проверьте файловую систему на неэффективность и убедитесь, что файловая система не используется для хранения сеансов. Самое главное, следите за кодом, который может вызвать статистику файла, например file_exists() , png() или filetime() . Оставление любой из этих функций в цикле может привести к проблемам с производительностью.

4. Внимательно следите за своими API

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

5. Профилируйте свой PHP

Использование OPcache и управление внешними ресурсами должно быть достаточным для бесперебойной работы большинства приложений; однако, если вы обнаружите, что ваши потребности возрастают, возможно, пришло время профилировать ваш PHP. Полный профиль кода PHP может занять много времени, но он может предоставить вам подробную информацию о производительности вашего приложения. К счастью, существует несколько программ с открытым исходным кодом для профилирования вашего PHP-кода, таких как Xdebug.

Важность мониторинга производительности PHP

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

Программное обеспечение для мониторинга производительности PHP, такое как New Relic, Logtail или PHP Server Monitor, поможет вам немедленно оценить влияние любых изменений, которые вы вносите. Конечно, не менее важно знать, что измерять. Скорость и использование памяти считаются лучшими показателями производительности, поскольку они влияют на время загрузки страницы, которое имеет решающее значение для веб-приложений.

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

Будущее производительности PHP

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

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

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

Настройка производительности PHP: 12 простых советов

Juliet Mendez

23 июля 2018 г. Советы, хитрости и ресурсы для разработчиков

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

Совет. Мгновенно находите ошибки приложений и проблемы с производительностью с помощью Stackify Retrace

Устранение неполадок и оптимизация кода упрощается благодаря встроенным ошибкам, журналам и анализу производительности на уровне кода.

Узкие места

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

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

Профилирование

Одним из советов по настройке производительности PHP является профилирование. Есть много инструментов профилирования, которые вам нужно определить, которые будут соответствовать вашим потребностям. У каждого профилировщика PHP есть свои особенности и преимущества. Я искал в Интернете профилировщик PHP, и у каждого есть свои преимущества и недостатки в его использовании. Stackify имеет префикс, который используется в качестве инструмента профилирования. Он обладает уникальными характеристиками, позволяющими получать непрерывную обратную связь о производительности вашего серверного кода, SQL и других методов, используемых в вашей системе. Лучшая и наиболее впечатляющая функция Prefix заключается в том, что он визуализирует весь конвейер запросов при разработке веб-приложений.

После того, как вы загрузите и установите префикс, вы сможете напрямую увидеть информацию о

  • общем времени, которое потребовалось для обслуживания страницы
  • произошло перехваченное исключение
  • возвращен код состояния 200

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

Оптимизация кода

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

Большинство приложений обычно используют несколько зависимостей, таких как службы PaaS, ElasticSearch, Redis, очереди, базы данных SQL и NoSQL, MongoDB и многое другое. Префикс помогает разработчикам понять, правильно ли их код использует все зависимости. Это также позволяет разработчику узнать, как все зависимости влияют на производительность их приложения.

Оптимизация конфигурации

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

Распределенные вычисления

Распределенные вычисления практикуются для повышения потенциала параллельного выполнения. Этот метод может увеличить нагрузку на общие ресурсы, скорее всего, в системах баз данных. У большинства веб-приложений есть проблемы и проблемы, связанные с задержкой и распределением пропускной способности, но распределенные вычисления могут помочь минимизировать задержку и избежать узких мест. Таким образом, распределенные вычисления могут быть очень полезными для вашей системы из распределенных кэшей. Советы по кэшированию будут следующей темой ниже.

Стратегия кэширования

Хорошая стратегия кэширования может сократить количество операций с базой данных и компиляцию кода. Часто разумно использовать Memcache для снижения нагрузки на базу данных, альтернативный кэш PHP (APC) для кэширования кода операции и оптимизации кода. Когда мы говорим о кэшировании в коде операции PHP, есть много вариантов. К ним относятся APC (бесплатно!), eAccelerator (бесплатно), XCache (бесплатно) и Zend Platform. Сначала Stackify использует управляемый кэш Windows Azure, но было получено несколько жалоб. Поэтому Stackify решил попробовать Redis, который теперь поддерживается Azure. Redis гораздо более рекомендуется, чем управляемый кэш Windows Azure. Мой лучший совет — правильно оценить каждую стратегию кэширования, чтобы увидеть, какая из них лучше всего соответствует вашим потребностям и обеспечивает наилучшие результаты.

Балансировка нагрузки

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

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

В большинстве случаев основная проблема балансировки нагрузки возникает при работе с базой данных и восстановлением резервной копии. В Stackify балансировка нагрузки не представляет особой проблемы, поскольку оптимизирует облако, в частности Azure. Облако предлагает среду аварийного восстановления, настроенную, готовую и соответствующим образом масштабируемую при необходимости.

Избегайте клиентской стороны

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

Безопасность (HTTP/2 через SSL)

Протокол передачи гипертекста — это прикладной протокол, работающий на уровне TCP/IP. HTTP отвечает за установление соединения между сервером и клиентом. Он также отвечает за обработку запросов пользователей на веб-странице или в браузере. С другой стороны, Secure Socket Layer (SSL) — это защищенная версия HTTP. Большая часть связи между веб-сервером и клиентом шифруется с помощью SSL.

При современных технологиях большинство наших браузеров уже поддерживает HTTP/2. Хотя браузеры поддерживают HTTP/2, на самом деле у него есть ограничения на стороне сервера.

SQL

База данных — один из самых фундаментальных элементов веб-приложения. В базе данных SQL вы всегда должны понимать, как правильно функционируют основные ресурсы. SQL Server имеет встроенные динамические представления управления (DMV). Большинство DVM предоставляют данные о статистике запросов, планах выполнения и многом другом. Преимущество DVM заключается в том, что они всегда доступны для предоставления базовой статистики свертки, но не могут визуализировать запросы, которые вызываются с течением времени.

Средства управления производительностью приложений (APM) имеют возможность отслеживать запросы SQL. Retrace предоставляет запросы отслеживания SQL для нескольких поставщиков баз данных, включая SQL Server. Retrace также сообщает, сколько раз выполнялся запрос и какие транзакции его вызывают. Наиболее существенное преимущество использования Retrace заключается в том, что он предоставляет подробные отчеты по приложениям, для каждого приложения и запроса. Он может отображать подробные транзакции о том, как запросы используются в вашем приложении. Это самая важная информация, когда речь идет о настройке производительности PHP для SQL.

Сеть доставки контента (CDN)

Сеть доставки контента (CDN) — это один из наиболее эффективных и действенных способов ускорить доставку веб-сайтов с высоким трафиком и веб-сайтов с глобальным охватом. Многие компании уже используют CDN при работе с крупными веб-сайтами для увеличения географического охвата. Этот метод может уменьшить задержку, уменьшить потребление полосы пропускания и защитить приложения, а также может блокировать спамеров и других сборщиков данных, которые могут атаковать вашу систему.

Обработка ошибок

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

Устранение неполадок — головная боль во время и после разработки, и Stackify разработал решение этой проблемы. Самая мощная функция Retrace — профилирование кода, которое может даже отслеживать ошибки, даже если вы не ведете журнал. Он находит скрытые ошибки в вашем коде и быстро уведомляет вас по электронной почте и SMS, прежде чем они затронут всех ваших клиентов. Мониторинг ошибок в Retrace ограничен не только во время разработки, но и в вашей производственной среде, и он будет автоматически обновлять новые ошибки и журналы.

Сводка

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

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

Дополнительная информация

В этих статьях содержится дополнительная информация о настройке производительности PHP, которая может быть полезна для ваших приложений PHP.

  • 18 инструментов PHP для разработчиков всех уровней
  • Почему преждевременная оптимизация — корень всех зол
  • Оптимизация веб-производительности: 3 основных совета по повышению производительности на стороне сервера и клиента
  • Основы тестирования производительности веб-приложений
  • Сравнение 18 инструментов APM и мониторинга приложений
  • Об авторе
  • Последние сообщения

О Джульет Мендес
Джульет Мендес — профессор кафедры компьютерных и информационных наук и аспирант, специализирующийся на информационных технологиях.

No related posts.