Прототип Cloudflare сжал текст в кэше в 2,8 раза ценой пары процентов CPU

Cloudflare 1 сентября описала прототип Cache Transcoding: подходящие ответы сжимаются алгоритмом zstd перед записью на диск кэша и перед передачей между уровнями Tiered Cache, а перед выдачей клиенту распаковываются. В тестах компании подходящие объекты стали занимать в среднем треть исходного места. Для тех, кто держит собственный кэширующий прокси или CDN, это готовая схема обмена дешёвого CPU на дорогой диск.

Автор публикации Ааши Патель из Cloudflare объясняет мотивацию просто: память и диски дорожают, а кэш-серверы Cloudflare хранят огромный объём текста, который origin-серверы отдают без сжатия. Прототип реализован внутри Pingora, прокси-фреймворка компании на Rust.

Почему сжимать пришлось именно в кэше

Казалось бы, текст в интернете и так сжат. Но по замерам Cloudflare около 71% текстовых ответов приходят от origin-серверов без заголовка Content-Encoding: сжатие для клиента делает уже edge-сервер, а на диск кэша объект ложится сырым. При этом HTML, JSON, CSS и JavaScript составляли 67,3% запросов и 22,3% байтов, а медиа и шрифты 21,4% запросов и 63,3% байтов. Пересжимать медиа бессмысленно: оно уже сжато своими кодеками. Значит, целевая доля кэша, где сжатие даёт эффект, это примерно пятая часть байтов.

Ключевая фраза публикации: «стоимость кодирования оплачивается один раз, когда объект попадает в кэш» (перевод редакции). Дальше объект читают многократно, а декодирование почти в три раза дешевле кодирования. Между дата-центрами через Tiered Cache объект едет уже сжатым, и это экономит ещё и междатацентровый трафик.

Путь объекта через уровни кэша в прототипе Cache Transcoding. Источник: Cloudflare

Критерии и цифры

В прототипе сжимались только ответы 200 OK с тремя условиями: заголовок Content-Encoding не задан, тип содержимого сжимаемый, известен Content-Length не меньше 4 КиБ. Range-запросы, уже сжатые ответы, тела неизвестной длины и бинарное содержимое проходят без изменений. Порог 4 КиБ исключил много мелких запросов, но потерял, по расчётам компании, около 1% потенциально сжимаемых байтов: «сжатие всего подходящего текста от 4 КиБ и выше дало почти всю измеренную экономию места».

Замеры производительности проводились на более чем миллионе запросов через 10 кэш-серверов. Коэффициент 2,834x получен на двух тестовых объектах размером около 195 и 272 КиБ, а не на всём кэше сервиса. Кодирование zstd уровня 3 стоило 4,31 нс на байт, декодирование 1,56 нс на байт. Дополнительная нагрузка на CPU при выбранных предположениях, по оценке Cloudflare, составила несколько процентов. Это замер вендора на его трафике; на другом профиле содержимого доля текста и коэффициент будут иными.

Как повторить у себя

Приём применим к любому кэширующему слою, где объекты хранятся на диске и читаются чаще, чем пишутся: nginx с proxy_cache, Varnish, самописные кэши на Pingora или Go. Порядок действий по мотивам публикации:

1. Измерить долю ответов без Content-Encoding и их суммарный объём: если origin уже сжимает всё, выигрыша не будет.
2. Ограничить кандидатов по типу содержимого и размеру; порог 4 КиБ у Cloudflare покрыл почти всю экономию.
3. Сжимать один раз при записи, хранить сжатым, декодировать при выдаче; прототип Cloudflare всегда декодирует объект, а отдачу сжатого представления клиенту напрямую компания называет будущей работой.
4. Считать CPU: при 232 МБ/с на кодирование одно ядро обслуживает ограниченный поток записи, и на серверах с высокой долей промахов кэша это может стать узким местом.

Для российских хостингов и собственных CDN аргумент тот же, что у Cloudflare: диски и память дорожают, а zstd есть в любом дистрибутиве и в библиотеках для всех основных языков. Cloudflare описывает внутренний прототип, а не продукт, поэтому ни включить, ни купить эту функцию нельзя; повторять придётся у себя.

Что осталось проверить

Компания перечисляет открытые вопросы: другие уровни zstd, другие типы объектов, range-запросы и предварительно сжатые ответы. Zstandard, напомним, разработан Янном Колле и открыт в 2016 году; в более раннем тестировании Cloudflare он сжимал на 42% быстрее Brotli и давал файлы на 11,3% меньше gzip при сопоставимой скорости. Редакция проверит, дойдёт ли прототип до боевой сети и появятся ли цифры по общей экономии.

Источник: Блог Cloudflare: Cache Transcoding

Изображение на обложке: Cloudflare