Оптимизация PHP скриптов // PHP. Оптимизация php


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

Вы здесь: Главная - PHP - PHP Основы - Оптимизация PHP-кода

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

Правило №1: Старайтесь не использовать длинные переменные

Действительно, если длина имени переменной больше 4-х символов, то скорость выполнения начинает падать. Особенно это заметно при длине от 8-ми символов.

Правило №2: Старайтесь не использовать цикл foreach

Цикл foreach используйте только для перебора ассоциативных массивов, а для всех остальных случаев жизни используйте только for или while. Выигрыш в скорости 25-30%.

Правило №3: Старайтесь переменные выносить за пределы кавычек

Давайте разберём такой код:

<?php   $x = 5;   $y = "5$x5";   $z = "5".$x."5"; ?>

Если проверить скорость выполнения, то можно заметить, что присвоение $y идёт примерно на 20% медленее, чем присвоение переменной $z. Особенно это актуально, если вместо переменной $x поставить элемент двумерного массива.

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

Предыдущая статья Следующая статья

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,то Вы можете подписаться на обновления: Подписаться на обновления

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

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

  1. Кнопка: <a href="https://myrusakov.ru" target="_blank"><img src="https://myrusakov.ru//images/button.gif" alt="Как создать свой сайт" /></a>

    Она выглядит вот так:

  2. Текстовая ссылка:<a href="https://myrusakov.ru" target="_blank">Как создать свой сайт</a>

    Она выглядит вот так: Как создать свой сайт

  3. BB-код ссылки для форумов (например, можете поставить её в подписи): [URL="https://myrusakov.ru"]Как создать свой сайт[/URL]

myrusakov.ru

Оптимизация 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. Используйте кэширование данных получаемых из БД или XML4. Используйте кэширование готовых HTML страничек5. Установите какой-нить оптимизатор PHP (XCache или Zend Optimizer)

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

September 26, 2007

anton.shevchuk.name

Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP

Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:

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

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

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

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

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

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

Продолжение этой статьи: Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache

Так же вы можете прочитать другие мои публикации на тему «Идеального» кластера

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

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

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

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. Активно использую этот вариант для большинства сайтов.

Главная страница тестового сайта
Номер конфигурации Архитектура Средняя скорость загрузки кб. Средний отклик мс.
1 Nginx + php-fpm56 без оптимизатора opcache 77,04 103,6
2 Apache2 + mod_php53 без оптимизатора apc 78,79 103,98
3 Apache2 + mod_php56 без оптимизатора opcache 78,85 102,38
4 Nginx + php-fpm53 без оптимизатора apc 81,55 97,88
5 Apache2 + mod_php53 + apc 303,37 29,36
6. Nginx + php-fpm53 + apc 312,33 24,73
7. Apache2 + php-fpm53 + apc 339,63 23,32
8. Apache2 + mod_php56 + opcache 484,96 16,91
9. Nginx + php-fpm56 + opcache 546,34 14,08
10. Apache2 + php-fpm56+ opcache 571,14 13,78
Авторизация в админке тестового сайта
Номер конфигурации Архитектура Средняя скорость загрузки кб. Средний отклик мс.
1 Nginx + php-fpm56 без оптимизатора opcache 67,51 239,01
2 Apache2 + mod_php53 без оптимизатора apc 64,61 257,51
3 Apache2 + mod_php56 без оптимизатора opcache 66,75 242,42
4 Nginx + php-fpm53 без оптимизатора apc 68.79 233.15
5 Apache2 + mod_php53 + apc 173,81 94,26
6. Nginx + php-fpm53 + apc 173,3 91,3
7. Apache2 + php-fpm53 + apc 182,1 90,5
8. Apache2 + mod_php56 + opcache 218,35 77,55
9. Nginx + php-fpm56 + opcache 252,83 62,25
10. Apache2 + php-fpm56+ opcache 262,8 60,85
Выход из админки тестового сайта
Номер конфигурации Архитектура Средняя скорость загрузки кб. Средний отклик мс.
1 Nginx + php-fpm56 без оптимизатора opcache 41,01 184,49
2 Apache2 + mod_php53 без оптимизатора apc 42,42 188,97
3 Apache2 + mod_php56 без оптимизатора opcache 42,06 188,37
4 Nginx + php-fpm53 без оптимизатора apc 45,48 169,15
5 Apache2 + mod_php53 + apc 190,1 41,87
6. Nginx + php-fpm53 + apc 185,92 41,24
7. Apache2 + php-fpm53 + apc 202,78 39,21
8. Apache2 + mod_php56 + opcache 315,56 26,23
9. Nginx + php-fpm56 + opcache 373,19 20,43
10. Apache2 + php-fpm56+ opcache 381,21 20,57
В качестве итогов:

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

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

habr.com


Prostoy-Site | Все права защищены © 2018 | Карта сайта