Memcache Malarkey

Если ключ не находится в кеше, запросите его, установите его и продолжайте. Код игнорирует возвращаемые значения из set (), так как в случае ошибки мы на самом деле ничего не будем с этим делать. Чтобы отладить проблему, мы добавляем функцию обратного вызова, чтобы увидеть ответ. Странно, с этого момента все заработало! Мы могли видеть команды «set», идущие в memcached из скрипта dtrace. Углубившись вглубь вызова функции set (), мы обнаружим, что это на самом деле проблема с модулем npm, который мы используем для обработки memcached. Если обратный вызов не предоставлен функции set (), модуль проверки модуля не видит его как функцию и считает, что существует несоответствие типов. Затем он пытается вернуть ошибку, используя предоставленный обратный вызов, который не существует, поэтому он ничего не делает; молча терпит неудачу. Это ужасный случай провала.Если требуется функция обратного вызова, она должна выйти из строя громко и немедленно. Если это не требуется, то он должен продолжать работать, как ожидается; при условии, что с запросом ничего не случилось. Весь остальной код пакета написан для правильной работы, если не предоставлен обратный вызов, поэтому изменение функции проверки в исходном коде модуля npm для разрешения неопределенных обратных вызовов — это все, что было необходимо.

Мы создали проблему в репозитории github модуля и отправили в проект запрос на извлечение с тестовым примером. Посмотрим, согласны ли они.

Кэширование для отрицательных ответов

Следующей по значимости причиной пропуска кэша была распространенная ошибка. При проверке кэша мы часто говорим: «Каково значение X?» Если мы не найдем его, мы проверим достоверный источник. Но что, если у авторитетного источника его тоже нет? Часто мы просто идем дальше. Взять, к примеру, код отслеживания, отправленный на страницу покупки. Определенные коды автоматически дают кому-то скидку 10%, поэтому нам нужно проверить, является ли это специальный код. Если это не так, то мы ничего не делаем. Это был один из тех случаев. Однако в подавляющем большинстве случаев большинство этих поисков ничего не возвращают, поскольку они использовались только для отслеживания. «Ничто» также является значением и может быть кэшировано. Кэшируя отрицательный ответ или отсутствие значения, страница может продолжать избегать медленного поиска в базе данных. Это улучшает время загрузки страницы в общем случае.Важно помнить ваши бизнес-правила для аннулирования этих данных. Если добавляется скидка, сколько времени понадобится истечению ваших значений в кэше, чтобы отразить новое значение?

Не возвращай то, что ты уже знаешь

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

Есть много вещей, которые люди ненавидят в объектно-ориентированном программировании, но особая любознательность заключается в том, что подход «черного ящика» часто скрывает, насколько дорогими могут быть конкретные вызовы. У этого клиента есть несколько разных представлений, которые могут отображаться для страницы в зависимости от контекста, и часто разные варианты поведения включаются / выключаются в зависимости от этого конкретного представления. Эти флаги будут предоставлены путем создания объекта Page и проверки его. например:

my $page = new PageObject( $request );
if( $page->do_the_thing() ) {
  // Do the thing.
}

get WETtYDA0:1:999999.9', NOT FOUND
get union, NOT FOUND
get all, NOT FOUND
get WETtYDA0:1:CertifiedWinnerRSP, FOUND KEY
get WETtYDA0:1:default, FOUND KEY
get WETtYDA0:1:999999.9', NOT FOUND
get union, NOT FOUND
get all, NOT FOUND
get WETtYDA0:1:CertifiedWinnerRSP, FOUND KEY
get WETtYDA0:1:default, FOUND KEY
get WETtYDA0:1:999999.9', NOT FOUND
get union, NOT FOUND
get all, NOT FOUND
get WETtYDA0:1:CertifiedWinnerRSP, FOUND KEY
get WETtYDA0:1:default, FOUND KEY

https://dev.site.com/page?.9%27%20union%20all%20

“999999.9' union all”

'WETtYDA0:1:999999.9unionall'