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

По следам статьи «Сборник советов и фактов по оптимизации PHP-скриптов»

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






Самое главное правило, которое надо помнить при оптимизации: преждевременная оптимизация — это корень всех бед.

Советы по оптимизации

Понятный код в 99% случаев лучше оптимизированного

• Очень часто код, который вы написали, будет использовать кто-то другой и время, которое он потратит на понимание вашего кода, очень важно
• Старайтесь под отдельный класс создавать отдельный файл
  
  Да, у вас увеличится количество require (include, require_once, include_once), но зато найти определенный класс будет во много раз проще
• Не пытайтесь использовать короткие имена для классов и переменных
  
  Если вместо $videos вы назовете переменную $a, то в скорости выигрыш будет смешным, зато понимание кода резко упадет и увеличится вероятность ошибки, которую сложно отловить.
• Если вам действительно важна скорость, то напишите простой скрипт-сборщик своего кода для продакшена (также можно посмотреть в сторону компиляции PHP)
  
  Но помните, что в этом случае, при появлении какой-нибудь проблемы на продакшене, ее будет тяжелее отлаживать (если вы замените название переменных, к примеру)

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

• Намного проще сбросить данные нескольких простых запросов, чем одного сложного
  
  К примеру, для получения информации о пользователе в комментариях (при отрисовки ника) проще сделать отдельный запрос (конечно же закешировав его), чем JOIN на таблицу пользователей
• Если возможно сделать расчет каких-нибудь данных на стороне PHP без ощутимых потерь во времени, то лучше сделать это
  
  Масштабировать базу тяжело. Масштабировать бэк-энды намного проще.
• При разнесении таблиц на различные сервера БД, запросы на JOIN вообще могут перестать работать

Старайтесь кешировать все данные, которые приходят к вам из БД

• Даже если у вас динамически меняющийся контент, его все-равно можно положить в кэш
  
  К примеру, список текущих трансляций пользователей можно кешировать на 1 минуту и это заметно снижает нагрузку на БД (при условии что страница трансляций очень посещаема). Правда в случае кеширования на небольшое время необходимо обязательно обратить внимание на то, чтобы несколько бэк-эндов не полезли обновлять кэш одновременно
• Используйте механизмы сброса кеша
  
  
  Пользователь обновил информацию о себе? Значит надо сбросить кеши, которые имеют к нему отношение.

Советы по архитектуре

• Для отдачи статического содержимого используйте nginx или lighttpd
• Для ускорения работы PHP можно использовать например eAccelerator
• Используйте gzip
• Объединяйте js и css файлы в один
  
  Также очень хорошо использовать различные компрессоры, чтобы уменьшить объем этих файлов (Google Closure Tools, YUI Compressor и другие)

P.S. Топик не претендует на инновационность и является лишь взглядом на оптимизацию со стороны разработки больших проектов.