From 741d0b1efa3f2e48cb35e8500f2620ba5942b15d Mon Sep 17 00:00:00 2001 From: Tim McCormack Date: Mon, 16 Dec 2024 18:13:00 +0000 Subject: [PATCH] temp: Add temporary monitoring for large memcache keys We'd like to finish the removal of MD4 key hashing, but want to know if cutting over to BLAKE2b will cause too large a cache turnover. Hopefully this monitoring will give us some insight into the rate of large keys. --- common/djangoapps/util/memcache.py | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/common/djangoapps/util/memcache.py b/common/djangoapps/util/memcache.py index 2f7e6dc623a0..723ca87098d1 100644 --- a/common/djangoapps/util/memcache.py +++ b/common/djangoapps/util/memcache.py @@ -9,6 +9,7 @@ from django.conf import settings from django.utils.encoding import smart_str +from edx_django_utils.monitoring.utils import increment def fasthash(string): @@ -48,9 +49,18 @@ def safe_key(key, key_prefix, version): # Attempt to combine the prefix, version, and key combined = ":".join([key_prefix, version, key]) + # Temporary: Add observability to large-key hashing to help us + # understand the safety of a cutover from md4 to blake2b hashing. + # See https://github.com/edx/edx-arch-experiments/issues/872 + increment('memcache.safe_key.called') + # If the total length is too long for memcache, hash it if len(combined) > 250: combined = fasthash(combined) + # Temporary: See + # https://github.com/edx/edx-arch-experiments/issues/872 and + # previous comment. + increment('memcache.safe_key.hash_large') # Return the result return combined