Водопад против параллели
Четыре независимых запроса примерно по 60 мс — сначала по очереди, затем все сразу.
Устранение задержек как архитектура, а не набор приёмов: оптимистичные мутации, уровни кэша, защита от лавины запросов, отложенный хвост — каждое измерено против наивной версии.
Каждое число на этой странице измерено в том запросе, который его запросил. Ничего заранее сохранённого здесь нет.
Четыре независимых запроса примерно по 60 мс — сначала по очереди, затем все сразу.
Одно значение читается трижды: каждый раз пересчитывается, затем читается через кэш. Каждое обращение к источнику стоит около 60 мс.
Две политики, одно значение, оба состарены за пределы TTL в 1 с. Одна объявляет окно устаревания, другая — нет. Занимает около 1200 мс — это ожидание И ЕСТЬ истечение TTL.
100 одновременных промахов по одному значению. Смотрите на число обращений к источнику, а не на часы — именно это почувствовала зависимость.
Запись примерно на 60 мс плюс три следствия: сначала дождались их до ответа, затем отложили после него.
Симулируется именно зависимость — она спит вместо запроса к Postgres, чтобы публичная страница не могла нагрузить базу, а фиксированная стоимость сохраняла сравнимость ветвей. Механизмы настоящие.
Думаете, этот паттерн можно сделать лучше? Расскажите как.
Оставить отзыв