Кэширование новостной ленты

С момента начала сбора статистики (5b6ea6b652b4a3d56b0012bbf9c9bff4efa543b5)
я не раз поменял способ её хранения. Такое ощущение, что страдаю какой-то
фигнёй, как школьник решаю задачки.

Bolt использует mmap -- это не нравится. Да и захотелось мне всё же
иметь и статистику когда именно какие запросы были сделаны, а не только
агрегированную.

В итоге сейчас делаю так: XXH128 (потому что быстрый) хэш от URL пути с
доменом используется как путь к файлу. В файл append-only записываю:
TAI64 времени запроса, 64-бит длина ответа, 16-бит код ответа, 48-бит
нулей (выравнивание, плюс некий маркер для нахождения записей если байт
будет побит). Агрегирование и фильтрация данных из таких файлов будет
делаться, грубо говоря, со скоростью последовательного чтения файла.
Плюс оно хорошо сжимается на ZFS.

Так вот увидел только на VPS-ке, за неделю работы, такое:

200 ответы:
    blog.stargrave.org/feed.atom     | 23,578 | 943 MiB
    blog.stargrave.org/comments.atom | 21,063 | 743 MiB

304 ответы:
    blog.stargrave.org/feed.atom     | 4,336
    blog.stargrave.org/comments.atom | 54

То есть, менее пятой части feed.atom кэшируется у клиентов.

Затем вспомнил: ведь у меня же мониторинг дёргает постоянно блог. И по
идее это половина запросов (60*24*7). Затем вспомнил, что мониторинг у
меня по всем адресам проходится (IPv4, IPv6), а значит это ещё на два
умножить. Получается, что почти все запросы и трафик -- только от
мониторинга моего. Благо, хотя бы ответы там сжатые, а это более чем в
два раза экономия трафика. Но надо будет исправлять это, ибо куча
трафика впустую.