И это касается каждого разработчика и каждого модуля.Как же на практике проходит оптимизация?
Есть несколько направлений, в которых идет работа:
* оптимизация кода
* оптимизация запросов, числа запросов, цены запросов, объемов передаваемых данных
* оптимизация архитектуры
* уменьшение объемов исполняемого и компилируемого кода
* поиск новых решений
Как я уже говорил, одна из задач по оптимизации заключалась в том, чтобы оптимизировать работу базовой версии продукта Старт. Про оптимизацию по SQL запросам я уже писал в первых постах. Результаты отличные. Стоит рассказать немного, как идет оптимизация кода.
Мы используем один из лучших профилировщиков для PHP xdebug
Продукт загоняется в профилировщик, запускается нагрузка на тестовый сайт и изучается, какие функции больше всего занимают в процентах времени исполнения.
Функции оптимизируются до тех пор, пока не оказываются "внизу" топа.
И так опять и опять, фактически неделями, повторяя после каждого цикла оптимизации того или иного модуля. Так избавляемся от лишних вызовов, где-то условия местами переставили и получили более оптимальное исполнение.
Иногда логика функций сохраняется, но код реконструируется полностью. Это позволяет избавиться от ненужного наследия или просто посмотреть на код свежим взглядом.
Обычно оптимизация кода делается именно с включенных прекомпилятором PHP, чтобы исключить погрешность измерений, вносимую большим временем компиляции кода по отношению к времени исполнения самого кода.
Объем компилируемого кода и время компиляции кода так же является важным направлением оптимизации. В PHP5 появилась возможность загрузки кода только при первом факте использования ( __autoload )
Autoload позволяет подгружать только те файлы модуля, которые нужны для работы. Например, если пользователь открыл каталог товаров, то подключаются модули каталога и магазина. При этом подавляющее большинство функционала этих модулей в данном случае не нужно. Но при обычном подключении в PHP4 весь функционал подгружается и обрабатывается.
Если использовать Autoload, то никакие скрипты не подгружаются до первого использования их функционала. А так как в каталоге товаров нужен грубо говоря только класс корзины и (может быть) заказа, то остальные скрипты просто тихо лежат на диске.
Преимущества очевидны в данном случае, но только нужно соблюдать совместимость версий PHP4 и PHP5, а лучше даже единство кода.
В частности, такая методика впервые будет использована в ближайшем обновлении модулей Интернет-магазина и Торгового каталога. При тестировании выяснилось, что на каждом отдельном хите выйгрыш не просматривается, так как машина свободна. Но при максимальном нагрузочном тестировании эффективность Autoload составила порядка 20% по памяти и производительности. Что очень даже ощутимо для нагруженных проектов и виртуального хостинга.
Еще одна хорошая новость.
В ближайшее время появится новый класс кэширования (построенный, конечно, на стандартных классах кэширования), который эмулирует кэш баз данных LRU (Least Recently Used)
Цель появления такого КЭШа такова: некоторые данные могут иметь теоретически неограниченно большой размер, поэтому их полное кэширование не представляется возможным. Но в реальной жизни и на реальном сайте эти данные могут быть весьма ограничены и/или какие-то из этих данных будут более востребованы, чем остальные. Причем некоторые данные очень часто запрашивается на сайте.
Мы посчитали, что имеет смысл как-то кэшировать эти данные. Но так, чтобы кэш не оказался многомегабайтной длины (что очевидно не только не убыстрит, но и даже затормозит работу). LRU кэш является управляемым и имеет управляемый размер (настраивается для каждого кэшируемого объекта).
Если происходит запрос к кэшируемому объекту, то объект сначала проверяется в КЭШе. Если там уже есть необходимые данные, то они передвигаются в начало КЭШа и возвращаются без запросов и вычислений. Если данных в КЭШе нет, то они выбираются (и вычисляются) и добавляются в начало КЭШа. Если при этом КЭШ перерос ограничения по длине, то последний элемент из него вытесняется.
Таким образом кэш ограничен по размеру на случай очень большого числа данных в базе. Если данных окажется реально немного, то они будут полностью кэшированы. Если данных много, но одни из них запрашиваются чаше других, то высока вероятность, что часто запрашиваемые данные будут постоянно жить в КЭШе (так как из КЭШа при переполнении удаляются те данные, которые дольше всего не запрашивались).
Первоначально этот тип кэширования будет применен к некоторым объектам в каталоге. Например, к скидкам.
Но для данных, которых заведомо мало, лучше использовать управляемый кэш. В частности, в новом модуле валют вообще не будет возникать запросов к базе данных при использовании большинства функций. Управляемый кэш сейчас будет применяться и в инфоблоках для обработки наиболее частных операций.
Опять же в качестве примера, успешно оптимизирован модуль опросов. Кэшированы группы опросов, права доступа, сайты. Оптимизирован повторный вызов функций. Использование модуля существенно оптимизировано.
Оптимизированные модули, безусловно, отражаются на скорости работы публичных компонент и административных разделов сайта.
Ожидаем в ближайшее время обновление по Интернет-магазину, торговому каталогу, опросам, техподдержке, инфоблокам, главному модулю, форумам...
