Какие хорошие рекомендации по производительности PHP?

Я слышал о некоторых рекомендациях по производительности для PHP, таких как использование strtr() over str_replace() over preg_replace() в зависимости от ситуации.

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

Изменить: я не говорю об использовании вещей, которые делают код менее удобочитаемым, например !isset($foo{5} over strlen($foo) < 5, я говорю о таких вещах, как использование preg_-функций над функциями ereg_ для регулярного выражения.

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

Ответ 1

Этот вопрос действительно расплывчатый. Когда вы хотите оптимизировать свой script, сначала проверьте свою базу данных и попытайтесь оптимизировать свои алгоритмы. Не так уж много чистых рекомендаций по производительности PHP, которые будут иметь значение. Давайте посмотрим:

  • Перекрестные переменные быстрее, чем просто помещать их в строку с двумя кавычками.

    $var = 'Hello ' . $world; // is faster than
    $var = "Hello $world"; // or
    $var = "Hello {$world}";
    

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

  • При использовании цикла, если ваше условие использует константу, поставьте ее перед циклом. Например:

    for ($i = 0; $i < count($my_array); $i++)
    

Это будет вычислять count ($ my_array) каждый раз. Просто добавьте дополнительную переменную перед циклом или даже внутри:

for ($i = 0, $count = count($my_array); $i < $count; $i++)
  • Самое худшее - это, безусловно, запросы внутри циклов. Либо из-за недостатка знаний (попытки имитировать JOIN в PHP), либо просто потому, что вы не думаете об этом (многие вставляют в цикл, например).

    $query = mysql_query("SELECT id FROM your_table");
    while ($row = mysql_fetch_assoc($query)) {
        $query2 = mysql_query("SELECT * FROM your_other_table WHERE id = {$row['id']}");
        // etc
    }
    

Никогда делать это. Это простая ВХОДНАЯ ВСТУПЛЕНИЕ.

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

P.S. Я начал писать этот ответ, когда его не было, могут быть некоторые вещи, уже упомянутые в ссылках.

Изменить: по какой-то причине я не могу правильно отформатировать код. Я действительно не понимаю, почему.

Ответ 2

ОПТИМИЗАЦИЯ ПЕЧАТИ - КОРТ ВСЕГО ЗЛА

И это самый важный совет, который вам нужен. Если в какой-то момент у вас возникли проблемы с производительностью, профилируйте приложение, обнаружите уязвимые области и пришли сюда, чтобы снова спросить:)

Ответ 3

Если вы ищете хорошие советы о том, как программировать код, чтобы он был наиболее эффективным, обратитесь к http://www.phpbench.com/. Они показывают много сравнений по различным аспектам программирования, поэтому вы можете использовать лучшие методы, соответствующие вашим потребностям. Как правило, все зависит от того, хотите ли вы экономить на мощности обработки или использовании памяти.

http://talks.php.net/show/digg/0 - беседа, предоставленная самими PHP по производительности

http://code.google.com/speed/articles/optimizing-php.html - Рекомендации Google о том, как ускорить ваши приложения.

Чаще всего ваши проблемы не связаны с PHP, но будут проблемы с MySQL или http-запросами.

Ответ 4

Это может показаться немного экстремальным, но...

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

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

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

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

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

Общий мониторинг ресурсов также полезен. Например, если ваше использование внешнего процессора составляет менее 5%, зачем делать что-либо, если задержка не возникает где-то? Это также помогает дать вам больше советов о том, где PHP застопорился (где узкие места, сеть, жесткий диск ввода-вывода, память, процессор и т.д.). Также имейте в виду, что сегодня аппаратное обеспечение действительно действительно дешево, и бросать аппаратное обеспечение при проблемах может оказаться намного более эффективным. Такой мониторинг снова позволяет использовать целенаправленный подход. Я старик с опытом ограниченного оборудования, и я могу рассказать вам в тот день, когда я использовал преждевременную оптимизацию. Это даст хороший доход, но сегодня этого просто нет. Обычно я могу потратить месяц на то, чтобы что-то оптимизировать, и за ту же стоимость человеко-часов купите некоторое оборудование, которое может привести к увеличению производительности в два раза без больших усилий. Я бы не стал слишком далеко, аппаратное обеспечение не решает все, но смотря на это так, независимо от того, сколько вы пытаетесь оптимизировать, есть жесткие ограничения, представленные аппаратным обеспечением, поэтому, если вы заходите слишком далеко, пытаясь заставить его работать с плохим оборудованием вы быстро попадете в область убывающих результатов.

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

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

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

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

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

В некоторых случаях я понимаю важность или преимущество упреждающей и микро-оптимизации. Однако на самом деле, как правило, практически невозможно достичь такого рода выигрышей, которые вы ожидаете (опять же, я должен сказать, что самое большое влияние, которое вы можете иметь, если вы действительно заботитесь о производительности, - это вообще отказаться от PHP, в основном это можно увидеть, как спросить, как могу ли я сделать улитку быстро, ответ - если скорость так важна, используйте что-то построенное для этого). Даже опытным и знающим может быть трудно с этим. Почти никто не понимает это в первый раз. Поэтому, когда вы действительно хотите потратить усилия, это ремонтопригодность. Держите свой код в порядке, порядке и хорошо организованном. Используется VCS, чтобы иметь возможность легко удалять вещи (не комментируйте код или переименовывать файлы в .old). Удостоверьтесь, что вы остаетесь СУХОЙ и, как правило, придерживаетесь хороших практик TIAS, Google и т.д.

Ответ 5

Обычно предварительная зрелая оптимизация является плохой идеей. Это действительно не имеет значения, когда вы делаете код быстрее на 0,5 мс, когда один запрос SQL занимает 80 мс.

Вы должны профилировать код и сосредоточиться на шейках бутылки, а затем попробовать такие вещи, как кеширование (статические, APC, Memcached). Микрооптимизации - это последний шаг, когда у вас есть идеальный дизайн приложения и по-прежнему требуется большая производительность от определенных модулей/функций.

Ответ 6

Предположим, что у вас есть массив слов.
Например: $words=array('banana','cat','tuna','bicycle','kitten','caffeine');

И тогда у вас есть поисковый запрос для поиска, например: $find='ca';

И вы хотите знать все элементы, которые начинают с этим термином.

Обычно мы делаем следующее:

foreach($words as &$word)if(preg_match('@^'.$find.'@',$word))echo $word,'<br>';

Или самый быстрый способ:

foreach($words as &$word)if(strpos($find,$word)==0)echo $word,'<br>';

Но почему бы нам просто не сделать так:

foreach($words as &$word)if($find==($find&$word))echo $word,'<br>';

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

Ответ 7

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

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

Сосредоточьтесь на скорости между PHP и вашей базой данных. Сосредоточьтесь на размере разметки на выходе. Сосредоточьтесь на кеше.

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

Ответ 8

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

Если вы обнаружите, что ваша веб-страница занимает 250 мс для рендеринга, это достаточно быстро? Если нет, то как быстро это должно быть? Он не достигнет нуля. Вам нужно, чтобы он составлял 200 мс?

Используйте инструмент, например XDebug (http://www.xdebug.org/), чтобы определить, где находятся горячие точки в вашем коде. Скорее всего, вы обнаружите, что ваше приложение занимает 80% своего времени, обращаясь к базе данных. Если ваше приложение принимает 200 мс для получения данных из базы данных и 0,01 мс в вызовах str_replace, то ускорения перехода на strtr или использование echo вместо print настолько малы, что не имеют значения.

Мечта о возможности использовать strtr вместо str_replace и стать заметной, измеримые ускорения - это фантазия.

Ответ 9

Этот вопрос (и ответы) довольно устарел, однако он поднялся высоко в списках, когда я googled для "производительности PHP".

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

Первым шагом является определение того, что занимает больше всего времени - и для веб-приложения вы должны начать в браузере. У Google Chrome хороший профилировщик и для Firefox есть расширение Firebug. Если медленный бит - это PHP, тогда копайте дальше с помощью профайлера, такого как xdebug, но помните, что это будет охватывать любую базу данных и файл IO.

Ответ 10

Это очевидно, но создание объектов также дорого, поэтому, например, если вам нужна временная метка, выполняющая время(), она удваивается быстрее, чем выполнение date_create() → getTimestamp.

for ($a=1;$a<1000000;$a++) {
  $e = time(); // In my tests about 2x faster than:
  //$e = date_create()->getTimestamp();
}

Ответ 11

  • Использование собственных функций PHP
  • Использовать одиночные кавычки
    Использование одинарных кавычек ('') выполняется быстрее, чем использование двойных кавычек ("")
  • Use = = =
    Используйте "= = =" вместо "= =",
  • Рассчитать только один раз Вычислите и присвойте значение переменной, если это значение используется много времени, а не вычисляет его снова и снова, когда оно используется.

    Например, следующее ухудшит производительность.

    for( $i=0; i< count($arrA); $i++){
    
     echo count($arrA);
    }
    

    script ниже будет работать намного лучше.

    $len = count($arrA);
    
    for( $i=0; i< $len; $i++){
    echo $len;
    

    }

  • Используемые случаи переключения

  • Использовать JSON

Используйте JSON вместо XML во время работы с веб-службами, поскольку есть встроенная функция php, такая как json_encode() и json_decode(), которые очень быстрые. 7. Используйте isset Используйте isset(), где это возможно, вместо использования count(), strlen(), sizeof(), чтобы проверить, превышает ли значение значение больше.

  1. Перекрестные переменные быстрее, чем просто помещать их в строку с двумя кавычками.

Ответ 12

  • Пожалуйста, рассмотрите привязывающие переменные к statament базы данных вместо того, чтобы помещать их в предложение SQL. Тот же метод аналогичен для СУБД Oracle и MySQL, а может быть и для других (синтаксический анализ, привязка, выполнение). Запрос с связанными переменными быстрее готов для их запуска более одного раза.
  • Если вам нужно добавить несколько строк, вы можете использовать один объемный DML.

Ответ 13

66 Советы по оптимизации вашего PHP

Вот точки Уэббера:

  • Использовать JSON вместо XML.
  • Можно также использовать sprintf вместо переменных, содержащихся в двойных кавычках, примерно в 10 раз быстрее.
  • Избегайте проблемы с вводом заголовка функции PHP mail().
  • Если метод может быть статическим, объявите его статическим. Улучшение скорости - в 4 раза.
  • эхо быстрее, чем печать. (* сравнить со списком от phplens от John Lim)
  • Используйте несколько параметров echos вместо конкатенации строк.
  • Установите максимальное значение для ваших for-циклов до и не в цикле.
  • Отключите ваши переменные до свободной памяти, особенно больших массивов.
  • Избегайте магии как __get, __set, __autoload
  • require_once() стоит дорого
  • Использовать полные пути в include и требует, меньше времени на устранение путей ОС.
  • Если вам нужно узнать время начала script, $_SERVER [REQUEST_TIME] предпочтительнее времени()
  • Посмотрите, можете ли вы использовать strncasecmp, strpbrk и stripos вместо regex
  • str_replace быстрее, чем preg_replace, но strtr быстрее, чем str_replace, в 4 раза
  • Если функция, такая как функция замены строк, принимает как массивы, так и одиночные символы в качестве аргументов, и если список аргументов не слишком длинный, подумайте над написанием нескольких избыточных операторов замещения, передавая по одному символу за раз, а не по одному строка кода, которая принимает массивы в качестве параметров поиска и замены.
  • Лучше использовать операторы select, чем команды multi if, else if.
  • Подавление ошибок с помощью @очень медленно.
  • Включить apaches mod_deflate
  • Закройте соединения с базой данных, когда вы сделали с ними
  • $row [id] в 7 раз быстрее, чем $row [id]
  • Сообщения об ошибках стоят дорого
  • Не используйте функции внутри цикла for, например, для ($ x = 0; $x < count ($ array); $x) Функция count() вызывается каждый раз.
  • Приращение локальной переменной в методе является самым быстрым. Почти так же, как вызов локальной переменной в функции.
  • Приращение глобальной переменной в 2 раза медленнее, чем локальная переменная.
  • Приращение свойства объекта (например, $this- > prop ++) в 3 раза медленнее локальной переменной.
  • Приращение локальной переменной undefined в 9-10 раз медленнее, чем предварительно инициализированная.
  • Просто объявление глобальной переменной без использования ее в функции также замедляет работу (примерно на ту же сумму, что и приращение локального var). PHP, вероятно, проверяет, существует ли глобальная сеть.
  • Вызов метода не зависит от количества методов, определенных в классе, потому что я добавил еще 10 методов для тестового класса (до и после тестового метода) без изменения производительности.
  • Методы в производных классах выполняются быстрее, чем те, которые определены в базовом классе.
  • Вызов функции с одним параметром и пустым телом функции занимает примерно то же время, что и операции 7-8 $localvar ++. Аналогичным вызовом метода является, конечно, около 15 $операций localvar ++.
  • Окружение вашей строки с помощью "вместо" заставит вещи интерпретироваться немного быстрее, поскольку php ищет переменные внутри "...", но не внутри "..." Конечно, вы можете сделать это только тогда, когда вам не нужны переменные в строке.
  • При повторном повторении строк их быстрее разделять их запятой, а не точкой. Примечание. Это работает только с эхом, который является функцией, которая может принимать несколько строк в качестве аргументов.
  • PHP script будет обслуживаться как минимум в 2-10 раз медленнее, чем статическая HTML-страница от Apache. Попробуйте использовать более статические HTML-страницы и меньше скриптов.
  • Ваши PHP-скрипты перекомпилируются каждый раз, если скрипты не кэшируются. Установите продукт кэширования PHP, чтобы увеличить производительность на 25-100%, удалив время компиляции.
  • Кэш как можно больше. Использование memcached - memcached - высокопроизводительная система кэширования объектов памяти, предназначенная для ускорения динамических веб-приложений за счет уменьшения загрузки базы данных. Ключи OP-кода полезны, поэтому ваш script не должен компилироваться по каждому запросу
  • При работе со строками вам нужно проверить, что строка имеет определенную длину, которую вы, по понятным причинам, хотели бы использовать функцию strlen(). Эта функция довольно быстро, так как ее операция не выполняет никаких вычислений, а просто возвращает уже известную длину строки, доступной в структуре zval (внутренняя структура C, используемая для хранения переменных в PHP). Однако, поскольку функция strlen() является функцией, она все же несколько медленная, потому что вызов функции требует нескольких операций, таких как поиск в нижнем регистре и хэш-таблице, за которыми следует выполнение указанной функции. В некоторых случаях вы можете улучшить скорость своего кода, используя тэг isset().
    Ex.

    view sourceprint? 1.if(strlen ($ foo) < 5) {echo "Foo слишком короткий"; }

    против.

    view sourceprint? 1.if(! isset ($ foo {5})) {echo "Foo слишком короткий"; }

    Вызов isset() происходит быстрее, чем strlen(), потому что в отличие от strlen(), isset() - это языковая конструкция, а не функция, означающая, что ее выполнение не требует поиска функций и строчных букв. Это означает, что у вас практически нет накладных расходов поверх фактического кода, который определяет длину строк.

  • При возрастании или уменьшении значения переменной $i ++ происходит медленнее, чем ++ $i. Это что-то специфичное для PHP и не относится к другим языкам, поэтому не переделывайте код C или Java, думая, что он внезапно станет быстрее, обычно. ++ $i, скорее всего, быстрее в PHP, потому что вместо 4-х опкодов, используемых для $i ++, вам нужно только 3. Инкремент отправки фактически приводит к созданию временного var, который затем увеличивается. В то время как предварительная инкрементация увеличивает исходное значение напрямую. Это одна из оптимизаций, которые оптимизированы для оптимизации кода, такие как Zends PHP optimizer. По-прежнему стоит иметь в виду, что не все оптимизаторы opcode выполняют эту оптимизацию, и есть много интернет-провайдеров и серверов, работающих без оптимизатора опций.
  • Не все должно быть ООП, часто это слишком много накладных расходов, каждый метод и вызов объекта потребляют много памяти.
  • Не используйте каждую структуру данных как класс, массивы также полезны.
  • Не используйте слишком много методов, подумайте, какой код вы действительно будете использовать повторно
  • Вы всегда можете разделить код метода позже, когда это необходимо
  • Использовать бесчисленные предопределенные функции
  • Если у вас есть очень много времени в вашем коде, подумайте о том, как писать их как расширения C
  • Профилируйте свой код. Профилировщик показывает вам, какие части вашего кода потребляют сколько раз. Отладчик Xdebug уже содержит профилировщик. Профилирование показывает вам узкие места в обзоре.
  • mod_gzip, который доступен как модуль Apache, сжимает ваши данные "на лету" и может уменьшить данные для передачи до 80%
  • Отличная статья об оптимизации php от John Lim

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

Еще одна хорошая практика для лучшей производительности PHP, как написано на cluesheet.com:

  • Используйте одиночные кавычки над двойными кавычками.
  • Использовать переключатель над множеством операторов if.
  • Следует избегать тестирования условных циклов с помощью функциональных тестов на каждую итерацию, например. для ($ я = 0; я <= подсчет ($ х); $я ++) {...
  • Использовать foreach для объединения коллекций/массивов. Элементы PHP4 являются байными, больше, чем элементы PHP5 являются byref
  • Учтите использование метода Singleton при создании сложных классов PHP.
  • Использовать POST через GET для всех значений, которые завершатся в базе данных по причинам производительности пакета TCP/IP.
  • Использовать ctype_alnum, ctype_alpha и ctype_digit над регулярным выражением для тестирования типов значений формы по причинам производительности.
  • Используйте полные пути к файлам в рабочей среде по сравнению с basename/fileexists/open_basedir, чтобы избежать сбоев производительности файловой системы, которая должна искать путь к файлу. Определенные значения сериализации и/или кеша в массиве $_SETTINGS. $_SETTINGS [ "УХО" ] = УХО (./);
  • Использовать require/include над require_once/include_once для обеспечения правильного кэширования кода операции.
  • Использовать tmpfile или tempnam для создания файлов temp/filenames
  • Использовать прокси-сервер для доступа к веб-службам (XML или JSOM) в чужих доменах с помощью XMLHTTP, чтобы избежать междоменных ошибок. например. foo.com ↔ XMLHTTP ↔ bar.com
  • Использовать error_reporting (E_ALL); во время отладки.
  • Установите Apache allowoverride на "none", чтобы улучшить производительность Apache при доступе к файлам/каталогам.
  • Использовать быстрый файловый сервер для обслуживания статического содержимого (thttpd). static.mydomain.com, dynamic.mydomain.com
  • Сериализовать параметры приложения, такие как пути, в ассоциативный массив и кешировать или сериализовать этот массив после первого выполнения.
  • Использовать буферизацию управления выводами PHP для кэширования страниц страниц с тяжелым доступом
  • Используйте PDO для подготовки к инструкциям для родных db. mysql_attr_direct_query = > 1
  • НЕ использовать выбор шаблона SQL. например. SELECT *
  • Использовать логику базы данных (запросы, объединения, представления, процедуры) через loopy PHP.
  • Используйте синтаксис ярлыков для SQL-вставки, если не используете параметры параметров PDO. например. INSERT INTO MYTABLE (FIELD1, FIELD2) VALUES (( "x", "y" ), ( "p", "q" ));

Ref - gist.github.com

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

Надеюсь, это поможет вам.