В этой статье я хочу дать несколько советов, следуя которым можно значительно ускорить обработку PHP-скриптов, тем самым, разгрузив сервер хостера от бесполезной работы в пользу более полезной…

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

Дело в том, что текст, заключенный в двойные кавычки сканируется процессором на наличие в нем переменных, а также мнемонических подстановок (например, \n для вставки в текст символа новой строки).

print("Это совершенно обычный текст, но PHP-процессор сканирует его на наличие переменных и мнемонических подстановок перед тем, как вывести. При достаточной длине такой строки, этот процесс занимает значительное время.");

Если же текст заключен в одинарные кавычки, то PHP-интерпретатор послушно выводит его в первозданном виде, даже не думая искать в нем что-то. Это отнимает намного меньшее время, чем в предыдущем примере.

print("PHP-процессор сильно обрадуется, увидев строку, заключенную в одинарные кавычки. А как тут не обрадоваться — ведь не нужно делать бесполезную работу!");

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

$string="Какое счастье не парсить лишний раз эту строку!";

Не заключайте переменные в кавычки

Очень часто приходиться видеть подобную картину.

print("PHP-процессору пришлось обрабатывать эту страницу $time секунд.");

Усвоя мой предыдущий совет, и зная, что PHP-интерпретатору намного легче "склеивать" строки, чем сканировать их на наличие переменных и заменять их на соответствующие этим переменным строки, нетрудно догадаться, что мой предыдущий пример — пример неэффективного использования ресурсов сервера. А теперь порадуем сервер оптимизированным скриптом.

print("PHP-процессор, радуясь жизни, обработал этот скрипт за ".$time." секунд.");

Для тех, кто в танке: склейка строк производится с помощью точки (.), то есть

print("Адрес этого сайта — http://".$_SERVER["HTTP_HOST"]."/!");

выведет текст «Адрес этого сайта — http://argon.com.ru/!»

Используйте минимум переменных

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

Спрашивается, а нахрена занимать лишнюю память, попусту нагружая сервер?.. Намного эффективней сделать так.

print("PHP-процессору доставляет одно удовольствие выводить такие строки.");

Так что, если какая-то строка используется меньше двух раз, присваивать переменной значение этой строки вредно.

Используйте короткие имена переменных

Если в скрипте используются переменные с неоправданно длинными именами, нагрузка на сервер, естественно возрастает.

$windows_xp_edition="Professional";
$windows_xp_build="2600";
$windows_server2003_edition="Standard";
$windows_server2003_build="3200";

Но и слишком лаконичные имена давать тоже не стоит — в будущем при правке скрипта внушительных размеров сто раз вспомнишь мать его создателя, причем не ласковым словом:)

$ifa="Professional";
$ifb="2600";
$ifc="Standard";
Sifd="3200";

Оптимальный же вариант — давать лаконичные, но понятные имена, не превышающие восьми символов.

$wxped="Professional";
$wxpbld="2600";
$ws2k3ed="Standard";
Sws2k3bld="3200";

Используйте вложенные функции

Очень часто приходиться видеть такое дело.

$string=str_replace("\n"," ",$string);
$string=str_replace("\r"," ",$string);
$string=trim($string);
$string=stripslashes($string);
$string=chop($string);
$string=substr($string,0,1024);
print($string);

$string))))),0,1024));

Согласен, выглядит это ужасающе, зато наблюдается ощутимый прирост производительности! Сделать такую штуку очень просто, если начинать с конца, подставляя каждый раз вместо переменной соответствующее ей значение…

Используйте встроенные функции

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

$string=str_replace("<","<",$string);
$string=str_replace(">"",">",$string);
print($string);

Этого же самого можно добиться, если использовать такой код.

print(htmlspecialchars($string));

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

Еще один пример. С помощью этого скрипта можно прочитать содержимое какого-нибудь текстового файла в массив.

$fp=fopen("database.txt","r");
while($array=fgets($fp,1024));
fclose($fp);

Но PHP имеет жутко полезную встроенную функцию file(), которая выполняет абсолютно то же самое, но намного быстрее!

file("database.txt");

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

Используйте собственные функции

Часто необходимо обработать несколько строк по совершенно одинаковому алгоритму. Вот, что делают неопытные программисты…

print(substr(chop(stripslashes(trim(str_replace("\r"," ",str_replace("\n"," ",$string1 ))))),0,1024));
print(substr(chop(stripslashes(trim(str_replace("\r"," ",str_replace("\n"," ",$string2 ))))),0,1024));

А опытные пойдут более простым путем.

function format(&$string){

}
print(format($string1));
print(format($string2));

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

Не создавайте лишних функций

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

function optimize(&$string){
$string=str_replace("&","&",$string);
$string=str_replace(""",""",$string);
$string=str_replace("<;","<",$string);
$string=str_replace(">"",">",$string);
}
print(optimize($string));

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

print(htmlspecialchars($string);

Не используйте лишние функции

Вот пример неэффективного кода.

print("Мой дядя ");
print("самых честных грабил…");

Но его можно очень просто оптимизировать.

print("Мой дядя "."самых честных правил…");

Чувствуете разницу? Поверьте, хостер в этом случае вам будет только благодарен за освободившиеся ресурсы сервера…

Рационально используйте функции

Например, такой скрипт.

print(ereg_replace("нормальный","несчастный",$string));

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

print(str_replace("несчастный","счастливый",$string));

Не дергайте лишний раз обработчик

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

…шапка страницы…
print($заголовок);
?>
…навигация…

?>
…подвал страницы…

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

print("…шапка страницы…".$заголовок."…навигация…");
include("динамический контент");
print("…подвал страницы…");
?>

Продолжение следует

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

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

Удачной вам оптимизации!

• Как оптимизировать сайт и ускорить его работу?
• С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
• Какие технологии следует использовать настраивая сервер или VPS?

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

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

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

В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33 .

Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2 , модули mod_php и php-fpm , версии php php53 и php56 , посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

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

Дано:

• Операционная система Centos 6.7
• Сервер баз данных: MariaDB 10.21
• Все сессии сайтов хранятся в memcache, чтобы убрать влияние скорости установки сессии на скорость работы сайта.
• На всех тестах в качестве frontend выступает web-server nginx 1.93. В случае с Apache2, Nginx выступает в качестве балансировщика, а также для отдачи статики. В конфигурациях без использования Apache2 - непосредственным web-сервером является Nginx
• Конфигурация Nginx и MariaDB содержат множество оптимизаций, направленных на достижение максимальной производительности, но для всех участников теста эти настройки одинаковые и поэтому их влиянием следует пренебречь
• Параметры opcache и apc взяты из рекомендаций Bitrix, так как они оптимальны и универсальны для большинства сайтов

Как будем тестировать?

В локальной сети есть сервер zabbix и его задачи каждую минуту:

• Открывать главную страницу испытуемого сайта, дожидаться определенного содержимого на странице, убеждаться, что ответ от сервера - код 200.
• Следующим шагом идет авторизация в админку сайта, это происходит отправкой соответсвующего POST запроса. Сверка текста и кода ответа на странице с заложенным эталоном. Этот шаг касается почти всех подсистем web-сервера, и во многом его скорость зависит от скорости взаимодействия с базой данных
• Последним шагом является выход из админки сайта, сверка кода ответа и текста на странице выхода
• По итогам каждого шага, zabbix будет скрупулезно замерять и записывать скорость рендеринга php-кода в html понятный браузеру и демонстрировать нам графики полученных результатов
• Для каждого испытуемого будут записываться значения в течение одного часа и в качестве результата будет выступать средние значения за этот час
• Тестирование будет происходить внутри локальной сети, так что влияние на результат скорости интернет-соединения исключено
• Для удобства восприятия, все результаты показываю в порядке возрастания. Т.е. самый первый результат - это самый медленный. Все конфигурации были вынесены под условный номер, это позволит лучше ориентироваться в результатах
• Верхние графики - скорость генерации кода, чем выше значение, тем лучше. Нижние графики - время ответа сервера и чем ниже значение, тем лучше
• Тестируемые сайты живут своей жизнью, в них происходят регулярные операции с базами данных и выполняются задания по расписанию, именно поэтому кривая на графиках может иметь взлеты и падения

Тестирование:

1. Nginx + php-fpm56 без оптимизатора opcache

По архитектуре - это один из самых передовых вариантов. По производительности - наибольшее разочарование.

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

2. Apache2 + mod_php53 без оптимизатора apc

Cамый типичный для хостингов вариант. 90% популярных хостинг-провайдеров используют этот вариант. Хоть php53 давно не поддерживается разработчиками, но в интернете очень много сайтов, до сих пор работающих на этой версии.

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

3. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php56 без оптимизатора opcache

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

К сожалению, далеко не все сайты могут работать полноценно c этой версией. Почти каждая новая версия PHP перестает поддерживать некоторые устаревшие и «небезопасные» функции, нарушая работу «старого» кода.
Сам по себе php56 без оптимизатора довольно медленный, а mod_php склонен падать и занимать всю память на сервере под нагрузкой.

4. Nginx + php-fpm53 без оптимизатора apc

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

5. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php53 + apc

Еще одна распространенная вариация. Очень многие хостинги применяют именно её, при этом либо используют по умолчанию, либо дают возможность включать оптимизатор в своих панелях управления.
Обычно Apache2 оставляют для работы.htaccess-правил, таких как преобразование ссылок и ЧПУ.

Получаем прирост скорости в 3,5 раза, по сравнению с вариантом без использования оптимизатора.
Сам по себе Apache (при использовании его собственного модуля mod_php) расходует для свой работы гораздо больше ресурсов, чем вариант с php-fpm. Apache2 склонен падать, если в одном из его модулей случается сбой или заполнять собой всю оперативную память сервера.

6. Nginx + php-fpm53 + apc

Отличный вариант для сайтов на старых движках, не требующих сложных.htaccess

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

7. Балансировка и статика через Nginx, динамическая часть Apache2 + php-fpm53 + apc

Вариант для устаревших сайтов со сложными.htaccess. Например - старые инсталляции Bitrix.

Это идеальный вариант для устаревших сайтов. Данная конфигурация устойчива к высоким нагрузкам, совместима и достаточно производительна.
Отлично подходит, когда нужны правила.htaccess и дополнительные модули Apache2.
Из недостатков - устаревшая и не обновляемая версия php, но если нет выбора - это самый лучший вариант. Отлично подходит для старой версий Bitrix, Joomla и других распространенных CMS не самых свежих версий.

8. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php56 + opcache

Достаточно производительная, но ресурсоёмкая конфигурация со всеми недостатками mod_php.

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

9. Nginx + php-fpm56 + opcache

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

Это самый лучший вариант для всех современных сайтов. Хорошо держит нагрузку, показывает самый лучший результат с точки зрения производительности. Именно такой вариант я использую, когда стоит задача оптимизировать производительность сайта и увеличить скорость его работы.
Единственный недостаток - это то, что мы не сможем использовать.htaccess и все правила mod_rewrite нужно переписать на синтаксис Nginx.
Также не будут работать модули Apache2. Если таковые используются, то этот вариант не подойдёт.

10. Балансировка и статика через Nginx, динамическая часть Apache2 + php-fpm56+ opcache

Самый лучший вариант для сайтов, где нужен.htaccess. Идеально подходит для свежих версий Bitrix.

Хорошо держит нагрузку за счет php-fpm. Активно использую этот вариант для большинства сайтов.

В качестве итогов:

• В реальной жизни, все варианты с Apache2 могут быть медленней, так как в своих тестах я умышленно передал отдачу статики Nginx. Это сделано, чтобы исключить влияние скорости отдачи статики на результаты замера скорости работы интерпретатора PHP. Одной из наиболее слабой стороной Apache2 и при этом сильной Nginx - является скорость отдачи статики. Особенно, это заметно на высоких нагрузках. Кроме того, Nginx менее подвержен атаке «медленных соединений»
• mod_php очень быстро занимает всю доступную память сервера и теряет производительность на нагрузках
• php-fpm расходует память значительно эффективнее, безопаснее и гибче в настройках. В ряде случаев он быстрее и без высоких нагрузок.
• Тест имеет узкую специфику, тут мы увидели особенности работы движка Drupal, другие могут вести себя иначе, но общая тенденция будет такой же.

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

Если у вас возникнут вопросы, трудности или потребуется совет:
Мои контакты в

Всем доброго времени суток.

1. Если метод может быть статическим, объявляйте его статическим.
2. echo быстрее, чем print.
3. Передавайте в echo несколько параметров, вместо того, чтобы использовать конкатенацию строк.
4. Устанавливайте максимальное количество проходов ваших циклов for до цикла, а не во время его выполнения.
5. Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы.
6. Остерегайтесь магических методов, таких как __set, __get, __autoload.
7. require_once дорого обходится.
8. Указывайте полные пути в конструкциях include/require, меньше времени будет тратится на поиск файла.
9. Если вам необходимо определить время, когда скрипт был запущен, используйте $_SERVER[’REQUEST_TIME’] вместо time().
10. Старайтесь использовать strncasecmp, strpbrk и stripos вместо регулярных выражений.
11. str_replace быстрее, чем preg_replace, но strtr быстрее, чем str_replace.
12. Если функция, как и функции замены строк, может принимать в аргументы как массивы, так и одиночные символы, и если ваш список аргументов не слишком длинный, подумайте над тем, чтобы записать несколько одинаковых выражений замены, проходя один символ за раз, вместо одной строки кода, которая принимает массив как аргумент поиска и замены
13. Лучше выбирать утверждения при помощи конструкции else if, чем использовать несколько конструкций if.
14. Подавление ошибок при использовании @ работает очень медленно.
15. Используйте модуль Apache mod_deflate.
16. Закрывайте свои соединения с БД, когда закончите работать с ними.
17. $row["id"] в семь раз быстрее, чем $row.
18. Сообщения об ошибках дорого стоят
19. Не используйте функции внутри условия цикла for, например как здесь: for ($x=0; $x < count($array); $x). В данном случае функция count() будет вызываться с каждым проходом цикла.
20. Инкремент локальной переменной в методе - самый быстрый. Почти также работает инкремент локальной переменной в функции.
21. Инкремент глобальной переменной в два раза медленее, чем локальной.
22. Инкремент свойства объекта (т.е. $this->prop++) в три раза медленнее, чем локальной переменной.
23. Инкремент неопределённой переменной в 9-10 раз медленнее, чем заранее инициализированной.
24. Объявление глобальной переменной, без использования её в функции, также замедляет работу (примерно на ту же величину, что и инкремент локальной переменной). Вероятно, PHP осуществляет проверку на существование переменной.
25. Скорость вызов метода, судя по всему, не зависит от количества методов, определённых в классе. Я добавил 10 методов в тестовый класс (до и после тестового метода), без изменения производительности.
26. Методы в производных классах работают быстрее, чем они же, определённые в базовом классе.
27. Вызов функции с одним параметром и пустым телом функции в среднем равняется 7-8 инкрементам локальной переменной ($localvar++). Вызов похожего метода, разумеется, около 15 инкрементов.
28. Ваши строки, определённые при помощи ", а не ", будут интерпретироваться чуть быстрее, т.к. PHP ищет переменные внутри "..", но не "...". Конечно, вы можете использовать это только тогда, когда в вашей строке нет переменных.
29. Строки, разделённые запятыми, выводятся быстрее, чем строки, разделённые точкой. Примечание: это работает только с функцией echo, которая может принимать несколько строк в качестве аргументов.
30. PHP-скрипты будут обрабатываться, как минимум, в 2-10 раз медленнее, чем статические HTML-страницы. Попробуйте использовать больше статических HTML-страниц и меньше скриптов.
31. Ваши PHP-скрипты перекомпилируются каждый раз, если скрипты не кэшируются. Кэширование скриптов обычно увеличивает производительность на 25-100% за счёт удаления времени на компиляцию.
32. Кэшируйте, насколько это возможно. Используйте memcached — это высокопроизводительная система кэширования объектов в памяти, которая повышает скорость динамических веб-приложений за счёт облегчения загрузки БД. Кэшированный микрокод полезен тем, что позволяет вашему скрипту не компилироваться снова для каждого запроса.
33. При работе со строками, когда вам понадобится убедиться в том, что строка определённой длины, вы, разумеется, захотите использовать функцию strlen(). Эта функция работает очень быстро, ведь она не выполняет каких-либо вычислений, а лишь возвращает уже известную длину строки, доступную в zval-структуре (внутренняя структура C, используемая при работе с переменными в PHP). Однако потому, что strlen() — функция, она будет работать медленно за счёт вызова некоторых операций, таких как приведение строки в нижний регистр и поиска в хэш-таблице, только после которых будут выполнены основные действия функции. В некоторых случаях вы сможете ускорить свой код за счёт использования хитрости с isset().
    Было: if (strlen($foo) < 5) { echo «Foo is too short»; }
    Стало: if (!isset($foo{5})) { echo «Foo is too short»; }
    Вызов isset() быстрее, чем strlen() потому, что, в отличие от strlen(), isset() - не функция, а языковая конструкция. За счёт этого isset() не имеет практически никаких накладных расходов на определение длины строки.
34. Инкремент или декремент переменной при помощи $i++ происходит немного медленнее, чем ++$i. Это особая специфика PHP, и не нужно таким образом модифицировать свой C и Java-код думая, что он будет работать быстрее, этого не произойдёт. ++$i будет быстрее в PHP потому, что вместо четырёх команд, как в случае с $i++, вам понадобится только три. Пост-инкремент обычно используется при создании временных переменных, которые затем увеличиваются. В то время, как пре-инкремент увеличивает значение оригинальной переменной. Это один из способов оптимизации PHP-кода в байт-код утилитой Zend Optimizer. Тем не менее, это хорошая идея, поскольку не все байткод-оптимизаторы оптимизируют это, также остаётся немало скриптов, работающих без оптимизации в байткод.
35. Не всё должно быть ООП, часто это излишне, поскольку каждый метод и объект занимает много памяти.
36. Не определяйте каждую структуру данных как класс, массивы бывают очень полезны
37. Не слишком разбивайте методы. Думайте, что вы действительно будете повторно использовать.
38. Вы всегда можете разбить код на методы позже, по необходимости.
39. Используйте бесчисленное количество предопределённых функций.
40. Если в вашем коде есть функции, выполняющиеся очень долго, обдумайте их написание на C в виде расширения
41. Профилируйте свой код. Профилирование покажет вам, как много времени выполняются части вашего кода.
42. mod_gzip — модуль Apache, который позволяет сжимать ваши данные на лету и может уменьшить объем передаваемых данных до 80%.