3

現在、ServiceStack (v3.9.60) を使用する Web サービスがあります。この Web サービスは、現在 (New Relic の監視ごとに) 1 分あたり平均 600 リクエストを取得しています (2 つの Windows 2008 Web サーバーで負荷分散されています)。

コード化されたリクエスト サービス (リクエスト フィルターを含む) で費やされる実際の時間は、平均で約 5 ミリ秒かかります (記録された log4net ログからわかることから)。これは、リクエストを ActiveMQ エンドポイントにオフロードし、ServiceStack に 204 (Return204NoContentForEmptyResponse が有効になっている) を自動的に生成させます。 「public void Post(request)」で)

その上に、次のものがあります。

PreRequestFilters.Insert(0, (httpReq, httpRes) =>
{
    httpReq.UseBufferedStream = true;
});

これは、正しいソースからのものであるという承認の理由から、リクエスト フィルター中にソルト化されたハッシュ値 (カスタム ヘッダーとして渡される) を検証するために未加工の本文を使用するためです。

全体として、New Relic では、Web サービスの呼び出し全体に平均で約 700 ミリ秒かかっていることがわかります。これは、コード化されたプロセスを実行するのに実際にかかる 5 ミリ秒と比較するとかなり長いです。そのため、New Relic レポートのデータを詳しく調べたところ、一部のリクエストには定期的にかなりの時間がかかることがわかりました (リクエストごとに 10 ～ 150 秒)。New Relic のレポートを掘り下げると、事前リクエスト フィルターの適用に時間がかかることがわかります (以下の画像。)なぜそうなるのか、また、それが Http Request オブジェクトのバッファリングされたストリームに関連しているのか、また、これを修正するにはどうすればよいのだろうかと考えていました。

ここに画像の説明を入力

編集

これでいくつか遊んでいますが、まだ答えが見つかりません。

やった事:

  1. 実際のサイト フォルダーのサブフォルダーの場所から仮想フォルダーを移動しました (このサイトの下には、約 11 の他の Web サービスがあります)。

  2. 独自のアプリケーション プールを使用するようにこの Web サービスを割り当てたので、メイン サイトやサイト内の他の Web サービスと共有されません。

  3. Phil が提案したように、Server GC を使用するための要件を Web.Config に追加しました

  4. バッファリングされたストリームの使用をオンにする事前要求フィルターを無効にしました (そして、RawBody を使用したコードをバイパスします)

  5. ドリルダウンを改善するために、New Relic にインストルメンテーションを追加しました (下の画像を参照)。

これは負荷による Windows Server/IIS の制限ではないかと考え始めています。しかし、そのようなことにもっと精通している誰かから聞きたいです。

ここに画像の説明を入力

4

0 に答える 0