はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事について Azure App Serviceの全体アーキテクチャについてはかなり昔に書かれたこのドキュメントが参考になります(今とはいろいろ違っていますが、基本は同じです)が、このドキュメントには実行時環境(ランタイム)についてはあまり触れられていません。ずいぶん昔に私が日本で登壇して話したことがあるものの、公式ドキュメントにはあまり説明がないんですよね。そのせいか、ときどきサポートリクエストにランタイムに関する質問が（なぜか日本からが多いらしい）来ているようです。ランタイムの挙動について網羅しようとすると本が一冊書けるくらいに

上記の通り、HttpClientオブジェクトは一度作成するだけでそれをずっと使い続けるのが正しい使用法です。知ってる人には当然なんですけども、知らないと結構驚くかも知れません。APIドキュメントにはこう書いてあります。 HttpClientは、1回インスタンス化し、アプリケーションの有効期間全体に再利用することを目的としています。 すべての要求に対して HttpClient クラスをインスタンス化すると、大量の読み込みで使用可能なソケットの数が枯渇します。 これにより、SocketException エラーが発生します。 間違った使い方をしていても普段はあまり問題は起きませんが、高負荷時に突然ダウンすることが起こりえます。 Azure App Service で問題になりやすい理由 間違った実装のアプリをAzure App Serviceで運用している場合、特に問題になりやすいです。どうし

App Serviceを使っていて何か問題が起きたとき、どうやって調査していますか？アプリケーションログを見る、App Insightsを使う、Failed Request Tracing (FREB) logを見る、Kuduを使うなどが主な方法だと思います。本稿では、これらの各種ログを自動で一括して走査し、原因を推定するシステム App Service Diagnostics を紹介します。 背景 もともとは我々開発チームが自分たちでの問題調査用に作ったツールだったのですが、App Service のサポートチームでもそのようなツールが切望されていたことが分かり、サポートチームからのフィードバックを受けながら改善していきました。今ではサポートチームが調査の始めに使うツールとして定着しています。これをさらに発展させ、ユーザ自身にも使ってもらえるようにポータル上にユーザインタフェースを作った

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

コード内で別プロセスを起動する際にはProcessクラスを使いますが、出力をリダイレクトする場合は正しく初期化しないとWaitForExit()がいつまで待っても返って来ません。 リダイレクションのための内部バッファは4Kバイトしかありません。もし呼び出したプロセスが4KB以上出力した場合、その出力が取り出されるまでプロセスが停止するためです。UNIXのパイプの扱いと同じですね。この問題を避ける一番簡単な方法は、簡単なイベントハンドラを用意して適宜データを吸い出してやることです。 以下にpowershellを内部から呼び出すサンプルを書きます。 var command = "powershell.exe"; var arguments = "gci $ENV:TEMP"; var startInfo = new ProcessStartInfo(command, arguments) {