From 74fc0ffa026acd14acd3d05488255575cc606d2b Mon Sep 17 00:00:00 2001 From: Tim McCormack Date: Mon, 16 Dec 2024 15:01:40 -0500 Subject: [PATCH] temp: Add temporary monitoring for large memcache keys (#36034) 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 2f7e6dc623a..723ca87098d 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