本文へ移動
cccskills
無料GitHub で公開日本語紹介

brightdata-rate-limits

Bright Dataの429応答やジョブ上限などの実測情報をもとに、処理経路ごとの並列数、待機時間、再試行の上限を設計します。

原文原文の説明を見る

Analyze and design Bright Data concurrency and backoff controls from observed provider signals and owned budgets instead of invented global limits. Use when handling 429 responses, dataset job ceilings, or uneven proxy pressure. Trigger with: "tune Bright Data concurrency", "handle Bright Data 429", "set a dataset job budget".

jeremylongshore/tons-of-skills-marketplaceスター 2,884(GitHub 2,884 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 429応答への対処を決めたいとき
  • データセットジョブの上限を管理したいとき
  • 再試行と待機時間を設計したいとき

日本語での紹介

できること

Bright Dataの429応答、Retry-After、プロバイダーのエラーコード、稼働中のデータセットジョブ数、キュー状況などを確認し、処理能力を推測ではなく実測情報から整理します。プロキシ通信、Browser APIのセッション、非同期ジョブの起動、進捗確認、ダウンロードなどを別々の経路として扱い、それぞれに並列数やキューの上限を設けます。一時的な失敗で再試行する場合も、対象を限定し、待機時間や試行回数、経過時間に上限を設定します。段階的な検証結果から、変更を維持するか戻すかを判断できるようにします。

こんなときに便利

429応答が増えた原因を調べたいとき、データセットジョブの同時実行数を管理したいとき、再試行によるキューの膨張を抑えたいときに向いています。各処理の予算やエラー記録があると、上限を決める根拠を整理できます。

使い方の例

  • 「最近の429応答とエラー記録から、処理経路ごとの上限を整理してください」
  • 「データセットジョブの上限と再試行条件を決めてください」

注意点

承認済みのBright Dataアカウントまたはテスト用データ、最新のBright Dataドキュメント、許可された公開データ収集の目的が必要です。このスキルは実トラフィックを発生させず、アカウント上限も変更しません。MITライセンスです。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(2)

  • SKILL.md3.6 KB
  • references/official-docs.md771 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Bright Data Adaptive Capacity Control

Overview

Bright Data does not publish one global proxy request limit. Build separate controllers for proxy traffic and dataset jobs, honor current provider signals, and keep target, cost, and policy ceilings stricter than capacity.

Prerequisites

  • A workload profile with target, product, and idempotency classes
  • Observed latency, error, and provider-code samples
  • Owner-approved concurrency, byte, cost, and wall-time ceilings

Instructions

Step 1: Measure the lane

Read recent receipts and Grep for 429, Retry-After, provider error codes, active dataset jobs, per-IP concentration, and queue depth. Do not infer capacity from successful bursts alone.

Step 2: Separate controllers

Write independent limits for proxy requests, Browser API sessions, async triggers, progress polling, downloads, and delivery workers. One product's success must not raise another product's ceiling.

Step 3: Apply evidence-based backoff

Retry only idempotent transient work. Honor provider guidance, use bounded jitter, cap attempts and elapsed time, and open the circuit on policy, authentication, or data errors.

Step 4: Tune gradually

Edit one limit at a time, run an approved canary, compare throughput, error, and cost, and retain the lower limit unless the evidence and owner approve promotion.

Tool Discipline

Use Read and Grep to analyze redacted metrics and documented codes. Use Write and Edit for controller configuration, tests, and runbooks. This skill does not run live traffic or change Bright Data account limits.

Output

  • Per-lane concurrency and queue budgets
  • Retry and circuit matrix by documented failure class
  • Canary comparison with rollback threshold

Examples

If dataset triggers return a tenant-specific parallel-job error, stop launching new jobs and continue bounded progress polling for owned snapshots. If proxy traffic returns a per-IP 429, reduce pressure and review distribution rather than guessing a universal rate.

Error Handling

FailureMeaningResponse
No provider code is retained429 cause is ambiguousImprove redacted instrumentation before tuning
Retries amplify queue depthBackoff lacks admission controlOpen the circuit and drain owned work
Throughput improves but cost or error ceiling failsOptimization violates the budgetRoll back the changed limit

Resources

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

abridge-ci-integration

無料概要あり

Abridge連携コードのCIに合成データを使った回帰チェックを加え、同意状態、ノート確認、ログの秘匿、ロールバックなど顧客側の処理を検証します。

  • Abridge連携の回帰テストを追加したいとき
  • 同意やノート確認の処理を検証したいとき
  • ログに機微情報が出ないか確かめたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-common-errors

無料概要あり

Abridgeの録音、記録の確認、Epicへの引き渡し、アクセスの不具合を観測情報から切り分け、患者情報を抑えた証拠と担当窓口への引き継ぎ資料を整理するスキル。

  • 録音とアップロード障害の切り分け
  • 記録生成の遅延や編集画面の不具合調査
  • Epic連携障害の担当窓口の特定
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-core-workflow-a

無料概要あり

同意確認から録音、生成メモの根拠確認、編集、最終確定まで、臨床文書作成の手順と確認ポイントを整理するスキルです。

  • 診療メモ作成の手順を導入・監査したいとき
  • 同意から医師の確認までの流れを整理したいとき
  • 下書きの根拠確認と停止条件を定めたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-core-workflow-b

無料概要あり

Abridgeで臨床家が確認した記録内容が、承認済みの手順でEpicの適切なテンプレート欄へ渡るか、テスト記録を使って対応関係や例外を検証するスキルです。

  • AbridgeとEpicの記録欄の対応を確認したいとき
  • 部門ごとの連携設定を監査したいとき
  • 承認済みテスト記録で連携を検証したいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-cost-tuning

無料概要あり

Abridgeの導入・更新判断に向け、利用定着率や業務の完了状況、診療記録の品質、支援負担を契約に基づく費用情報と照らし、継続や改善の選択肢を整理するスキル。

  • Abridge導入後の定着率確認
  • 契約更新の判断材料をまとめたいとき
  • 診療環境ごとの業務成果の比較
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

abridge-debug-bundle

無料概要あり

Abridgeの障害調査で、録音や診療記録を含めず、許可した項目だけを集めたサポート用資料と確認用マニフェストを作成します。

  • 障害サポート用の証拠をまとめたいとき
  • 共有資料の除外項目を記録したいとき
  • 調査情報を安全な経路で引き継ぎたいとき
jeremylongshore/tons-of-skills-marketplace2,8842026年10月29日 更新

jeremylongshore のスキルをすべて見る

このスキルの問題を報告する