Cyrax_02

Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.

Как Вы сами же говорите, xx.include.cache.php — НЕ кэш сниппета. Тогда почему этим файлом должна управлять галка «Очистить кэш»?

Согласен, что xx.include.cache.php — не кэш сниппета (если говорить о кэшировании значения, возвращаемого сниппетом). xx.include.cache.php — это фактически зеркало того кода, который хранится в БД. Т.е. код сниппета хранится в 2 местах — в стандартной БД и в файле. Имеет место оправданная избыточность данных.

Но почему Вы считаете, что это самое зеркало и код в БД не должны друг другу соответствовать? И речь не идёт о кэше. Если одни и те же данные в некоторый момент времени оказываются разными, имеет место нарушение целостности, что мы и наблюдаем при изменении кода сниппета в БД.

Вы считаете нарушение целостности данных нормальным?

Т.е. вы признаёте, что это кэш сниппета?
Я удивляюсь, что «он» не обновляется (очищаться он и не должен, т.к. галка очистки снята) при изменении сниппета. И не на пустом месте.

В modx мы имеем место с 2 логическими категориями:
1) Кэширование элемента или ресурса. В случае с элементами — это восклицательный знак перед именем элемента. В случае с ресурсом — галка «Кэшируемый». Логика этой категории такова, что что запрет кэширования означает, что ВСЕГДА обрабатываются актуальные на текущий момент данные и выполняется актуальный на текущий момент код.

2) Очистка кэша при сохранении. Означает, что если мы изменяем элемент или ресурс, то при последующей загрузке страницы мы получим актуальные данные и актуальный код.

Но в случае со сниппетом запрет кэширования НЕ означает выполнение актуального кода (нарушена логика #1). Всё встало бы на свои места, если бы при запрете кэширования сниппета и при отключенной галке «Очистить кэш при сохранении» этот самый файл обновлялся (актуализировался). Только в этом случае вышеизложенная логика полностью бы соблюдалась.

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

Ещё один артефакт. Вернее, как уже выяснилось, так было задумано разработчиками.
Галка «Очистить кэш при сохранении» у элементов (сниппеты, плагины, чанки, шаблоны) и галка «Очистить кэш» у ресурсов НЕ имеют собственного поля в БД.

Как следствие:
а) при снятии этой галки и сохранении элемента/ресурса состояние галки в БД запомнено не будет
б) при загрузке (перезагрузке) страницы элемента/ресурса эта галка ВСЕГДА устанавливаются

Это вторая причина, по которой никто не замечал вот этого артефакта:

Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.

Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).

Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.

Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).

А почему никто, кроме меня, на этот артефакт внимания не обращал — потому что у всех стоит галка «Очистить кэш при сохранении» (при сохранении кэш очищается => при вызове сниппета выполняется актуальный в данный момент код сниппета).

Нет никакого оптимизатора.
Я же слежу непосредственно за файлом 200.include.cache.php (сниппет snp_test имеет id 200) в директории /core/cache/includes/elements/modsnippet. А этим файлом и в этой директории управляет исключительно modx. Этот файл после первого создания никогда не меняется. Если только очистить кэш, он пересоздастся.

Я не против хранения кода сниппета.
Но какого хрена там хранится старый код? И этот старый код всё время выполняется.
Вот я изменил код сниппета, сохранил его. Вместо '555' он должен возращать '666'. Запускаю ресурс — получаю '555'. Это нормально? При том, что кэширование отключено.

При сохранении шаблона кэш сайта не очищается, потому что галку «Очистить кэш при сохранении» у шаблона я отключил.
У ресурса галку «кэшируемый» снял.
У сниппета галку «Очистить кэш при сохранении снял».

При этом наблюдаю артефакт: некэшируемый сниппет кэшируется.
Т.е. если кэш сайта не очищать, то при загрузке ресурса появляется кэш сниппета. А если измененить код сниппета и сохранить его, то при загрузке ресурса выполняется код из кэша.

У меня modx глючит.
В шаблоне tpl_test указываю:

[[!snp_test]]

У ресурса test в качестве шаблона указываю tpl_test.
Загружаю этот ресурс — в /core/cache/includes/elements/modsnippet появляется кэш сниппета. Удаляю этот кэш-файл, загружаю ресурс — кэш-файл сниппета снова появляется.

Шаблон ресурсу прописываю верный. Если в шаблоне отключить сниппет

[[-!snp_test]]

то при загрузке ресурса получаем пустой экран. При этом в /core/cache/includes/elements/modsnippet никаких файлов кэша не появляется.

Бред какой-то. Сниппет вызываю НЕкэшируемым. А он всё равно кэшируется. При загрузке ресурса отрабатывает сниппет из кэша. Галку «Очистить кэш при сохранении» снял и у шаблона, и у сниппета.

Возможная разница во всех этих параметрах уже учтена в вышеуказанном тесте и составляет 4x. Впрочем, на разных операциях (getChunk'и и makeURL'ы) эти же самые характеристики могут дать разные «разности».

0.0018330: Created inline chunk
0.7903738: Total time
8 388 608: Memory usage

В 4 раза медленнее и в 2,2 раза больше оперативки.

300 вызовов makeURL у вас занимает 0.04 сек, у меня — 0.75 сек. Разница — в 20 раз.
4-х кратный тормоз объясняется процессором (согласно тесту). Но остаётся объяснить ещё 5-кратный тормоз. Из-за диска?

Тогда откуда берётся разница в 40 раз?

Т.е. при выполнении 300 makeURL modx обращается к диску всего 3 раза (при первом вызове makeURL)?

h.simpledream.ru/
Так вот в чём дело — у вас там SSD стоят. Тогда всё понятно ))

Блин. У меня в 40 раз медленнее работает. Что за хрен.
Ну а переходить на simpledream — не вариант. Там маловато оперативки (хотя, 384 Мб, наверное, вполне достаточно) + дисковой памяти совсем нет (нужно от 100 Гб).
modx.pro/hosting/3335-hosting-simple-dream-a-new-ruler-of-tariffs/

И вопрос. Эти тормоза зависят исключительно от ПО хостера, разделяющего ресурсы диска по VPS, или можно оптимизировать сам VPS?

Ещё раз проверил:
300 вызовов makeUrl — 0.7-0.8 сек, 300 вызовов runSnippet — 1.2-1.4 сек.

Вообще, сабжевую задачу я уже решил. makeURL вызываю 1 раз, чтобы получить текущий URL. Далее меняю параметр через parseUrl, собираю обратно unParseUrl. А вызываемым чанкам передаю весь url.

Нужно сменить или хостинг, или логику работы

1 Гб памяти, CPU 1500 МГц. Впрочем, эти ресурсы здесь погоды не делают. В основном — скорость работы с диском на VPS. У вас, похоже, дисковые операции летают на первой космической…

В цикле 300 вызовов makeURL у меня занимает столько:
0.78527092933655

Ну а если вызывать через $modx->runSnippet — секунд 5 будет.

modx.pro/help/3567/#comment-27735

Только вот этот самый вызов сниппета, который выполняет парсер — это полноценное обращение к БД + создание объекта. Если в скрипте генерируется сотня ссылок с одним или несколькими изменяющимися параметрами, все эти вызовы сниппета приведут к ощутимым тормозам. Итого 300 запросов к БД.

Ну так обращение к карте сайта в файле на диске и обращение к базе данных mysql — это всё обращение к диску. Т.е. под обращением к БД в контексте скорости следует понимать обращение к диску. А это — самое слабое звено…

А это не на уровне парсера modx. Плюс долго выполняется из-за ряда дополнительных обращений к БД.