PHP+Memcached - hi-load

fisher

накатила суть
Количествой айтемов ограничено по слабам. Статистику по слабам можно посмотреть - там что типа stats slabs или типа того. Для каждого слаба будет счетчики сколько всего и свободно. Что HraKK предлагает - по-моему это костыль, ты так же упрёшься в лимиты если всё пойдет в один слаб и мемкеш под него не будет реаллоцировать память.
 

kvn

programmer
Банально в лоб храни допустим по 1000 каунтов в итеме. Ну и заведи в мемкеше ключи для итемов.
Это уже второй вопрос, выходящий из первого: Есть ограничение на количество или нет?
Я так понял, что никто не сталкивался..
 

kvn

programmer
Количествой айтемов ограничено по слабам. Статистику по слабам можно посмотреть - там что типа stats slabs или типа того. Для каждого слаба будет счетчики сколько всего и свободно. Что HraKK предлагает - по-моему это костыль, ты так же упрёшься в лимиты если всё пойдет в один слаб и мемкеш под него не будет реаллоцировать память.
Хм, смотрю по слабам:

Slabs Allocated - 15
Slabs Used - 9
Memory Used - 23.0 MBytes
Wasted - 16.8 MBytes

На всех слабах Used Chunk < Total Chunk
 

fisher

накатила суть
либо бага в мемкеше, либо неправильно интерпретируете данные, либо искать надо вообще в приложении.
 

fisher

накатила суть
Есть ограничение на количество или нет?
Я так понял, что никто не сталкивался..
Ограничение есть, но работает LRU. То есть может оказаться, например, что все ключи резко протухли = получили миссы. Советую дебажить - логировать миссы и ращзбираться просто методом пристального всматривания в данные.
 

kvn

programmer
Ограничение есть
его увидеть можно где-то? Т.е. если оно есть, и реально равно 65635 (максимум, который влазит в int на 32-битной платформе), тогда нужно реально менять логику приложения.
Я почему-то искренне надейлся, что ограничения нет, либо оно гораздо больше..

, но работает LRU. То есть может оказаться, например, что все ключи резко протухли = получили миссы.
Это маловероятно, т.к. используется управление Expire на стороне приложения, т.е. реально в кеше значения перезаписываются и постоянно там живут, просто либа выдает приложению, что итем expired (чтобы одна сессия пересчитала значение), а сама тем временем продлевает жизнь кеша, чтобы остальные пока брали старое значение. Т.е. простая блокировка от одновременных запросов при выпадении из кеша. Все было пучком больше месяца...

Советую дебажить - логировать миссы и ращзбираться просто методом пристального всматривания в данные.
Да, спасибо. Просто думал есть какое-то явное решение, или как минимум, объяснение происходящего..
 

HraKK

Мудак
Команда форума
я изначально логику до стольких ключей не раздуваю, поэтому и не встречался.
 

kvn

programmer
я изначально логику до стольких ключей не раздуваю, поэтому и не встречался.
Так а это что, много? 65 тыс ключей, при нормальном динамическом проекте с посещаемостью в 30-50к юзеров это по 1-2 ключа на юзера..
 

kvn

programmer
а нафига на юзера по ключу?
М...я даже не знаю, что сразу ответить...
Ну, например, количество его фото - один ключ, кол-во его друзей - второй.
Его юзеринфо - третий..
Это, в целом, можно попробовать объединить в один ключ (например запихнуть в объект, и засунуть в кеш), но, т.к. данные сами по себе не очень связаны (вернее их изменение), то получается экономя на кеше, не очень экономим память, а также апдейт если юзер добавил фотку требует апдейта всего составного ключа (объекта).
Это мысли в слух...Но в целом - а почему нет?
Мы то имеем дело с "быстрым" кешем "ключ-значение"..а ключ-значение достаточно простая конструкция, какой смысл в нее пихать условно "сложные вещи"..
"Часто много маленьких лучше/быстрее, чем один большой" (с)..:)
 

kvn

programmer
"...в целом - а почему нет?" - это был второй ответ, на вопрос "а нафига на юзера по ключу?" :)
 

fisher

накатила суть
его увидеть можно где-то? Т.е. если оно есть, и реально равно 65635 (максимум, который влазит в int на 32-битной платформе), тогда нужно реально менять логику приложения.
Я почему-то искренне надейлся, что ограничения нет, либо оно гораздо больше..


Это маловероятно, т.к. используется управление Expire на стороне приложения, т.е. реально в кеше значения перезаписываются и постоянно там живут, просто либа выдает приложению, что итем expired (чтобы одна сессия пересчитала значение), а сама тем временем продлевает жизнь кеша, чтобы остальные пока брали старое значение. Т.е. простая блокировка от одновременных запросов при выпадении из кеша. Все было пучком больше месяца...


Да, спасибо. Просто думал есть какое-то явное решение, или как минимум, объяснение происходящего..

c какой радости нет ограничения? объяснение всей твоей ситуации элементарное - утебя либо массовое протухание, либо ты уперся в лимит слаба - лимит слаба берется из статистики по слабу.
 

kvn

programmer
c какой радости нет ограничения? объяснение всей твоей ситуации элементарное - утебя либо массовое протухание, либо ты уперся в лимит слаба - лимит слаба берется из статистики по слабу.
Где можно про это почитать? Или намекни в двух словах?
Если ограничение есть (и оно не по памяти, а в количестве), то хотел бы его посчитать, чтобы иметь ввиду на далее.
 

HraKK

Мудак
Команда форума
fisher
Сорри за оффтоп, знаешь какой-то проект hi-load на красивом ООП?
 
Сверху