Поиск по тегу «оптимизация»

Мощная система расширенной отладки. Позволяет легко, наглядно и управляемо получить информацию о последовательности, времени выполнения, используемой памяти и других параметрах PHP-скриптов и частей CMS, а также о работе с базой данных и кешем. Данная «Отладка» будет полезна как начинающим пользователям для изучения работы InstantCMS 2, так и опытным разработчикам компонентов/шаблонов при создании и тестировании своих продуктов. А так же всем пользователям CMS для выявления проблем при размещении сайтов на реальных серверах, где невозможно или неудобно использовать xDebug или подобную систему отладки.

Ответы актуальны для крайней версии «Расширенной отладки». Влияет ли «Расширенная отладка» на функционирование InstantCMS 2? «Расширенная отладка» не оказывает влияния на работу функций CMS и её компонентов. Она только ведёт учёт происходящих в системе действий. Какие изменения вносит «Расширенная отладка» в систему? «Расширенная отладка» не изменяет базу данных, кроме добавления стандартной записи о новом установленном компоненте. Начиная с версии 14.1 отладка может работать в двух режимах: стандартном - практически без изменения ядра, и полном - с патчами ядра для сбора дополнительных отладочных данных. Подробнее про режимы и изменяемые файлы можете почитать на странице описания режимов. Установил отладку, но информации отладки на сайте не вижу. Что не так? 1.

В стандартной версии движка пока перехватываются и обрабатываются только ошибки при обращении к базе данных. Ошибки PHP и предупреждения (в случае соответствующих настроек на сервере) не выводятся, а тихонько ложатся в лог веб-сервера. «Расширенная отладка» предоставляет несколько больше возможностей при обработке ошибок, которые будут полезны и разработчикам, и вебмастерам.

При анализе работы движка CMS или при отладке своих компонентов/шаблонов требуется знать состояние переменных в разных местах кода. Частично эта задача решается выводом информации об основных операциях несколькими щелчками мышки в «Расширенной отладке». А для более точного понимания происходящего в любом месте кода можно использовать контрольные точки.

Самый интересный вопрос для любого разработчика: «Что там, внутри моего кода, на самом деле происходит с данными?». Потому, что реальность иногда отличается от задумки из-за стратегических, логических и синтаксических ошибок в коде. И чтобы привести их в соответствие, нужно знать, какие данные поступают на вход той или иной части скрипта, и какие результаты обработки данных получаются на выходе.

Немного поговорим про использование фильтров. Поскольку «Расширенная отладка» может выдать в лог очень много разной информации, то возникла необходимость как-то организовать отбор только нужных строк логов. Для этого я сделал фильтры.

Этот и несколько следующих постов про использование «Расширенной отладки» будут в основном полезны для разработчиков и желающих разобраться в InstantCMS 2 на уровне кода. Начну с небольшого поста про трассировку вызовов. Ведь всегда хочется понимать, что откуда вызывается и где источник тех или иных данных.

Использование расширенной отладки. Часть 3. Изучаем работу InstantCMS 2 без знания PHP При создании своих сайтов любой вебмастер довольно быстро сталкивается с необходимостью хотя бы в общих чертах понимать, как устроена и работает выбранная им CMS. Попробуем наглядно посмотреть, как работает InstantCMS 2, без знания программирования и без чтения php-кода системы на примере одной из страниц демо-сайта. Это очень просто!

Пока писал пост про использование «[url=]Класса расширенной отладки v.9[/url]», заметил, что не хватает пары небольших полезностей. Вот, добавил. Заодно исправил обнаруженные небольшие ошибки.

Обновление класса расширенной отладки и оптимизации для InstantCMS 2.3.0.

Долгожданное обновление класса расширенной отладки и оптимизации для InstantCMS 2.2.1.

Обновление класса расширенной отладки и оптимизации для InstantCMS 2.1.2. Также исправлены несколько ошибок предыдущей версии.

В InstantCMS 2 в версиях до 2.0.1 включительно загрузка классов кэширования производится независимо от того, разрешено ли кэширование в настройках сайта или нет. Мотивацию разработчиков для этого я точно не знаю. Скорее всего это желание следовать принципам ООП, по которым проверка работы с кэшем должна осуществляться предпочтительно в классе кэширования. Но поскольку имя параметра настройки 'cache_enabled' вряд ли будет меняться в будущем, то выгоднее в нескольких местах кода вне класса кэширования сделать проверку этого параметра и просто не загружать ничего, связанного с кэшированием, если оно выключено. На моём компе это дало выигрыш порядка 4-5 мс и дополнительную экономию памяти (не сравнивал, забыл).

Прекрасный по всем параметрам продукт InstantCMS 2 в версиях до 2.0.1 включительно имеет один недостаток, влияющий на производительность – неоптимизированные подключения файлов классов и библиотек. Например, при открытии главной страницы под админским логином выполняется более 800 попыток подключения по сути одних и тех же файлов. Данный хак добавляет проверку на уже выполненное подключение перед вызовом подключений классов и библиотек. Это позволяет уменьшить время создания страницы более чем в полтора раза с полным сохранением функциональности сайта.

Продолжим начатое, но чуть менее затратно.