Избыток производительности при коротких таймаутах в Memcached

Question

Мне интересно, будет ли иметь короткий тайм-аут (60 секунд) в memcached какое-либо негативное влияние на производительность, VS более длинные тайм-ауты, но игнорируя возвращаемое значение (если оно было сохранено более 60 секунд назад).

Повлияет ли большое количество ошибок в кэше (если элемент был удален) на производительность?

Краткое примечание: я не буду переустанавливать значение, если отсутствует кеш, просто проверяю его наличие

Пример сценария:

Рассмотрим случай, когда на вашем веб-сайте вы хотите запретить двойные действия (например, дважды нажмите кнопку PAY на вашем веб-сайте, которая регистрирует два платежа. В нашем случае мы не имеем дело с платежами).

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

Теперь вы можете либо установить кэш на короткий период, и проверить, существует ли такое же действие для пользователя в кеше или нет. Или установите кэш last_user_action на длительный период вместе со временем действия, и приложение может сравнить время с запланированным периодом.

Предостережение в течение коротких периодов будет иметь много удалений кеша (ключей с истекшим сроком действия) и много пропусков кеша (так как элемент был удален). Более длительный период будет использовать только больше памяти.

Итак, я хотел бы знать дополнительные издержки, связанные с большим количеством удалений (просроченных элементов) и отсутствием кэша.

Answer 1

Не ври Ленивой Плите

Ваши тайм-ауты должны точно соответствовать тайм-аутам вашего приложения, желающим вернуться назад (если вы в порядке с неопределенностью в 1-2 секунды). Вы не будете значительно увеличивать количество кеша, которое пропускает внутренняя память memcache, или вызывать некоторую форму блокировки, если истекает срок действия многих записей в то же время. Но вы позволите memcache перестать обрабатывать и возвращать элемент, который вашему приложению нужно будет просто выбросить.

Вы можете найти описание поведения memcached в Мониторинге: почему curr_items не уменьшается, когда истекает срок действия элементов? По сути, он не делает ничего активного с просроченной записью, вместо этого:

Истек срок действия, обнаруженный:

• получить

  не возвращайте это и отметьте это бесплатно

• хранить

  всегда запускает get logic в первую очередь, так что теперь он может повторно использовать пространство элемента

• Выселение LRU (запускается магазином в полном кэше)

  не увеличивайте статистику выселения, так как срок действия этого предмета истек.

Мотивированный Slab Crawler ищет процессор и блокирует конфликт?

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

Не забывайте, что memcache - это LRU Cache

1. Всегда с осторожностью вызывайте нежелательные выселения LRU:

   • Если вы также используете кеш с аналогичным размером, но с более долгоживущими записями, вы можете вызвать их выселение (что и предотвращает необязательный сканер).

   • Если вы позволите ops * seconds * slab_size(entry) чтобы приблизиться к размеру кэша, записи начнут исчезать до истечения срока их действия.

   Но вы можете наблюдать это в статистике выселения и можете протестировать с искусственным трафиком и / или пропорционально уменьшенным пространством кеша.

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

3. Учитывая (1) и (2), я бы, вероятно, не стал делиться особым случаем использования, когда элемент не поддерживается безопасно повторяемой операцией с вашим кешем общего назначения.