Exact Online: The remote server returned an error: (429) Too Many Requests. (Too Many Requests) の問題が解決された後も、また正常に動作していないようです。他の日や週と特に何も変わったことをしていないのに、再び「Too many requests(リクエストが多すぎます)」というメッセージが表示されます。
上記のように表示されているメイン画面の「ライセンス使用状況」のスクリーンショットを追加していただけますか?
数値が赤く表示されている場合、マウスカーソルをバーの上に乗せたときに表示される3つの数字(パーセンテージと2つの数値)も追加していただけますか?
アドバイスとしては、タイムライン上でどのリクエストの処理時間が長いかを確認することをお勧めします。これはInvantive Cloudの左側のメニューから確認できます。
例えば、このリクエストは10分かかっていますが、PjtTimeTransactionsIncrementalを使えば、おそらく数秒で完了します:
さらに、ダウンロードを全て同時に開始しないこともお勧めします。開始時刻は05:00のようなきりの良い時刻ではなく、04:53のようにばらつかせてください。
また、02:00前後にダウンロードを開始しないこともお勧めします。この時間帯はシステムがメンテナンスのためダウンしていることが多く、その分の追加の処理時間が合計に加算されてしまいます。04:00 UTC以降に開始する方が良いでしょう。
以下の例は、多くのリクエストが一斉に実行され(待機している)様子を示しています:
さらに、フレッシュデュレーションのレートリミッターに一時的に余裕を持たせることが可能かどうかも検討する予定です。
長い処理時間は「too many requests」とは関係ないように思うのですが、どうでしょうか？
とはいえ、ご指摘ありがとうございます。それは必ず解決したいと思っています。
どのレポートなのか、どうやって調べればいいでしょうか？SQL文には「[Division] = :w1」としか返ってきません。
更新のタイミングを混同してしまいました。残念ながら分単位での選択はできません。Power BI Serviceでは30分単位か1時間単位でしか指定できないんです。
「Too Many Requests」というメッセージは、HTTP標準に基づく汎用的なメッセージ(HTTPステータス429)であり、サービスの利用が過度に集中していることを示しています。Invantive Cloud内では、これはリクエスト数が原因である場合もありますが、処理時間、APIコール数、行数など他の制限を超過した場合も考えられます。
原因を特定するためには、以下に記載されているようにリファレンスを追加することをお勧めします:
例えば、すべてのクエリで以下のOData.Feedを使用し、enter-your-chosen-id-for-the-sourceの部分を変えるようにします:
Bron = OData.Feed("https://bridge-online.cloud/3279/odata4/", null, [Implementation="2.0", ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=[Referer = "enter-your-chosen-id-for-the-source" ], Timeout=#duration(0,4,0,0)]),
リクエスト時に表示されるリファラーによって、発信元を特定することができます。
過去と比べて特に変わったことをしていないのに、またこれが出てしまいます。一日が始まったばかりなのに。
早急に直してもらえますか?お客さんが今日数字を報告しないといけないんです。
アドバイスは以下の通りです:
- アドバイス1: refererを追加した後、以前の返信に記載されている手順に従ってください:
- アドバイス2: さらに、エラーを返すリクエストIDをここに追加していただけます。そのHTTPヘッダーには、どの基準が超過しているかが含まれています。
- アドバイス3: 最後に、Invantive CloudまたはInvantive Bridge Onlineのホームページに表示されているライセンス使用統計のスクリーンショットを追加することをお勧めします。
アドバイス1：すでに実施済みです：
アドバイス2：赤色のものが複数見られますが、例えば 0HNJIOCHK3BGE:00000013
アドバイス3：スクリーンショットをご覧ください
「新鮮期間」の延長が一時的に最大500%まで設定されました。
上記で説明した通り、ダウンロードを最適化することをお勧めします。
彼は更新を実行していますが、ID 0HNJJ6QQ3ES03:0000000F がひどく時間がかかっています。
select t.\[Account\], t.\[AmountDC\], t.\[CostCenter\], t.\[CostUnit\], t.\[Date\], t.\[Description\], t.\[Division\], t.\[FinancialPeriod\], t.\[FinancialYear\], t.\[GLAccount\], t.\[InvoiceNumber\], t.\[Item\], t.\[JournalCode\], t.\[Quantity\], t.\[Type\]
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
where Division in (:w1, :w2, :w3, :w4)
これがこんなに時間がかかるのは、何が特殊なのでしょうか?
これにはさまざまな原因が考えられます。最初の分析を行う際に最も便利な方法は、「履歴(Historie)」画面からリクエストIDでこのリクエストを検索することです。
そうすることで、処理時間、API呼び出し回数、データ量といったさまざまな特性を確認できます。
また、「セッションI/O(Sessie I/O’s)」ボタンをクリックすると、関連するAPI呼び出しの長さ、時刻、所要時間へと進むことができます。
*Incrementalテーブルに関するより一般的な情報は、以下をご覧ください。
この質問は1週間操作がなかったため、自動的にクローズされました。最後に投稿された回答が解決策としてマークされています。
問題が再発した場合は、別のトピックで新しい質問を立ててください。新しい質問には、このトピックへのリンクをURLとして本文に貼り付けてご記載ください。