15 мс на ответ: как мы добились высокой скорости работы API Gateway

[olku]

Зачем инвалидация по ресурсу, если он отдает заголовок etag? Зачем инвалидация по времени если ресурс отдает заголовки кеширования? Зачем инвалидация по частоте если достаточно вытеснения по ограничению памяти? Посмотрите кеширование Nginx, оно значительно лучше latency в 15мс. Тема API Gateway не раскрыта.

[Kokoulin]

Все взаимодействие с мастер системами происходит на базе gRPC, к тому же мы не являемся мейнтейнерами мастер систем и не можем вносить в них изменения когда нам это нужно. Заголовков кэширования и etag там нет. Кэширование nginx (и надстроек над ним) к сожалению нам не подходит так как у нас не умеют его готовить. К тому же мы можем собирать ответы на большой запрос из разных кусков кэша (читай агрегировать) данные так как нам нужно

[olku]

Контекст многое объясняет, спасибо. Товарищ делал прокси на расте, смотрите Sequential requests на https://github.com/evgenyigumnov/cblt-next Мелкие джейсон запросы больше 5 мс - это очень плохой прокси. За 15 мс техдир может заставить изучить Nginx. Для сравнения, однажды пришлось делать встроенный в приложение прокси, так вот его latency было 0.3-0.4 мс.

[Kokoulin]

Тут 15мс это среднее на 99 персентиле, запросы из кэша без агрегации отдаются за 2-4мс, но иногда нам нужно сходить в редис и там будет 8-10 просто из за потерь на уровне сети. А изредко надо сходить в мастер систему и там будет 15-25мс.

[izibrizi2]

В нашей системе пользователи часто делают выборки по сложным фильтрам, что создает дополнительную нагрузку на сервисы - какие фильтры, какая нагрузка? Грепом фильтруете?

[Kokoulin]

В зависимости от ручки там может быть от 1 до 18 параметров фильтрации, плюс одна из мастер систем ожидает gQL. Мы кэшируем атомарные сущности и для некоторых запросов мы можем из кэша собрать ответ на запрос который еще не попадал в кэш.