HttpClientをusingで囲わないでください - Qiita
using (var client = new HttpClient()) { var response = await client.GetAsync(url); .... } これは間違いです。HttpClientオブジェクトは dispose してはいけません！ Stackoverflowにも沢山この間違いがあります。 (追記: 正確に言うとdisposeしてはいけないわけではなく、生成と破壊を繰り返すのが誤りです) 正しい使い方はAPIの公式ドキュメントに書いてある通りです。 public class GoodController : ApiController { private static readonly HttpClient HttpClient; static GoodController() { HttpClient = new HttpClient(); } } 上
App Service Plan を理解するためのキーポイント - Qiita
App Service を正しく使うために App Service を本番環境で正しく使うためには App Service Plan の正しい理解が欠かせません。しかし「App Service Planとはマシンのスペックのようなもの」というざっくりした説明が多いためか、細かい挙動が理解されなかったりトラブルの原因になっているケースをよく見ます。なのでここでキーポイントを書いておこうと思います。 ※ Functions の Consumption Plan (従量課金) にはここでは触れません。 App Service Plan == アプリを入れる箱？ 新しく Web アプリを作るときには必ず App Service Plan を選択するか、新たに作成する必要があります。これは、Azure にどのようなスペックのハードウェアを使いたいかを指定するためです。はい、ざっくりした説明ですね。こ
App Service の実行時環境についてのFAQのごく一部を書きます - Qiita
この記事について Azure App Serviceの全体アーキテクチャについてはかなり昔に書かれたこのドキュメントが参考になります(今とはいろいろ違っていますが、基本は同じです)が、このドキュメントには実行時環境(ランタイム)についてはあまり触れられていません。ずいぶん昔に私が日本で登壇して話したことがあるものの、公式ドキュメントにはあまり説明がないんですよね。そのせいか、ときどきサポートリクエストにランタイムに関する質問が（なぜか日本からが多いらしい）来ているようです。ランタイムの挙動について網羅しようとすると本が一冊書けるくらいになってしまうので、ここでは数点だけに絞って書いておきます。 参考ドキュメント 次節以降の説明は、このドキュメントを見ながら読むと理解が進むと思います。 https://docs.microsoft.com/en-us/archive/msdn-magazin
App Service Diagnostics で障害調査を楽にする - Qiita
App Serviceを使っていて何か問題が起きたとき、どうやって調査していますか？アプリケーションログを見る、App Insightsを使う、Failed Request Tracing (FREB) logを見る、Kuduを使うなどが主な方法だと思います。本稿では、これらの各種ログを自動で一括して走査し、原因を推定するシステム App Service Diagnostics を紹介します。 背景 もともとは我々開発チームが自分たちでの問題調査用に作ったツールだったのですが、App Service のサポートチームでもそのようなツールが切望されていたことが分かり、サポートチームからのフィードバックを受けながら改善していきました。今ではサポートチームが調査の始めに使うツールとして定着しています。これをさらに発展させ、ユーザ自身にも使ってもらえるようにポータル上にユーザインタフェースを作った
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
