[X] Помощник

[Гость_wizard993_*]

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

1. Собственно вопрос преимущественно к Александру. В движке активно используется кэширование (как с помощью сторонних кэш-машин, так и методом сериализации). Так вот, никак не могу понять в чём разница в использовании Eleanor::$Cache->Put(....) и Eleanor::$Cache->Lib->Put(....) (ну анологично не только Put но и остальные методы). Понятно, что методы родительского класса (class Cache) представляют собой декораторы вокруг дочерних методов. Ещё при каких-то определённых условиях выполняется запись в БД в `eleanor`.`cache`. Хотелось бы узнать в каких именно случаях надо использовать Eleanor::$Cache а в каких Eleanor::$Cache->Lib.

2. Существует такая, скажем, недоработка, на мой взгляд. Заходим на localhost с установленным движком Eleanor CMS. Всё отлично. Система закешила всё, что необходимо. (в папке /cache/ всё лежит). Далее залазим в core/core.php находим класс class Cache и меняем следующий кусок кода

if(!isset($this->Lib))
		{
			#Вместо Serialize можно использовать HardDisk
			if(!class_exists('CacheMachineSerialize',false))
				include Eleanor::$root.'core/cache_machines/serialize.php';
			$this->Lib=new CacheMachineSerialize;
		}

на

if(!isset($this->Lib))
		{
			#Вместо Serialize можно использовать HardDisk
			if(!class_exists('CacheMachineHardDisk',false))
				include Eleanor::$root.'core/cache_machines/harddisk.php';
			$this->Lib=new CacheMachineHardDisk;
		}

при обновлении страницы получаем следующее (залил в файл чтобы не засорять пост):  changecacheoutput.txt ( 14.22 килобайт ) Скачиваний: 9


Вот эта штука выводится в браузер вместо красивой дефолтной странички

при обратной ситуации (HardDisk->Serialize) движок перехватывает исключение и выдаёт ошибку: произошла ошибка, Unknown service!
Это, скорее всего, происходит из-за того, что CacheMachineHardDisk создал файл /cache/system-services.php , а система затем не может его корректно обработать из-за сменившийся кэш-машины. Как вариант, предлагаю в директории /cache/ создать поддиректории с названиями кэш-машин, и каждая будет ложить кэш туда куда ей надо. Сначала думал предложить записывать имя кэш-машины в каждый файл, наряду с временем жизни, но по-моему будет довольно жирно проверять каждый раз, чем закэширован файл.

3. И просто из любопытства. Немного не понял защиту от dog-pile effect. В методе Get() при обращении предусмотрена блокировка? Я, к сожалению, его пока не раскладывал по косточкам, ограничившись изучением Put().

Сообщение отредактировал wizard993 - 2012-11-08, 19:32

[Alexander]

Хотелось бы узнать в каких именно случаях надо использовать Eleanor::$Cache->Put а в каких Eleanor::$Cache->Lib->Put.

Я бы не рекомендовал использовать Eleanor::$Cache->Lib в обычном режиме. Этот метод реализует одну единственную задачу: используя кэш-машину, положить туда какое-то содержимое. Все. Но для полноценной работы этого мало: нужно иметь возможность "вечного кэша" и защиту от dog-pile эффекта. По этаим причинам, рекомендуется использовать Eleanor::$Cache->Put .

Ещё при каких-то определённых условиях выполняется запись в БД в `eleanor`.`cache`

Эти условия я назвал "вечный кэш", включается четвертым параметром метода Eleanor::$Cache->Put и вторым метода Eleanor::$Cache->Get . "Вечный кэш" работает идентично key=>value базе данных, только для ускорения используется кэш машина. Алгоритм работы следующий: полученное значение записываем не только в кэш, но и в БД. Если данные из кэша каким-то чудным образом пропадают, данные берутся из БД, откуда они никуда пропасть не могут.

2. Существует такая, скажем, недоработка, на мой взгляд. Заходим на localhost с установленным движком Eleanor CMS. Всё отлично. Система закешила всё, что необходимо. (в папке /cache/ всё лежит). Далее залазим в core/core.php находим класс class Cache и меняем следующий кусок кода

А не нужно так поступать. Чтобы все работало, нужно очистить кодержимое каталога /cache/ (кроме файла .htaccess естественно). Разница между serialize и harddisk в том, что serialize для хранения данных в строке использует функцию serialize, а harddisk - var_export. var_export полезна в том случае, если клиенту нужно часто вручную править содержимое кэша (такое бывает). serialize же быстрее.

Немного не понял защиту от dog-pile effect.

Вы понимаете что это за эффект? Нужно объяснять?

[Гость_wizard993_*]

Alexander, спасибо за развёрнутый ответ.
Что такое dog-pile эффект объяснять не нужно. Уже перолапатил интернет. Ну по-русски это вроде называется проблема одновременного перестроения кэша (нашёл несколько статей на хабре) или "протухший" кэш.
Также видел типовые решения проблемы, котрые, в основном приводятся для кэш-машины memcached. В общем, попробую ещё раз очень внимательно изучить проблему, если вопросы останутся - снова отпишусь. Ещё раз большое спасибо. Регулярно слежу на гуглокоде за вашей работой Видел также в тудушке аксессор __invoke() в классе роутинга, я так понял вы хотите обращения вида $Eleanor->Url->Construct() перебросить на $Eleanor->Url(). Ещё вроде отказались от класса UrlFunc. Но это уже выходит за рамки этого топика. А так бы с интересом поспрашивал бы ещё про роутинг, я смотрю и .htaccess по-тихоньку меняется и в плане роутинга и в плане других опций). Во всяком случае, теперешняя структура учитывает рекоммендации, в одной недавней статье, размещённой на хабре (кажется она называлась "очередная попытка создать идеальный .htaccess").

P.S. удивляет, где вы черпаете некоторые идеи. Понятно, что сам код - результат таланта и опыта программирования, но некоторые идеи реализации очень впечатляют. Уж очень грамотно

P.P.S.

Эти условия я назвал "вечный кэш"

Я в принципе так понял, что данные зеркалятся в БД, для страховки, но просто смутило, что для большинства кэш-файлов оно не используется, и в основном кэширование идёт напрямую через кэш-машину, без использования методов класса Cache

Сообщение отредактировал wizard993 - 2012-11-10, 21:43

[Alexander]

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

Да. Все правильно. Решение мое банально: любая информация, что кладется в кэш через класс Cache, кладется туда с удвоенным ttl (можно регулировать), но при этом запоминается и оригинальный ttl. И вот когда ttl истекает, первому обратившемуся потоку за кэшем выдается false (кэш отсутствует) и пока этот первый поток перестраивает кэш, остальные потоки при обращении получают устаревший кэш. Ничего лучше придумать не смог. Есть что подсказать?

Видел также в тудушке аксессор __invoke() в классе роутинга, я так понял вы хотите обращения вида $Eleanor->Url->Construct() перебросить на $Eleanor->Url()

Да. Но система пока к этому не готова.

Ещё вроде отказались от класса UrlFunc.

Это был "бред" 4х часов утра. Оказалось, что все можно сделать куда более приятнее. Так что сделаем вид, что его и небыло

Во всяком случае, теперешняя структура учитывает рекоммендации, в одной недавней статье, размещённой на хабре (кажется она называлась "очередная попытка создать идеальный .htaccess").

Да, оттуда я тоже взял кое-что.

Уж очень грамотно

Примерчик того, что понравилось можете привести? Мне будет приятно.

в принципе так понял, что данные зеркалятся в БД, для страховки, но просто смутило, что для большинства кэш-файлов оно не используется

Оно используется для крона. Переменная nextrun.

P.S. удивляет, где вы черпаете некоторые идеи.

Тут на форуме подсказывают, плюс сам делаю на системе сайты и вижу недостатки. Вот, к примеру, сейчас на очереди реализация "умного" лога ошибок. Мне надоело уже. что одна ошибка невнимательного пользователя может забить все свободное пространство на диске. Нужно их группировать. Ждите уже в ближайшее время.

Кстати, благодарю, что смотрите мой код на гугле. Это помогает мне делать его лучше