Мне интересно, будет ли иметь короткий тайм-аут (60 секунд) в memcached какое-либо негативное влияние на производительность, VS более длинные тайм-ауты, но игнорируя возвращаемое значение (если оно было сохранено более 60 секунд назад).
Повлияет ли большое количество ошибок кэша (если элемент был удален) на производительность?
Краткое примечание: я не буду переустанавливать значение, если отсутствует кеш, просто проверяю его наличие
Рассмотрим случай, когда на вашем веб-сайте вы хотите запретить двойные действия (например, дважды нажмите кнопку PAY на вашем веб-сайте, чтобы зарегистрировать два платежа). Мы не имеем дело с оплатой в нашем случае).
Простым трюком было бы удерживать действия пользователя в Memcached в течение короткого периода времени — Есть гораздо лучшие способы сделать это, конечно, — и проверьте, был ли сделан тот же звонок в течение последних нескольких секунд.
Теперь вы можете либо установить кэш на короткий период, и проверить, существует ли то же действие для пользователя в кеше или нет. Или установите last_user_action кэш-памяти на длительный период, а также время действия, и приложение может проверить время по сравнению с запланированным периодом.
Предостережение в течение коротких периодов будет иметь много удалений кэша (ключей с истекшим сроком действия) и много пропусков кэша (так как элемент был удален). Более длительный период будет использовать только больше памяти.
Итак, я хотел бы знать дополнительные издержки, связанные с большим количеством удалений (просроченных элементов) и отсутствием кэша.
Не ври Ленивой Плите
Ваши тайм-ауты должны точно соответствовать тайм-аутам вашего приложения, желающим получить запись назад (при условии, что у вас все в порядке с неопределенностью в 1-2 секунды). Вы не будете значительно увеличивать количество кеша, пропускающего внутреннюю память memcache, или вызывать некоторую форму блокировки, если истекает срок действия многих записей в то же время. Но вы позволите memcache перестать обрабатывать и возвращать элемент, который вашему приложению нужно будет просто выбросить.
Вы можете найти описание поведения memcached в Мониторинг: почему curr_items не уменьшается после истечения срока действия элементов? По сути, он не делает ничего активного с просроченной записью, вместо этого:
Истек срок действия, обнаруженный:
получить
не возвращайте это и отметьте это бесплатно
хранить
всегда запускает сначала получить логику, так что теперь Можно повторно использовать пространство предмета
Выселение LRU (запускается магазином в полном кэше)
не увеличивайте статистику выселения, так как срок действия этого предмета истек.
Мотивированный Slab Crawler ищет процессор и блокирует конфликт?
В ответе на часто задаваемые вопросы не упоминается о том, что теперь вы можете дополнительно иметь поток искателя LRU, но это характер распределителя блоков, поскольку этот поток имеет относительно небольшие накладные расходы, «освобождающие» записи с истекшим сроком действия, и эта работа окупается за счет упрощения последующих обходов. ,
Не забывайте, что memcache — это LRU Cache
Всегда с осторожностью вызывайте нежелательные выселения LRU:
Если вы также используете общий кэш с аналогичным размером, но с более долгоживущими записями, вы можете вызвать их выселение (что предотвращает дополнительный искатель).
Если вы позволите ops * seconds * slab_size(entry)
чтобы приблизиться к размеру кэша, записи начнут исчезать до истечения срока их действия.
Но вы можете наблюдать это в статистике выселения и можете протестировать с искусственным трафиком и / или пропорционально уменьшенным пространством кеша.
Если он будет перезапущен (или ваша конфигурация изменится, или не синхронизируется между экземплярами приложения, или …?), Вы можете не найти запись, которая не является проблемой в случае использования кэша, но в вашем случае у вас будет быть осторожным, чтобы запретить операции в течение периода задержки.
Учитывая (1) и (2), я, вероятно, не поделился бы особым случаем использования, когда элемент не поддерживается безопасно повторяемой операцией с вашим кешем общего назначения.
Других решений пока нет …