WebMan

Почему? Поясните Вашу мысль, пожалуйста.

Хак: Оптимизация загрузки классов кэша в InstantCMS 2.0.1

Согласен, это самый разумный подход. У классного движка InstantCMS 2 ещё есть запасы оптимизации по этому принципу.

Например, при открытии любой страницы с контентом (даже просто "О сайте" без каментов и виджетов под гостем) загружаются, компилируются и выполняются все 20 файлов с полями форм, независимо от их использования или не использования. Эта логика "зашита" в контроллер контента (\system\controllers\content\model.php). Я ещё не разбирался в ядре настолько глубоко, чтобы понять, как это обойти. Но думаю, что возможности есть. Даже только загрузка классов полей формы по требованию вместо полной загрузки при старте позволила бы уменьшить время создания страницы ещё на 15-20 мс. При открытии простой страницы типа "О сайте" на моём компе за 160 мс увеличение скорости было бы примерно на 10%. Тоже хороший плюс.

Или, например, загрузка классов кэширования происходит независимо от включения/выключения этого кэширования в настройках и реального использования кэша. Логика кода, в принципе, понятна: делать проверку включения кэширования только в самом классе кэширования для структурирования кода и более точного соответствия парадигме ООП. Но я бы от этого отказался ради производительности. Поскольку название параметра конфига 'cache_enabled' вряд ли будет меняться в будущем, то выгоднее в паре мест кода вне класса кэширования сделать проверку этого параметра и просто не загружать ничего, связанного с кэшированием, если оно выключено. Это даст выигрыш в 2-4 мс и дополнительную экономию памяти.

Где-то выиграть пару-тройку мс, где-то больше - можно ускорить движок ещё раза в полтора.

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

И, кстати, о кэшировании. Оно сейчас сделано достаточно мягким и динамичным: кэшируются виджеты, небольшие блоки информации (списки событий) и т.д., а потом из этих кусочков кэша собирается страничка. Это увеличивает скорость сборки страницы всего процентов на 30 при использовании memcache, зато делает кэширование более динамичным. При этом всё равно загружается, компилируется и частично выполняется достаточно много лишнего кода - это следствие хорошей структурированности кода и следования ООП. Если добавить ещё один режим кэширования, более полный, когда, например, гостям будут отдаваться готовые страницы целиком из кэша, то можно генерить страницы раза в два и более быстрее даже без использования прокси. Можно будет разделять гостей и зарегистрированных пользователей, отдавая им сайт, соответственно, из кэша и без него. И это вообще будет полезно как в случае неожиданного пикового наплыва посетителей, так и для "обычных" сайтостроителей, не разбирающихся в особенностях вебсерверов, позволяя некоторое время прожить на старых серверах и тарифах.

В-общем, возможностей для оптимизации ещё много. Согласен с Aryuts, что движок молодой, его ещё можно и нужно совершенствовать во многих направлениях. Хотя по-честному, уже сейчас даже с минимальной оптимизацией InstantCMS 2 легко делает по удобству и функционалу другие популярные движки при не меньшей, а часто заметно лучшей производительности и меньшем потреблении памяти. Так что разработчики действительно постарались на славу. За что им большая благодарность!

А в итоговой таблице отладки что больше всего времени съедает? Возможно тормозит MySQL, тогда этот хак своё дело сделает, но принципиально не поможет.

Хак: Оптимизация инклудов в InstantCMS 2.0.1 (v.1)


Также в этой теме добавил архив отладки со встроенной оптимизацией. Его можно заливать в чистую систему.
В систему с уже установленной отладкой без оптимизации лучше распаковать архив "оптимизации для отладки" из блога про оптимизацию.

Сегодня или завтра. Оптимизацию сделал, нужно выделить время всё оформить.

Здравствуйте, Potapych! К сожалению, у меня сейчас мало свободного времени. Попробуйте переделать самостоятельно. Или попросите уважаемого oll - он сейчас выложил в своём блоге аналогичную серию хаков для других компонентов, может быть и тут Вам поможет.

В 1.10.3 можете внести поправки сами по аналогии с изменениями для 1.10.1, описанными в файле photo-seo_readme.txt.
Для новой версии движка я делать патч не предполагаю, нет времени. Если у Вас всё получится, сделайте такой же архив для патча, как в этой теме и либо выложите в своём блоге, либо пришлите мне - я опубликую его тут со ссылкой на Вас. Может это ещё кому-то понадобится.

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

В итоговой таблице показывается время, затраченное на дисковые операции, работу с БД, кэш и чистое php-время. Также расчитывается процент этого всего от полного времени работы скрипта. Зная ваши обычные значения при хорошо работающем сайте, вы сразу увидите отклонения конкретного времени при тормозящем сайте и сможете понять, что стало работать дольше (что тормозит).
Естественно, эта отладка не заменит штатных средств операционной системы, установленной на хостинге. Но позволит оперативно и наглядно понять узкие/нагруженные места и будет дополнительным агрументом при общении с поддержкой хостера.

Для первой ветки давно была сделана версия попроще. На тот момент и в том виде она не заинтересовала разработчиков Инстанта для встраивания в релизы. А отдельным компонентом такую глубокую функциональность сделать не получится. Поскольку мне под мои проекты больше подходит вторая ветка, то я решил версию для первой ветки не доделывать и не выкладывать, чтобы не морочиться с постоянным обновлением её при выходах новых релизов 1.10. Если эта отладка реально будет нужна пользователям первого Инстанта и разработчики решат её включить в следующий релиз, я сделаю код и для первой ветки.

Пожалуйста, irbis!
В самом начале в файле uc-seo-title_readme.txt, там, где начинается описание правок хака, идут строки:
и далее идут указанные Вами строки - это не оно? Если что-то пропустил, опишите это точнее в личку, я переделаю архив.

С версией 1.9 не работал и проверить нет возможности. Попробуйте просто убрать определение кодировки из запросов, должно сработать.

Для 1.9 я делать не планирую. Вы можете сделать сами по тому же принципу, все необходимые действия для 1.10 подробно описаны в файле uc-seo-title_readme.txt в архиве. Для 1.9, вероятнее всего, делается аналогично.

SEO title для разделов и записей каталога
Хак добавляет возможность вручную менять заголовки страниц (title) при отображении разделов и записей каталогов. Является развитием этого хака, так как в итоговые файлы в архиве объединены все изменения из этой темы, и из новой.

Этот хак добавляет META-теги к страницам фотогалереи (в том числе и к тем, на которых показываются отдельные фото), а не к элементам страницы. А значит, для изображений, размещённых на страницах других компонентов он не подходит.
Что касается изображений в статьях. Чтобы добавить Alt и Title к картинкам, загружаемым в описании статьи, нужно делать ещё хак. В чём лично я не вижу никакой выгоды. Это не те картинки, которые хотелось бы видеть в выдаче поисковиков. Гораздо выгоднее для СЕО при вставке или редактировании картинки, вставленной в текст статьи, прописать для неё альтернативный текст, как написал Олег Васильевич.

Да, спасибо, Fichter! Я действительно забыл написать, что подсветка вынесена в стиль css "search_match". Просто не всем удобно выделение найденного именно жирным шрифтом. Некоторые предпочитают выделять цветом фона, например. Зависит от дизайна сайта.

Согласен, letsgo, поиск в этой версии Инстанта, мягко говоря, не очень. Но на корпоративный сайт, например, ставить поиск от Гугла или Яндекса мне показалось не очень удачным. Тем более, что информации там мало и она достаточно хорошо структурирована, так что её и через меню можно легко найти. Поиск делался как дополнительная возможность. Когда в движке появится Sphinx или подобное, я подключу его, если такая необходимость возникнет.

На других типах сайтов поиск от поисковиков (простите за каламбур) может даже принести пользу. Теоретически. Поисковики могут как-то учитывать поисковые фразы, приходящие с сайта, для уточнения тематики сайта и своей выдачи по нему. Но это только мои предположения, конкретной инфы по этому вопросу у меня нет.

Как оказалось, разница есть. Поиск Инстанта в результатах вывода показывает куски текста в пределах некоторого количества слов вперёд и назад вокруг найденных слов. И частенько это получается "полтора землекопа". То есть, первое предложение с середины, потом целое предложение, потом ещё кусочек. Если весь текст написан только строчными буквами, то тяжелее улавливать правильный контекст найденного. Тем более, если в тексте часто встречаются аббревиатуры, имена, названия и сокращения. А если сохранить заглавные, то - легче. Например, на корпоративном портале некрасиво выводить название фирмы или продукции полностью маленькими буквами. А названия партнёров - тем более.

Я понимаю, что некоторым людям при общении в инете вообще ломы пользоваться заглавными буквами и даже знаками препинания. Может быть им и не важно как что-то написано. Но это исключительно личный выбор каждого. Кто-то выбирает путь лени и безграмотности, а кто-то хочет, чтобы его точнее понимали и с ним было проще/приятнее общаться. Для меня правильное пользование грамматикой и орфографией - это уважение к моим собеседникам. Я предпочту чуток потрудиться ради этого. Без обид, просто каждый выбирает своё.

И, кстати, все поисковики не ленятся оставлять найденный текст в том виде, в котором он был проиндексирован с сайта - с учётом заглавных букв. Видимо у них не дураки это делали. Хотя проще и экономнее сделать всё строчными буквами.

В любом случае, мне самому удобнее пользоваться таким поиском и, уверен, многим пользователям так же. И не в моих правилах "забивать" на подобные мелочи, касающиеся удобства, если я могу их реализовать. Хак выложен для тех, у кого такое же отношение к людям и к своему делу.

Fuze сказал, что писать в багтрекер нет необходимости. Видимо у него это уже есть в планах.