Сравнивать один сценарий
Условный пример с десятичными килобайтами: сначала 100 вызовов по 100 kB, затем 20 по 50 kB. Объём уменьшается с 10000 до 1000 kB, на 90 %. Такое же сокращение задержки из этого не следует. Учитываются только тела ответов, без запросов и заголовков.
| Условный показатель | Исходный | Кандидат |
|---|---|---|
| Вызовы | 100 | 20 |
| Объём ответа | 100 kB | 50 kB |
| Общий объём | 10000 kB | 1000 kB |
| Длительность сценария | Измерить | Измерить |
Сначала сокращать работу
- Запрашивайте нужные поля и соблюдайте правила пагинации. Пакетам нужны ограничения и обработка частичных результатов; большая страница не всегда быстрее.
- Повторно используйте соединения и ответы при допустимых контексте и свежести. Ограничивайте параллелизм, измеряйте очереди и работу сервера.
- Задайте общий срок и предел попыток. Разносите повторы временных сбоев случайной составляющей ожидания; проверьте повторы на всех уровнях.
Не выполнять завершённое действие дважды
Тайм-аут клиента не доказывает отмену на сервере. До повторного создания или платежа проверьте состояние и механизм идемпотентности поставщика. Сравните длительность, ошибки и правильность при типичной нагрузке.
Первоисточники
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Анализ работы, стоящей за одним ответом API.
Один запрос GraphQL может инициировать множество последующих вызовов. Задержка, видимая клиенту, может скрывать стоимость резолверов, списков и пройденных связей.
- Отслеживание операции от клиента до последующих сервисов.
- Сравнение стоимости поля и фактически полезного объема.
- Ограниченные списки и повторяющиеся запросы перед кэшированием.
Первичный источник: OWASP — GraphQL Cheat Sheet. Связанный метод: прочитать практическое руководство.
Retry-After: ожидание, бюджет и повтор
Подробные справочные заметки в этой версии доступны на английском.
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS