Производительность
N+1: тест с множественным выбором
Суть Синтез всего юнита N+1 в формате выбора — стоимость round-trip, выбор семейства фикса по cardinality, DataLoader, off-CPU детекция, исчерпание пула и DoS-амплификация.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для пересказа, а фикс, который надо выбрать, когда query log перед тобой, а страница тормозит.
Цель
Подтвердить, что ты связываешь модель стоимости round-trip, четыре семейства фиксов, инструменты детекции и вторичные сбои — синтез, к которому вели отдельные уроки.
Викторина
Completed
Страница-список делает 51 запрос по 0.4 мс каждый, но wall-clock — 765 мс. DBA настаивает, что каждый запрос быстрый и индексы в порядке. Как это примирить?
Heads-up Запросы действительно быстрые на стороне сервера. 765 мс — это round-trip latency × 51, а не медленное выполнение. Ускорение каждого запроса тут почти ничего не даёт.
Heads-up Индекс снижает время выполнения запроса, уже равное 0.4 мс. Bottleneck — latency 51 round-trip'а, которую индекс не трогает. Нужно меньше trip'ов, а не быстрее.
Heads-up Время тратится off-CPU в ожидании сокета БД между trip'ами, а не на CPU. CPU-профиль был бы плоским — классическая сигнатура N+1.
Викторина
Completed
Страница грузит 50 заказов, у каждого ~20 line item'ов. Ты фиксишь N+1 через JOIN, количество запросов падает 51 → 2, но p99 ухудшается на 30%. Что произошло и какой фикс?
Heads-up Eager loading почти всегда выигрывает, схлопывая round-trip'ы. Регрессия тут — стратегия JOIN для тяжёлого one-to-many fan-out, а не сам eager loading.
Heads-up Это JOIN, а не IN-запрос — IN-списка нет. Цена — дублирование строк от JOIN, которого IN-based loading избежал бы.
Heads-up Два запроса бьют 51 round-trip по latency; регрессия — раздувание payload от дублирования JOIN. Фикс — IN-based loading, а не возврат к N+1.
Викторина
Completed
GraphQL-запрос me { posts { author { name } } } на 50 постов делает 1 + 50 author-lookup'ов. Почему ORM eager loading (.includes / select_related) это не фиксит, и что фиксит?
Heads-up Каждый резолвер выполняется независимо на родительский объект, без общего места запроса. Некуда прикрепить .includes, чтобы батчить через 50 отдельных author-резолверов — ровно для этого существует DataLoader.
Heads-up GraphQL не имеет мнения о SQL. Блокер — разбросанная, по-резолверная природа lookup'ов, а не запрет JOIN'ов.
Heads-up Это обход, уменьшающий симптом; структурный паттерн 1+N остаётся. DataLoader убирает паттерн независимо от размера fan-out.
Викторина
Completed
REST-агрегатор вызывает 8 downstream-сервисов последовательно по 30 мс каждый (240 мс p99). SQL N+1 на странице-списке тоже стоит ~240 мс. Это одна проблема, и у них общий фикс?
Heads-up Обе — одна форма N round-trip'ов на уровень протокола выше. Вся суть юнита: N+1 протокол-агностичен; различается только механизм батчинга.
Heads-up Параллельный SQL всё равно платит N round-trip'ов и может насытить пул соединений. SQL к одной БД надо батчить в один запрос, а не разворачивать параллельно.
Heads-up Скорость протокола даёт инкрементальный выигрыш. Структурный фикс — схлопнуть trip'ы: батчить SQL, параллелить независимые вызовы сервисов.
Викторина
Completed
Сервис с пулом на 25 соединений начинает отдавать 503 под нагрузкой. Latency отдельных запросов стабильна, БД здорова, но насыщение пула приклеено к ~100%, а очередь запросов растёт. Корневая причина и первый фикс?
Heads-up Увеличение пула отодвигает стену, но переносит контеншн на базу и маскирует причину. Реальный рычаг — короче hold-time соединения, достигаемый убийством N+1.
Heads-up Утечка заставляет active count расти и не восстанавливаться. Здесь соединения освобождаются — просто медленно, потому что каждый запрос гонит ~50 последовательных запросов.
Heads-up Latency отдельных запросов стабильна, значит БД не bottleneck. Приложение держит соединения слишком долго через последовательные запросы.
Викторина
Completed
Публичный GraphQL-эндпоинт даёт клиентам управлять глубиной вложенности и размером страницы. Один сконструированный запрос разгоняет БД до тысяч запросов. Как сениор должен это сформулировать, и какой устойчивый guard?
Heads-up Фикс одного пути помогает, но на публичном эндпоинте с управляемым пользователем fan-out это вектор security/availability. Нужны границы depth/complexity, а не только фикс одного пути.
Heads-up Rate limiting глушит объём, но один дорогой запрос всё равно может амплифицировать тысячи запросов. Надо ограничивать per-request стоимость через depth и complexity limits.
Heads-up Реплики поднимают ёмкость, но атакующий масштабирует fan-out вместе с запросом; ты будешь платить за обслуживание атаки. Ограничивай per-request стоимость запроса.
Итог
Сквозная линия юнита — одно дерево решений: сначала считай round-trip’ы (цена в количестве trip’ов, а не в скорости запроса), затем выбирай фикс по cardinality — JOIN для one-to-one, IN/selectinload для тяжёлого one-to-many, preload когда форма известна на месте запроса, DataLoader когда lookup’ы разбросаны по резолверам, и параллельный dispatch когда независимые сервисы не делят backend. Детектируй off-CPU через query log и APM-waterfall, гейти в CI и помни вторичные сбои: раздувание payload от JOIN, исчерпание пула соединений, переключения query plan и DoS-амплификацию.