Comments 27
> Сразу хочу оговориться, проект высоконагруженный, порядка двух тысяч человек в сутки.
Очень круто :)
Очень круто :)
У вас же race condition в методе сохранения. Используете общий контейнер — значит надо лочить его.
Ну и да, две тысячи человек в сутки — это не нагруженный проект, тем более не «высоконагруженный».
Ну и да, две тысячи человек в сутки — это не нагруженный проект, тем более не «высоконагруженный».
Возникли следующие вопросы:
1) Как вы боретесь с вытеснением из кеша контейнера тэгов и самих тегов?
2) Для чего нужен контейнер тегов?
3) Как вы боретесь с пересечением имен тегов и обычных ключей? Не лучше было бы для тегов добавить префикс?
4) Мне кажется, или действительно, помести в кеш любые данные с хоть одним тегом и временем жизни одна секунда, я убью контейнер и этот тег, потому что они сохраняются с этим же временем жизни?
5) Зачем сохраняются теги и контейнер в методе save(), даже если они не менялись?
1) Как вы боретесь с вытеснением из кеша контейнера тэгов и самих тегов?
2) Для чего нужен контейнер тегов?
3) Как вы боретесь с пересечением имен тегов и обычных ключей? Не лучше было бы для тегов добавить префикс?
4) Мне кажется, или действительно, помести в кеш любые данные с хоть одним тегом и временем жизни одна секунда, я убью контейнер и этот тег, потому что они сохраняются с этим же временем жизни?
5) Зачем сохраняются теги и контейнер в методе save(), даже если они не менялись?
1. Возможно я не правильно понял вопрос, но у меня нет в этом необходимости.
2. Контейнер тегов нужен для того, чтобы быстро, в случае необходимости получить все id.
3. Пересечение имен тегов на ни в коем образе не навредит, ключи же не пересекаются, поскольку в данном случае произойдет memcache->get. Префикс не нужен, потому что если тег именуется как имя класса и если же он пересекается, то просто идет добавление нового id(key) в хранилище.
4. Выходит так, но мы этого делать не будем :)
5. Спасибо, критичное замечание.
2. Контейнер тегов нужен для того, чтобы быстро, в случае необходимости получить все id.
3. Пересечение имен тегов на ни в коем образе не навредит, ключи же не пересекаются, поскольку в данном случае произойдет memcache->get. Префикс не нужен, потому что если тег именуется как имя класса и если же он пересекается, то просто идет добавление нового id(key) в хранилище.
4. Выходит так, но мы этого делать не будем :)
5. Спасибо, критичное замечание.
1) Видимо неправильно. Мамкеш не резиновый. Если все данные, положенные в кеш, не влазят в отведенное пространство, они вытесняются т.е. удаляются. Как вы боретесь с вытеснением тегов и контейнеров.
2) Все id не получите, получите id, помеченные тегами. Для чего это может понадобиться?
3) Вы видимо описали свой частный случай. Тем не менее выставили код как общее решение. Вы должны решить эти проблемы.
4) То же самое.
2) Все id не получите, получите id, помеченные тегами. Для чего это может понадобиться?
3) Вы видимо описали свой частный случай. Тем не менее выставили код как общее решение. Вы должны решить эти проблемы.
4) То же самое.
1. Ответ не очевиден, поскольку как минимум необходимо знать по какому критерию происходит очистка кеша на стороне сервера, знаю точно, ключи никуда не деваются, чиститься лишь содержимое. Решений может быть несколько: увеличить размер хранилища, разнести кеш на несколько серверов, хранить теги в базе данных, возможно ещё что-нибудь придет в голову.
2. При получении id, это частный случай. В проекте сессия также храниться в мемкеше, но работает на прямую с memcache->get и memcache->set без тегирования, тоесть ключи лежат отдельно. И возникает необходимость очистить весь кеш кроме сессии. Получаю все теги, потом чищу по полученным id.
3. Я описал свой частный случаю, который работает и применим к проекту. Если у вас есть замечания и ответы на них, поделитесь ими.
Предложенное решение разработчики могут использовать на свой страх и риск, впрочем как и весь код предлагаемый на хабре. И он ничем не хуже кода предложенного в самой либе зенда.
Знаю точно, база данных без мемкеша легла бы уже давно.
2. При получении id, это частный случай. В проекте сессия также храниться в мемкеше, но работает на прямую с memcache->get и memcache->set без тегирования, тоесть ключи лежат отдельно. И возникает необходимость очистить весь кеш кроме сессии. Получаю все теги, потом чищу по полученным id.
3. Я описал свой частный случаю, который работает и применим к проекту. Если у вас есть замечания и ответы на них, поделитесь ими.
Предложенное решение разработчики могут использовать на свой страх и риск, впрочем как и весь код предлагаемый на хабре. И он ничем не хуже кода предложенного в самой либе зенда.
Знаю точно, база данных без мемкеша легла бы уже давно.
> И он ничем не хуже кода предложенного в самой либе зенда.
Завидная самоуверенность, особенно учитывая тот факт, что вы сами тут же признаете, что кроме вас этот код никому не подходит.
Завидная самоуверенность, особенно учитывая тот факт, что вы сами тут же признаете, что кроме вас этот код никому не подходит.
Этот частный случай, если вы не заметили есть расширением класса Zend_Cache_Backend_Memcached и реализует работу с тегами. И этот вариант как ни странно рабочий.
Т.е. достаточным условием хорошего кода является наследованием от другого хорошего кода? Спешу вас разуверить.
Ваш код плох именно там, что он учитывает только ваши частные случаи и не может называться библиотекой. Библиотека Зенд же, является общим решением.
Ваш код плох именно там, что он учитывает только ваши частные случаи и не может называться библиотекой. Библиотека Зенд же, является общим решением.
Не конструктивная критика, покажите слабые или не рабочие места, а потом говорите, что мой код плох.
Are you fucking kidding me?
Я же вам тректат о недочетах написал.
Я же вам тректат о недочетах написал.
> 5) Зачем сохраняются теги и контейнер в методе save(), даже если они не менялись?
fixed
все остальное просто слова
fixed
все остальное просто слова
1) Вы расчитываете на то, что хранилище под кеш всегда будет больше, чем нужно закешировать данных. Мемкеш работает совсем по-другому.
2) Вы тратите ресурсы на поддержание в актуальном состоянии некоего списка всех тегов, объясняя это тем, что в вашем приложении все так устроенно, что без тегов только сессии. Это только у вас так устроенно.
3) Разработчик, воспользовавшийся вашим детищем, может вполне резонно захотеть сделать как ключ people, так и тег people. Вы никак с этим не боретесь и не предупреждаете разработчика, что его закешированным данным хана.
4) Это вообще заряженный пистолет в детской комнате. Разработчик просто ставит хоть у одного тега таймут 10 секунд и все его теги летят к чертям. Все потому, что вы так не делаете.
Вот это все частные случаи, а не «поддержка тегов мемкеш бекенда», как вы предположили ниже.
2) Вы тратите ресурсы на поддержание в актуальном состоянии некоего списка всех тегов, объясняя это тем, что в вашем приложении все так устроенно, что без тегов только сессии. Это только у вас так устроенно.
3) Разработчик, воспользовавшийся вашим детищем, может вполне резонно захотеть сделать как ключ people, так и тег people. Вы никак с этим не боретесь и не предупреждаете разработчика, что его закешированным данным хана.
4) Это вообще заряженный пистолет в детской комнате. Разработчик просто ставит хоть у одного тега таймут 10 секунд и все его теги летят к чертям. Все потому, что вы так не делаете.
Вот это все частные случаи, а не «поддержка тегов мемкеш бекенда», как вы предположили ниже.
Меня не пугает случайная очистка данных, поскольку это лучше чем полная очистка всего кеша, как происходило ранее. В нужный момент подстрахует база данных. В любом случае мемкеш это отдельный сервис и вреда моему здоровью и тем более коду он не принесет. Если всего бояться и не пытаться ходить, тогда и ноги не к чему.
Нет панацеи, кроме увеличения хранилища, до разумных пределов конечно. Распределение нагрузки на несколько серверов. Это экспериментальный путь развития без этого всего прироста не произойдет.
Насчет времени хранения ключей и тегов с одинаковым именем, это конструктивные предложения, по ним будут внесены правки в ближайшее время.
Нет панацеи, кроме увеличения хранилища, до разумных пределов конечно. Распределение нагрузки на несколько серверов. Это экспериментальный путь развития без этого всего прироста не произойдет.
Насчет времени хранения ключей и тегов с одинаковым именем, это конструктивные предложения, по ним будут внесены правки в ближайшее время.
Мой класс не может называться библиотекой, поскольку является расширением, с помощью которого решается не тривиальная задача. И если поддержка тегов мемкеш бекенда это частный случай, то могу смело вам сказать, что ваши заявления ни что иное как попытка попиариться.
Кстати, есть такая штука Zend_Cache_Backend_Mongo. Там теги есть, и не медленнее чем Memcache.
Sign up to leave a comment.
Учим Zend Memcache работать с тегами