Когда кеш растёт не в ту сторону

В папке кеша этой службы лежат четыре маленьких файла. Самый большой — 35 байт. Вместе они содержат три номера счётчиков, и их читают при каждом обращении к счётчику.

Они есть, чтобы путь подсчёта не задавал базе четыре вопроса, на которые почти всегда отвечает «нет». Исключает ли этот счётчик собственные визиты владельца? Считает ли исходящие клики? Отслеживает ли пути по сайту? Перезагружает ли сам себя? Более чем для 99 % счётчиков каждый ответ — нет, и файл с горсткой номеров, где ответ «да», обходится дешевле, чем четыре запроса по индексу.

Обходится дешевле. И это та дешевизна, которая переворачивается.

Что измеряли

Один и тот же вопрос — «есть ли этот счётчик в списке?» — заданный двумя способами, при шести длинах списка. Путь через файл: прочитать, разобрать JSON, поискать номер. Путь через базу: один подготовленный запрос к столбцу с индексом. По две тысячи повторов, пять кругов, взята медиана.

При нынешнем размере файл выигрывает в восемь раз: 0,0202 миллисекунды против 0,1630. При тысяче номеров они вровень. При десяти тысячах файл стоит в двенадцать раз дороже, а при ста тысячах — в 135 раз, потому что к тому моменту это 578 килобайт, которые надо прочитать и разобрать при каждом обращении.

Линия базы не движется. 0,16 миллисекунды при двух строках и 0,16 при ста тысячах: для этого индекс и нужен, и легко забыть, сколько работы скрыто за такой скучной линией.

Неудобная часть

Пересечение — между 100 и 1 000 номерами. У этой службы 2 218 счётчиков, у которых за последние тридцать дней были обращения.

Значит, если бы исключение оказалось успехом — если бы каждый, у кого есть счётчик, включил «не считать мои собственные визиты» — файл содержал бы 2 218 номеров, весил 11 килобайт и стоил 0,43 миллисекунды на обращение вместо 0,02. При вчерашних 18 423 обращениях это восемь секунд работы в день ради того, чтобы избежать запроса, который занял бы три.

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

Почему это всё же остаётся

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

Три номера в трёх файлах. В восемь раз дешевле альтернативы, на машине, где путь подсчёта — единственное, что обязано быть быстрым. Заменить это сейчас запросом, который он обыгрывает, значило бы получить худшую систему, оправданную предположением.

Не хватает растяжки, а не переделки. Файл и так пишется из базы — кодом, который меняет настройку. Это и есть естественное место, чтобы заметить, что список перевалил за несколько сотен записей, и сказать об этом. Кеш с записанным потолком — это решение. Кеш без потолка — это пари, на которое никто не соглашался.

Общая форма

Это не довод против кеша в файле. Это довод за то, чтобы знать, в какую сторону растёт ваш кеш.

Большинство кешей под нагрузкой становятся лучше: больше запросов, больше попаданий, лучше доля. Этот — другого рода. Его стоимость на запрос зависит от того, сколько он в себе держит, а держит он то, что растёт вместе с делом, которое служба и хочет поощрять. Каждое чтение платит за каждую запись, включая те 2 215, которые не имеют отношения к посетителю, считаемому прямо сейчас.

Вопрос к любой справочной таблице в памяти или в файле не «насколько она быстра», а «отчего она растёт и что будет, когда это пойдёт хорошо». Если ответ «станет медленнее», ограничение размера принадлежит коду — рядом с тем, что пишет файл, в тот день, когда его строят.