`GET /api/v1/sdk/ruleset` stops answering under sustained overload and does not recover after a pause

クローズ
  • 何か問題がありますか？
#1,728 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #1754 @amarkanday による — マージ済み

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
api, backend, performance

調査の方向性

Start by locating the handler for GET /api/v1/sdk/ruleset and the in-process tests for that route. Read how the handler manages requests under load, then add a test that drives it past capacity and fails on release 0.42.0. Done when the test shows the route continues answering some requests during overload and recovers after load pauses.

索引モデルが issue の本文から書いたものです。

説明

bug

What happens

Under sustained overload, GET /api/v1/sdk/ruleset stops answering altogether, and it is still not answering after the load
has paused for 12 to 17 seconds.

Seen in all three runs of the ruleset scenario in scale measurement run 41732112985 (release 0.42.0, GitHub-hosted runners,
two different CPU models). In each run, at the first step the API could not keep up with:

  • answered requests fell to zero for the rest of the step (after 6 to 30 seconds of normal answers);
  • the API's CPU use fell (from about 65-71% to 13-40% of a core) instead of staying saturated, and the database had no
    active connections serving it;
  • the proxy recorded every request in that stretch as closed by the client (499);
  • the next step started after a 12-17 s pause and answered nothing from its first second (0 of 2,268, 0 of 2,856 and 0 of
    3,598 requests).

What should happen

Past its capacity, the route may slow down or refuse some requests, but answered throughput should not collapse to zero, and
the route should answer normally again soon after the load drops.

Why it matters

Server-side SDKs in local-evaluation mode poll this route to refresh their rules. During a stall they keep serving their
last-known rules, as designed, but cannot pick up a change, so a flag change or a kill switch does not reach them until the
route recovers.

Notes

  • Priority: medium, before launch (D213: it touches use case #4, server-side local evaluation).
  • The measurement's report labelled these steps as database-bound ("serialised"). That label is wrong for this case and is
    being corrected in the scale harness as part of #1608. The run itself is discarded from the published evidence.
  • A fix needs an in-process test that drives this route past its capacity and fails on 0.42.0's code.
主要言語
Python
スター
0
フォーク
4
平均マージ
5時間 36分
マージ済み PR（30日）
509

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Controlvar/controlvar のほかの issue

Controlvar/controlvar の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。