問題タブ [kestrel]

私は asp.net core 2.0 でサイトを書いています。

未処理の例外が発生しました: 指定された引数が有効な値の範囲外でした。パラメータ名：カウント

スタックトレース：

System.ArgumentOutOfRangeException: 指定された引数が有効な値の範囲外でした。パラメーター名: Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.PipeCompletion.ThrowFailed() でカウント Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.GetResult(ReadResult& result) Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.Pipe.Microsoft.AspNetCore.Server.Kestrel.Internal.System.IO.Pipelines.IReadableBufferAwaiter.GetResult() で Microsoft.AspNetCore.Server.Kestrel.Internal で.System.IO.Pipelines.ReadableBufferAwaitable.GetResult() at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.d__24.MoveNext() --- 例外がスローされた前の場所からのスタック トレースの終わり --- - System.Runtime.ExceptionServices.ExceptionDispatchInfo で。1.<ProcessRequestsAsync>d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Frame1.d__2.MoveNext()

よくわかりませんが、おそらくこのエラーは、asp.net コア 2.0 に移行した後で発生します。

ASP.NET Core 2.0の非同期ビュー コンポーネントを作成しようとしています。ユーザーがページから離れたときにキャンセルするアクションを実行します。次のオプションがあります。

1. HttpContext.RequestAborted の使用
2. CancellationToken パラメーターの使用
3. トークンをチェーンすることもできます

オプション 1 は次のようになります。

オプション 2 は次のようになります。

どちらのアクションも Kestrel では機能しません(バグのようです)。どちらの場合も、トークンは満たされています (おそらく構造体が原因でしょうか?)

違いは何ですか？何を使用すればよいですか？

同じマシンで複数の asp.net コア Web API アプリケーションを実行し、異なるポートをリッスンし、すべてのサービスを同じ kestrel インスタンスで実行することは可能ですか?

ASP.net コア Web API を使用して複数のサービス (マイクロ サービス) を開発する必要があり、同じマシンに展開し、HTTPS と同じ SSL 証明書を使用する必要があります。私の調査結果によると、各サービスは個別の kestrel インスタンスで実行するように構成する必要があるため、サービスごとに同じ SSL を構成するオーバーヘッドがあります。SSL を一度に有効にできるように、すべてのサービスを kestrel の単一インスタンスで実行する方法を見つけようとしています。

Nginx の背後にある高速な SSD サーバーでホストされている ASP.NET Core アプリがあり、データベースは同じサーバーでホストされている MySql です。私は非常に奇妙な行動を経験しています。

下記は用例です。そのため、数字は API への呼び出しを表し、応答時間が発生します。内部アーキテクチャに問題があると思ったので、コントローラーの先頭に日時オブジェクトがあり、最後にタイムスパンを測定します。次のようなものです。

だからここに私が得るものがあります（アプリはサーバー上にあり、高速の100mbpsネットワーク上にあるローカルマシンから呼び出しています）：

デプロイ API アドレス 1 の直後に行われた呼び出し

1) 4.879 秒 2) 262 ミリ秒 3) 10 ミリ秒 4) 14 ミリ秒 5) 7 ミリ秒 6) 7 ミリ秒 7) 8 ミリ秒

API アドレス 2 8) 523ms 9) 16ms 10) 6ms 11) 7ms 12) 5ms

ご覧のとおり、最初の API への最初の呼び出しに最も時間がかかり、その後、時間は最小の 7 ミリ秒に短縮されます。別の API エンドポイントに切り替えると、開始時にほぼ同じ結果が得られますが、少し高速ですが、あとがきの動作はまったく同じですが、約 10 ミリ秒の応答時間で安定します。

誰もこの問題を経験したことがありますか? ユーザーが行う前に最初の呼び出しを行うための可能な回避策を聞きましたが、おそらくタイムアウト後にこの動作が返されると思われますが、これは醜いように聞こえますか? カーテンの後ろで実際に何が起こっているかを確認するにはどうすればよいですか?

この問題に本当に悩まされています。アプリは非常にうまく機能しますが、これは本当に苦痛です。前もって感謝します！これに関する有益な情報を本当に感謝します。

更新だから、Linux マシンのシステム ログを調査したところ、次のような結果が得られました。