Cyrax_02
С нами с 04 августа 2013; Место в рейтинге пользователей: #250
8 часов назад
Можно сделать самому по этой инструкции
Вчера в 12:10
Спасибо, помогло
Согласен, что xx.include.cache.php — не кэш сниппета (если говорить о кэшировании значения, возвращаемого сниппетом). xx.include.cache.php — это фактически зеркало того кода, который хранится в БД. Т.е. код сниппета хранится в 2 местах — в стандартной БД и в файле. Имеет место оправданная избыточность данных.
Но почему Вы считаете, что это самое зеркало и код в БД не должны друг другу соответствовать? И речь не идёт о кэше. Если одни и те же данные в некоторый момент времени оказываются разными, имеет место нарушение целостности, что мы и наблюдаем при изменении кода сниппета в БД.
Вы считаете нарушение целостности данных нормальным?
Я удивляюсь, что «он» не обновляется (очищаться он и не должен, т.к. галка очистки снята) при изменении сниппета. И не на пустом месте.
В modx мы имеем место с 2 логическими категориями:
1) Кэширование элемента или ресурса. В случае с элементами — это восклицательный знак перед именем элемента. В случае с ресурсом — галка «Кэшируемый». Логика этой категории такова, что что запрет кэширования означает, что ВСЕГДА обрабатываются актуальные на текущий момент данные и выполняется актуальный на текущий момент код.
2) Очистка кэша при сохранении. Означает, что если мы изменяем элемент или ресурс, то при последующей загрузке страницы мы получим актуальные данные и актуальный код.
Но в случае со сниппетом запрет кэширования НЕ означает выполнение актуального кода (нарушена логика #1). Всё встало бы на свои места, если бы при запрете кэширования сниппета и при отключенной галке «Очистить кэш при сохранении» этот самый файл обновлялся (актуализировался). Только в этом случае вышеизложенная логика полностью бы соблюдалась.
Т.е. при запрете кэширования сниппета всегда должен выполняться актуальный на текущий момент код, независимо от того, каким образом физически реализована работа с этим сниппетом. Если бы код сниппета извлекался бы из БД, то проблемы бы не было. Ну а коли код сниппета сохраняется в файле, то этот файл должен поддерживаться в актуальном состоянии (если кэширование запрещено).
Галка «Очистить кэш при сохранении» у элементов (сниппеты, плагины, чанки, шаблоны) и галка «Очистить кэш» у ресурсов НЕ имеют собственного поля в БД.
Как следствие:
а) при снятии этой галки и сохранении элемента/ресурса состояние галки в БД запомнено не будет
б) при загрузке (перезагрузке) страницы элемента/ресурса эта галка ВСЕГДА устанавливаются
Это вторая причина, по которой никто не замечал вот этого артефакта:
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.
Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).
А почему никто, кроме меня, на этот артефакт внимания не обращал — потому что у всех стоит галка «Очистить кэш при сохранении» (при сохранении кэш очищается => при вызове сниппета выполняется актуальный в данный момент код сниппета).
Я же слежу непосредственно за файлом 200.include.cache.php (сниппет snp_test имеет id 200) в директории /core/cache/includes/elements/modsnippet. А этим файлом и в этой директории управляет исключительно modx. Этот файл после первого создания никогда не меняется. Если только очистить кэш, он пересоздастся.
Но какого хрена там хранится старый код? И этот старый код всё время выполняется.
Вот я изменил код сниппета, сохранил его. Вместо '555' он должен возращать '666'. Запускаю ресурс — получаю '555'. Это нормально? При том, что кэширование отключено.
У ресурса галку «кэшируемый» снял.
У сниппета галку «Очистить кэш при сохранении снял».
При этом наблюдаю артефакт: некэшируемый сниппет кэшируется.
Т.е. если кэш сайта не очищать, то при загрузке ресурса появляется кэш сниппета. А если измененить код сниппета и сохранить его, то при загрузке ресурса выполняется код из кэша.
В шаблоне tpl_test указываю:
У ресурса test в качестве шаблона указываю tpl_test.
Загружаю этот ресурс — в /core/cache/includes/elements/modsnippet появляется кэш сниппета. Удаляю этот кэш-файл, загружаю ресурс — кэш-файл сниппета снова появляется.
Шаблон ресурсу прописываю верный. Если в шаблоне отключить сниппет
то при загрузке ресурса получаем пустой экран. При этом в /core/cache/includes/elements/modsnippet никаких файлов кэша не появляется.
Бред какой-то. Сниппет вызываю НЕкэшируемым. А он всё равно кэшируется. При загрузке ресурса отрабатывает сниппет из кэша. Галку «Очистить кэш при сохранении» снял и у шаблона, и у сниппета.
300 вызовов makeURL у вас занимает 0.04 сек, у меня — 0.75 сек. Разница — в 20 раз.
4-х кратный тормоз объясняется процессором (согласно тесту). Но остаётся объяснить ещё 5-кратный тормоз. Из-за диска?
Так вот в чём дело — у вас там SSD стоят. Тогда всё понятно ))
Ну а переходить на 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. У вас, похоже, дисковые операции летают на первой космической…
0.78527092933655
Ну а если вызывать через $modx->runSnippet — секунд 5 будет.