про работу модуля кэширования

dyll писал(а):

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

Чтобы пояснять то, что непонятно, вначале нужно спросить и указать, что именно не понятно.

dyll писал(а):

19 методов API с кое-каким описанием для этого недостаточно.

Мало методов или описаний?

dyll писал(а):

Вы можете ОТВЕТИТЬ на вопрос, а не ПОСОВЕТОВАТЬ?

"И незачем так орать" (с) Винни Пух

Кстати, если мне не изменяет память, именование элемента кэша у ZF ведется на основе меток, и при очистке осуществляется огромный перебор кучи файлов, что может привести к жуткому времени удаления N элементов.

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

Это частный случай. Просто хотелось бы пользоваться Вашим кешированием, а не прикручивать сторонние.
$Cache->DeleteCacheItem($cache_name, $item_name);
как формируются $cache_name для элементов ИС?

У ZF основное - это название, но можно задавать и метки (Вам этого не хватает) и много чего.

HostCMS писал(а):

«И незачем так орать» (с) Винни Пух

Я просто привлекал внимание )

dyll писал(а):

но осталась проблема с комментариями — они все равно кешируются и сразу не обновляются.

Вы полностью модуль кэширования отключили, а комментарии все равно кэшируются?

dyll писал(а):

как формируются $cache_name для элементов ИС?

Поясните, для какого именно блока кэширования Вы спрашиваете (из 2-х приведенных)?

dyll писал(а):

(Вам этого не хватает) и много чего.

про метки я уже выше написал, практическая ценность при больших объемах ниже плинтуса. А на тему "и много чего" было бы замечательно, если эти "чего" Вы озвучите

dyll писал(а):

Я просто привлекал внимание)

у Вас получилось.

Вообщем все сложно с ваши кэшем!
Я давно предлагал сделать чтобы система по ключу(URL) записывала кэш в memcached и брала страничку оттуда! Соответственно если какой-то комментарий или что-то там еще изменилось - изменялся кэш именно по ключу URL (независимо от пользователя , а при изменении инф. системы ее элементов или еще чего-то). Пользователь уже сразу получает ответ из кэша от memcached! Я на mod_perl в самописной cms так делал и nginx очень классно умеет из кэша забирать значение по ключу URL - и все летает и кэш обновляется. Разработчики - возьмите на заметку! Смысла в вашем модуле кэширования получается нет - он нужен именно для динамики , а статическую главную страницу я и так могу закэшировать чем угодно - nginx, mod_accel, mod_proxy и и т.д. Не верю что этого нельзя сделать - URL есть URL! Если что-то что отображается при вводе URL изменяется - это легко отконтроллировать! Жаль что в вашей системе которой я активно пользуюсь еще нет разумного кэширования. Что мешает то?

HostCMS писал(а):

Вы полностью модуль кэширования отключили, а комментарии все равно кэшируются?

при отключении модуля кеширования все нормально.
HostCMS писал(а):

Поясните, для какого именно блока кэширования Вы спрашиваете (из 2-х приведенных)?

Я же описал конкретную проблему. Хотелось бы при наличии модуля кеширования пользоваться этим модулем.
В первую очередь меня интересует как очистить кеш комментариев определенного ИЭ. Во вторую - как очистить кеш списка ИЭ зная id ИС, id группы.
Отключения модуля не предлагать ))

Вот это писала техподдержка
техподдержка писал(а):

Попробуйте для запрета использования кэша на странице *** в метод ShowInformationSystem передать параметр $property['cache_off'] со значением true(в коде типовой динамической страницы, используемой для раздела /guestbook/).

jenix писал(а):

записывала кэш в memcached

memcached для виртуальных хостингов не актуален. А вот если бы был способ задания места хранения кеша - было б здорово.

jenix писал(а):

Я давно предлагал сделать чтобы система по ключу(URL) записывала кэш в memcached и брала страничку оттуда! Соответственно если какой-то комментарий или что-то там еще изменилось — изменялся кэш именно по ключу URL (независимо от пользователя, а при изменении инф. системы ее элементов или еще чего-то ). Пользователь уже сразу получает ответ из кэша от memcached! Я на mod_perl в самописной cms так делал и nginx очень классно умеет из кэша забирать значение по ключу URL — и все летает и кэш обновляется. Разработчики — возьмите на заметку!

У нас файловый кэш именно так работает. Нужно разделять кэширование "тупо всю страницу" и элементов страницы.
jenix писал(а):

Смысла в вашем модуле кэширования получается нет — он нужен именно для динамики

Вы чисто теоретически порассуждать в тему пришли? У нас динамика как раз и кэшируется в один кэш, а страницы целиком в другой.
jenix писал(а):

Жаль что в вашей системе которой я активно пользуюсь еще нет разумного кэширования. Что мешает то?

Что-то мне говорит, что в системе Вы к кэшированию даже не подходили, раз говорите такие глупости.

dyll писал(а):

В первую очередь меня интересует как очистить кеш комментариев определенного ИЭ. Во вторую — как очистить кеш списка ИЭ зная id ИС, id группы.

Итак, начинаем с начала. Система кэширует различные блоки, одна и та же информация может поместиться в разные блоки. Кэша комментариев для ИС нет, кэшируется сгенерированный код для обработанного XSL-шаблона. Кэшируется он в SHOW_INF_SYS_XML.
Формируется следующим образом:


dyll писал(а):

memcached для виртуальных хостингов не актуален. А вот если бы был способ задания места хранения кеша — было б здорово.

У нас есть в файлах и с использованием eAccelerator (по многим тестам превосходит memcached). Добавить memcached не представляет большого труда.

я все никак не успокоюсь )
HostCMS писал(а):

$cache_element_name = 'InformationSystems_'.implode(",",$InformationSystemIdArray).'_'.$information_groups_id.'_'.$xsl_name.'_'.$items_on_page.'_'.$items_begin.'_'.$kernel->implode_array($external_propertys, '_'.'_'.$kernel->implode_array($property,'_'.'_'.$site_user_id;

здесь $kernel->implode_array($external_propertys, '_'. У меня возникает вопрос как быть с $external_propertys['captcha_key'] = $Captcha->GetCaptchaID() ? этот параметр всегда разный и случайный, значит и название элемента кеша всегда разное и случайное, следовательно удалить его нельзя. *WALL*

и подскажите, пожалуйста, еще как формируется $cache_element_name для отработанного  XSL-шаблона в методе ShowInformationSystemItem .
и как в нем обстоит дело с $external_propertys['captcha_key']

только добавление такого параметра помогло полностью "отключить" кеш
$external_propertys['rand_'. mt_rand()] = mt_rand();

Но проблема осталась. И проблема в том что когда добавляем комментарий к ИЭ - мы его видем, обновляем страницу и комментария нет. мое мнение - вся проблема в названии элемента кеша, а точнее в участии в нем $external_propertys.

пока работает с mt_rand(место для кеша на диске еще есть), но я надеюсь что исправите этот баг.

dyll писал(а):

здесь $kernel->implode_array($external_propertys, '_'. У меня возникает вопрос как быть с $external_propertys['captcha_key'] = $Captcha->GetCaptchaID()? этот параметр всегда разный и случайный, значит и название элемента кеша всегда разное и случайное, следовательно удалить его нельзя. *WALL*

Соответственно и данные в таком случае браться из кэша не будут. Вы уверены, что они все-таки оттуда берутся? Т.к. если капча кей разный, то каждый раз кэш-элемент для этого блока будет разным.

dyll писал(а):

и подскажите, пожалуйста, еще как формируется $cache_element_name для отработанного XSL-шаблона в методе ShowInformationSystemItem.

Пожалуйста: