RSS
 

 

В продолжение темы оптимизации PHP и ускорению сайтов.

28 Янв
В продолжении стати Сборник советов и фактов по оптимизации 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 и другие)

 
 

Метки: , 28.01.2011