27 янв. 2011 г.

Сборник советов и фактов по оптимизации 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. Топик не претендует на инновационность и является лишь взглядом на оптимизацию со стороны разработки больших проектов.