🤧 🚅 🍈 アプリケーションパフォーマンス分析実践ガイド 🛒 🐠 👴🏼

おそらく、会議の数か月後にすべてのレポートのビデオを投稿することを既にご存じでしょう。 Sasha Goldshtn Goldshteinの基調講演の場合のように、ビデオ形式が気に入らない人でも参加できるように、最高の成績証明書を作成しています。

Sashaは、自分で開発したものを含め、アプリケーションのパフォーマンスを分析するための方法とツールについて語っています。

この記事は、DotNext 2017 Piterカンファレンスでのサーシャのスピーチに基づいています。 Sashaは、イスラエルのトレーニングおよびコンサルティング会社Selaのテクニカルディレクターとして働いており、パフォーマンス分析の実施方法を直接知っています。終了するよりも良い方法、どのツールを使用するべきか、どのツールを避けるべきか、カットの下で読んでください。

パフォーマンス分析：段階的な計画

パフォーマンス分析フレームワークから始めましょう。次の計画は、開発者、システム管理者、技術専門家によって使用されます。

問題の説明を取得します。これは実際よりも簡単に聞こえます。なぜなら、多くの場合、顧客は問題を非常に不十分にしか説明しないからです。
システム図の作成。これにより、問題がどの部分で構成されているかを認識できます。
クイックパフォーマンスチェック。これにより、システムで何が機能しているか、何が過負荷になっているかなどを理解できます。
問題の原因となっているコンポーネントを理解する。この段階では、問題が何であるかはまだわかりませんが、それがどこにあるかはすでにわかっているので、すでに進歩しています。
詳細な分析。この段階では、最も時間がかかります。
問題の根本を見つける。
問題を修正します。
検証この段階で、問題が修正され、システムが正常に機能しているかどうかを確認する必要があります。
分析プロセス全体の文書化。これは、あなたが何をしたか、どのツールがあなたにとってうまくいったか、そしてどれがうまくいかなかったかを正確に知るために必要です。これにより、将来同じ間違いを繰り返さないようにすることができます。

問題の説明：なぜそれを入手するのがそんなに難しいのですか？

クライアントから問題の正確な説明を取得することは、一見思われるよりもはるかに困難です。

クライアントは次のような問題に対処できます。

「アプリケーションの動作が遅すぎる。 ユーザーはこれがいつ起こるかを正確に言うことはできませんが、それは悪いことです。 見えますか？」

または

「生産性を向上させるための作業予算があります。作業環境を見て、2日間問題を見つけることができますか？」

もちろん、試すことはできますが、割り当てられた予算を非常に有効に使用することはほとんどありません。より正確に定式化された問題は、次のようになります。

「午前4時25分から、95％のケースでASP.NETサイトにアクセスすると、1400ミリ秒の遅延が見られます（通常の応答時間は60ミリ秒です）。 遅延は地理的な場所に関係なく観察され、軽減されません。 自動スケーリングを有効にしましたが、それは役に立ちませんでした。」

このような問題の説明は、症状を見て、どこを見るべきかを理解し、問題の解決策と考えられるもの（遅延を60ミリ秒に短縮）を理解しているため、すでにはるかに正確です。

クライアントに必要なものを正確に見つけることは、一見思われるよりもはるかに難しい場合があります。

各企業には独自のパフォーマンス要件がありますが、残念ながら常に策定されているわけではありません。たとえば、次のようになります。

すべてのフルテキストリクエストの90％は、200ミリ秒以内に完了する必要があります。
全文リクエストの99％は600ミリ秒以内に完了する必要があります。
すべてのフルテキストクエリの100％は、2000ミリ秒以内に完了する必要があります。

そのような要件が存在する場合、システムがそれらのコンプライアンスをテストし、問題を解決する方法を理解するだけです。ただし、要件はどこからでも来るものではなく、常にビジネス目標と一致している必要があることを理解することが重要です。要件が明確に定義されているため、APMソリューションまたはその他の方法でいつでも統計を追跡し、何か問題が発生した場合に通知を受け取ることができます。

アンチパターン：分析が必要ない方法

結果を生成する分析メソッドに飛び込む前に、問題をどのように分析すべきでないかについて少しお話したいと思います。したがって、絶対にすべきではありません：

仮定を立てます。
「本能」と不条理な信念を信頼する。
見つけやすい場所でのみ問題の解決策を探してください（この動作は「街灯効果」とも呼ばれます。彼は、紛失した場所ではなく、明るい場所で鍵を探した有名なジョークの酔っぱらいによって示されました）。
ランダムツールを使用します。
責任をツールに移します。

完了しなかった分析の失敗例を1つ挙げます。私の仕事は、プロジェクト管理システムでドキュメントを保存およびロードするときに、クライアントが大幅な遅延に遭遇することがある理由を理解することでした。システムは、ローカルネットワーク上のSMBを介してNetAppに接続されました。私のタスクは、データウェアハウスを操作するときに発生する可能性のあるネットワークレイテンシとレイテンシを見つけることでした。

WCFとアプリケーションサーバーのパフォーマンスを監視するツールがあり、ネットワークトラフィックのスニファーがありましたが、NetAppストレージシステムにアクセスできませんでした。一連のテストの後、平均応答速度は11ミリ秒であることがわかりましたが、24時間以内に1200ミリ秒の遅延が発生する場合がありました。 NetAppで何が起こっているのかについて十分な情報を持っていなかったため、パフォーマンステストデータを取得する必要がありました。

クライアントから、ストレージシステムの応答速度が5ミリ秒未満にならないという情報のみを取得することができました。この図が何であるかについての私の質問に：平均またはピーク遅延、私は答えを得ました： これは60秒間の最大平均値です。 私はまだこの価値が何であるかを知りません、そしてあなたもあなたも知らないのだと信じています。彼は毎秒平均値をとってからすべての平均から最大値をとるか、あるいは毎秒最大値をとってから最大値をとって...

その後、このストレージシステムで有効と見なされるNetAppパフォーマンスカウンターのドキュメントを見つけました。これは、毎分ではなく、毎秒の平均データです。クライアントにこのデータを提供するように依頼しましたが、拒否されました。分析を実行するこの試みは終了しました。

私にとって、これはパフォーマンス分析を実行できない典型的なケースです。できるだけ多くの情報を取得するように最善を尽くし、仮定に頼らなかったが、クライアントとの理解不足のため成功しなかった。そして、これは仮定と不条理な信念に頼ることができない理由の良い例です。

次に、ツールの使用の失敗について。

専門家は、高価なツールを購入した場合、すべての分析オプションに使用する必要があると考える場合があります。分析に間違ったツールを使用する典型的な例を挙げます。

CPUフェッチモードでVisual Studioプロファイリングツールを実行して、検索ロボットのパフォーマンスをテストします。ロボットは、プロセッサをロードしないいくつかのことを実行できます。このようなテストを実施すると、次のような結果が得られます。

このメソッドはアプリケーションの速度を低下させるため、System.Console.WriteLineのパフォーマンスを改善する必要があることになります。ただし、検索ロボットは単にネットワークデータの到着を待つことができ、これはプロセッサに接続されていません。したがって、「購入したからといって、その価値を取り戻す必要がある」という原則に基づいて分析用のツールを選択することはできません。

問題の原因を見つける：USEメソッド

何を探すべきかわからないこともあります。その場合、世界中のエンジニアがよく使用する方法論を提案します。これはUSE（Utilization、Saturation、Errors）メソッドであり、いくつかの段階で機能します。

最初に、すべてのハードウェアおよびソフトウェアリソースとそれらの間の接続を含むシステムの図を作成する必要があります。
次に、各リソースおよび各接続について、3つのパラメーターを定義する必要があります。使用率-使用（ロードされるリソースの量）、飽和-飽和（このリソースを使用するためのキューがあります）およびエラー-エラーが発生した場合。
問題がパラメーターに関連付けられている場合は、解決する必要があります。

ハードウェアおよびソフトウェアリソースのUSEメソッドは次のようになります。

全体像を把握するために、各コンポーネントを体系的にテストするためのチェックリストを用意する必要があります。

Windowsシステムのチェックリストは次のようになります。

成分	種類	分析ツールまたは追跡パラメータ
CPU	読み込み中	プロセッサ（_Total）\％ProcessorTime、％User Time Process（My App）\％ProcessorTime
CPU	彩度	システム\プロセッサキューの長さ
CPU	間違い	Intelプロセッサ診断ツール（およびその他）
記憶	読み込み中	メモリ\利用可能なMバイトプロセス\仮想サイズ、プライベートバイト、ワーキングセット .NET CLRメモリ\すべてのヒープ内のバイト数 VMMap、RAMMap
記憶	彩度	メモリ\ページ/秒
記憶	間違い	Windowsメモリ診断ユーティリティ（およびその他）
ネットワーク	読み込み中	ネットワークインターフェイス\受信バイト数/秒、送信バイト数/秒
ネットワーク	彩度	ネットワークインターフェイス\出力キューの長さ、送信パケットの破棄、受信パケットの破棄
ネットワーク	間違い	ネットワークインターフェイス\パケットアウトバウンドエラー、パケット受信エラー
運転	読み込み中	物理ディスク\％ディスク時間、％アイドル時間、ディスクレッド/秒、ディスク書き込み/秒
運転	彩度	物理ディスク\現在のディスクキューの長さ
運転	間違い	Chkdisk（およびその他のツール）
アプリ	間違い	.NET CLR例外\スローされた例外の数/秒 ASP.Net \エラーイベントが発生しました

このデータのほとんどは、組み込みのWindowsパフォーマンスカウンターを使用して取得できます。このテストは非常に迅速に実行できますが、時間を大幅に節約し、見つかった問題の分析に集中できます。

このプロセスを自動化するには、さまざまなソリューションを使用できます。

Windowsシステムモニター（Perfmon）-パフォーマンスカウンターのログを常に収集できるか、特定の条件が満たされた場合のみ収集できます。
Typeperf-ユーザーが指定したパフォーマンスカウンターの値を使用してCSVファイルを毎秒生成する方法を知っています。
サードパーティのソリューション。たとえば、クラウドソリューションを使用している場合は、プロバイダーがツールへのアクセスを提供して、プロセッサ、ディスク、ネットワークアクティビティなどのアクティビティを監視する必要があります。

パフォーマンス分析：使用するツール

パフォーマンス分析ツールは、次の3つのカテゴリに分類できます。

これが発生する頻度を判断するのに役立つもの（カウント）。たとえば、1秒あたりのリクエスト数

どれだけ時間がかかるかを判断するのに役立つもの（タイムアウト）。たとえば、ASP.NETリクエストにかかる時間、ウィンドウ間の切り替えにかかる時間など。

これが起こっている理由を判断するのに役立つもの（スタック）。たとえば、アプリケーションのソースコードで特定の条件が発生した場合

原則として、最初のカテゴリのツールは小さなオーバーヘッドを与えますが、待機時間を決定するためにツールを使用する場合、それは長くなり、3番目のカテゴリの資金は大きなオーバーヘッドにつながります。後者はより多くの情報を提供するため、これは驚くことではありません。

ツールを選択するときは、次の5つの点に注意することが重要です。

小さなオーバーヘッド
精度（結果をどれだけ信頼できるか）
迅速な結果（データを分析するのに何時間も待つ必要がない場合）
侵略性（実行中のシステムで実行する機能）
特定の領域（クラス、機能など）に焦点を合わせる能力

オーバーヘッドを覚えておいてください！

観察はシステムの状態に影響を与える可能性がありますが、一部のツールは他のツールよりも強力です。したがって、ツールを使用する前に、ドキュメントを参照することをお勧めします。原則として、ツールの使用から期待できることを示します（たとえば、特定の状況でプロセッサの負荷が5〜10％増加するなど）。

使用するツールのドキュメントでオーバーヘッドについて何も説明されていない場合は、自分でテストする必要があります。これはテストシステムで実行し、パフォーマンスの低下を測定する必要があります。

正確性：安全な条件の物語

おそらくJavaで作業していない人にとってはこれはニュースになりますが、開発者が使用するJava Javaプロファイラーのほとんどは不正確なデータ（VisualVM、jstack、YourKit、JProfilerなど）を生成します。文書化されたJVMTI APIであるGetAllStackTracesを使用します。 GetAllStackTraces関数を呼び出すと、システム内の各スレッドが実行するサンプルが生成されます。

その使用の利点はクロスプラットフォームですが、重大な欠点があります。すべてのスレッドが安全な状態にある場合にのみ、スレッドサンプルを取得します。つまり、スタックトレースを要求した場合、現在の瞬間からではなく、スレッドがスタックトレースの転送を決定した時点から取得します。その結果、実際の状況とは関係のない結果が得られます。

以下のスクリーンショットでは、Javaプロファイラーの精度に関する科学レポートのデータを見ることができます。

グラフでは、特定のベンチマークのどのメソッドが「最もホット」であったかについて、4つのプロファイラーのデータを見ることができます。 4つのプロファイラーのうち2つ（左と右）がjj_scan_tokenメソッドであると判断し、3つ目のプロファイラーがgetPositionFromParentメソッドであると判断し、4つ目がDefaultNameStep.evaluateであると判断しました。つまり、4つのプロファイラーは、まったく異なる測定値とまったく異なる方法を提供しました。そして、ここではプロファイラーではなく、ターゲットプロセスから結果を取得するために使用するAPIです。

そのため、新しいツールを使用している場合は、さまざまな条件（プロセッサがアクティブに動作しているとき、静止しているとき、またはディスクからデータを読み取っているとき）で必ずテストする必要があります。また、プロファイラーが正しいデータを提供していることを確認してから、オーバーヘッドを確認する必要があります。データが正しくない場合、このプロファイラーはもちろん使用しないでください。

結果：どれくらい早く入手できますか？

ここでは、Linuxで.NET Coreをプロファイリングする手順の例を示します。

詳細に検討するのではなく、いくつかのポイントのみを取り上げます。まず、環境変数を構成する必要があります。環境変数を使用すると、たとえば問題が発生します。さて、あなたはそれをやったとしましょう。これらのすべての手順の結果として生成されたZIPファイルを取得して、Windowsマシンにコピーし、PerfViewを使用して開く必要があるため、指示は終了します。そして、そうして初めてデータを分析できます。ばかげているね。 Linuxで分析を実行してから、Windowsで分析を開きます...

同じ問題の代替ソリューションを次に示します。これらのスクリプトはあまりうまく機能しませんが、少なくともLinuxで結果を取得する機能を提供します。

$ ./dotnet-mapgen.py generate 4118

$ ./dotnet-mapgen.py merge 4118

＃perf record -p 4118 -F 97 -g

＃perfスクリプト| ./stackcollapse-perf.pl>スタック

$ ./flamegraph.pl stacks> stacks.svg

その結果、フレームグラフと呼ばれる視覚化が得られます。 Windowsおよび.NETの多くの開発者はまだこれに慣れていないため、これについて詳しく説明します。

この方法を使用すると、たとえば、プロセッサの負荷が高いときにアプリケーションがディスクにアクセスする場合など、さまざまなスタックトレースを視覚化できます。多くの異なるスタックがある場合、フレームグラフは多くのテキストを読む代わりにそれらを視覚化するための良い方法です。フレームグラフは、数千のスタックトレースページを1つのインタラクティブなグラフに変換します。

チャート内の各長方形は関数です。色はランダムに選択されるため、無視できます。 Y軸はスタックの深さです。つまり、ある関数が別の関数を呼び出した場合、その関数はその上に配置され、グラフは上に表示されます。 X軸は（時間ではなく）スタックをソートします。このようなスケジュールを設定すると、関心のある領域を正確に拡大することが非常に簡単になります。

侵略性：害を与えない方法

侵入型プロファイラーは重すぎるため、システムのパフォーマンス、信頼性、応答性に悪影響を与える可能性があります。たとえば、インストルメンテーションモードおよびIntelliTraceでVisual Studioプロファイラーを使用すると、アプリケーションは再コンパイルされ、追加のマーカーで起動されます。このようなツールは、実稼働環境では使用できません。

別の例はCLRプロファイリングAPIで、これは一部のツールでまだ使用されています。これは、ターゲットプロセスでのDLLの実装に基づいています。これは開発中に許容される場合がありますが、実稼働環境では、実行中のプロセスにライブラリを導入することが問題になる場合があります。

Linuxの極端な例は、LinuxトレースフレームワークSystemTap、LTTng、およびSysDigであり、システムにカスタムカーネルモジュールをインストールする必要があります。はい、これらの人を信頼できますが、パフォーマンス測定ツールを実行するためにカーネルに何か新しいものをロードする必要があることはまだ少し疑わしいです。

幸いなことに、Windowsには、聞いたことがあるかもしれないかなり軽量のイベントトレース（Windows）トレースフレームワークがあります。このフレームワークを使用すると、プロセッサのプロファイル、ガベージコレクションの場所、アプリケーションがアクセスするファイル、ディスクへのアクセス場所などを決定できます。

しかし、ETWはあまり侵襲的ではないという事実にもかかわらず、ETWから結果を取得する速度が問題になる場合があります。以下に、PerfViewを使用して生成されたログファイルの例を示します。

ご覧のとおり、プロセッサの使用状況に関する情報を10秒間収集し、合計15 MBのデータが取得されました。したがって、イベントトレースを使用してシステムを数時間テストできるとは考えられません。データ量が多すぎます。さらに、CLR Rundownを完了するのに12.7秒かかり、その後データを変換して開くのに時間がかかりました（時間を赤で強調表示しました）。つまり、10秒以内にデータを収集するには、30分間かけてデータを処理して開く必要があります。

これはかなり良い結果と考えられているという事実にもかかわらず、私はそれがあまり好きではありません。したがって、私が自分で書いたツールについてお話したいと思います。

Etrace（https://github.com/goldshtn/etrace）は、ETWのオープンソースコマンドラインインターフェイスです。あなたは彼にあなたが見たいイベントを伝えることができ、彼はそれらについての情報をリアルタイムで提供します。イベントが発生するとすぐに、コマンドラインで確認できます。

> etrace --help

...

例：

etrace --clr GC --event GC / AllocationTick

etrace-カーネルプロセス、スレッド、FileIO、FileIOInit --eventファイル/作成

etrace --file trace.etl --stats

etrace --clr GC --event GC / Start --field PID、TID、理由[12]、タイプ

etrace --kernelプロセス--eventプロセス/ start --where ImageFileName = myapp

etrace --clr GC --event GC / Start --duration 60

etrace-その他のMicrosoft-Windows-Win32k --event QueuePostMessage

etrace --list CLR、カーネル

たとえば、etraceを開始して、「GCイベントが欲しい」と言います。そのようなイベントが発生するとすぐに、そのタイプ、理由、プロセスなどを確認したいと思います。

私が自分で書いて紹介したい別のツールは、 LiveStacksです。また、ETWに関連しています。 LiveStacksは、興味深いイベントのスタックトレースを収集します（ガベージコレクション、プロセッサの負荷、アプリケーションがアクセスするファイル、ディスクにアクセスする場所など）。 LiveStacksと他の同様のツールの主な違いは、リアルタイムでの情報の出力です。どのプロセスが実行されているかを知るために、データ処理が完了するまで待つ必要はありません。

デフォルトのプロセッサプロファイリングモードの例を次に示します。 LiveStacksはVisual Studioでプロセスを確認し、プロセス内のコールスタックを表示します。これは、CPU時間を最も消費します。

別の例：「 ガベージコレクションの開始場所、特定のプロセスまたはシステム全体でガベージコレクションにつながったコールスタックを表示 」クエリで、LiveStacksはリアルタイムでガベージコレクションが行われる場所に関する情報をコールスタックに提供します。

結果から、LiveStacksは、コンソールに表示された呼び出しスタックを視覚化することにより、フレームグラフを生成できます。

> LiveStacks -P JackCompiler -f> stacks.txt

ˆC

> perl flamegraph.pl stacks.txt> stacks.svg

これらのツールを使用すると、データ処理を待たずに結果をすばやく取得できるためです。

効果的な計装のためのシステムを構築する方法

新しいプロジェクトのシステム、ライブラリ、アーキテクチャを構築するとき、将来のパフォーマンス分析を簡素化するいくつかのことを事前に考慮する必要があります。

興味深いイベント（ディスクアクセス、ガベージコレクションなど）の呼び出しスタックが簡単に取得できることを確認してください。
静的コードインスツルメンテーション（トレースポイント）を実装して、プロセスに関するリアルタイム情報を取得できるようにします。
重要なプロセスは、オーバーヘッドなしで、システムを再起動することなく、単にログレベルで設定することで有効にできることを確認してください。
動的インスツルメンテーションのデバッグポイント（プローブ）を追加します。
パフォーマンス分析を実行する人がシステムの動作を理解するのに余分な時間を費やす必要がないように、例とドキュメントファイルを作成します。

非常に優れたインスツルメンテーションを備えたサンプルプロジェクトは、Windows上の.NETであり、10年以上にわたって多くの人々に使用されています。上で話したETWイベントがあります。興味深いイベントの呼び出しスタックをキャプチャし、それらを関数名に変換する機会があります。そして、これらはすべてデフォルトで含まれています！

このような計測ツールを使用してプロジェクトを作成することは簡単ではありません。たとえば、Linux用の.NET Core 2.0を見ると、すべてがそれほどバラ色ではありません。 Linuxにはパフォーマンスを分析するための優れたツールがないためではなく、プロファイルとデバッグが簡単なプラットフォームを構築するのはかなり難しいためです。

Linux用の.NET Core 1.0の何が問題なのか知りたいですか？プラットフォームにはイベントがありますが、コールスタックを取得することはできません。イベントが発生したことしかわかりません（情報量が少ない）。別の例：呼び出しスタックを変換して関数名を取得するには、多くの準備手順を実行する必要があります。そのため、ドキュメントでは、ZIPファイルをWindowsで開くことを推奨しています（この例を上記に示しました）。

優先事項がすべてです。パフォーマンス分析を実行する能力が開発中のシステムにとって重要な要件であると考える場合、このようなものをリリースすることはありません。もちろん、これは私の見解です。

統計に注意してください！

統計とツールはしばしば私たちを欺きます。この点で留意すべき点がいくつかあります。

平均値は無意味です。
中央値は無意味です。
パーセンタイルと分布は、何をしているかを正確に知っている場合にのみ役立ちます。
データに適切な視覚化を使用します。
協調的な脱落の現象に注意してください。

たとえば、誰かが「平均システム応答時間は29ミリ秒だ」と言います。これはどういう意味ですか？たとえば、平均応答時間が29ミリ秒の場合、最悪の値は50ミリ秒または60ミリ秒であり、最高はゼロに近いという事実です。または、ほとんどの場合、応答時間は10ミリ秒ですが、システムの動作が非常に遅くなるモード（応答時間は最大250ミリ秒）があり、平均値も29ミリ秒です。

平均応答時間が同じであるこれら2つのケースを示す2つのグラフは、まったく異なることがわかります。何が起こっているのかを実際に把握するには、数字を見るだけでは不十分で、実際の分布を調べる必要があります。

ウェブで見つけた素晴らしい研究があります。要約統計のみを信頼できない理由を示しており、常にデータを視覚化する必要があります。

著者は、同じ要約統計量（同じ平均x / y、1つの標準偏差x / y、同じ相互相関）で13のデータセットを視覚化しました。ただし、これらのデータセットはまったく異なって見えます。つまり、数字だけを見ると、何の意味もありません。数字だけを見ると、データの「フォーム」は見えません。

BenchmarkDotNetは、多くの人が使用するライブラリです。それは単に豪華ですが、データの「形状」を表示しません（少なくともデフォルトでは）。コンソールで実行すると、データの「フォーム」ではなく、平均、標準偏差、信頼区間、四分位数などの多数の数値が出力されます。これは非常に重要です。一部のタイプの分析では、データの「フォーム」が見えないということは、重要なことを見逃すことを意味します。

平均に依存することでスキップできるものの例を次に示します。このグラフは遅延時間を示しています。 99％のケースでは、応答時間は200ミリ秒よりもわずかに短いですが、周期的なst音が観察される可能性があります-短期間で発生する長すぎる遅延（10ミリ秒まで）です。

また、ほとんどの場合、パフォーマンス分析を実行する際に、st音に注意を払うよう求められます。これは、ユーザーが時々遭遇する問題である平均値よりも高い値です。それらを識別するには、上のグラフのようにすべてのデータポイントを視覚化するか、下のグラフのように分布を構築する必要があります。

人々がパーセンタイルで犯すもう1つの一般的な間違いは、パーセンタイルで数学的操作を行うことです。たとえば、私のクライアントが行ったようにパーセンタイルを平均化することはできません。

2台のサーバーがあるとします。サーバーAの場合、90％の時間の遅延時間は90ミリ秒であり、サーバーBの90％の時間の遅延時間は22ミリ秒です。

これらの値を平均化できないことを理解することが重要です。要求の90％で、応答が57ミリ秒未満になるのは事実ではありません。実際、リクエストの90％は68ミリ秒よりも速く応答します。

したがって、関心、四分位数などを平均化することはできません。常にデータとその普及を確認する必要があります。

次のような音が聞こえることがあります。私のユーザーは誰もこれを見ません！」Amazon.comのウェブサイトのページを例として使用して、なぜこれが重要なのかを説明します。彼女は328件のリクエストを行いました。すべてのクエリが独立していると仮定すると、そのうちの少なくとも1つが99パーセンタイルにある可能性はどのくらいですか？

P = ^1-0.99 328〜96％

答えは96％です。したがって、Amazon.comページにアクセスすると、99パーセンタイルで少なくとも1つのリクエストを受け取る可能性が非常に高くなります。また、ユーザーが比較的複雑なシステムにアクセスする場合、最悪のシナリオが発生する可能性は非常に高くなります。

大規模システムには本格的なツールを使用してください！

この記事のフレームワークで最後に言及したいのは、多数のマシンで構成されるシステムに特別なツールを使用する必要があるということです。このようなツールでできることは次のとおりです。

多数のマシンからパフォーマンスデータを収集します。
ユーザーアクションをセッションまたはトランザクションIDに関連付けます。
情報パネルでデータを視覚化します。
, , .

. – Vector Netflix. , , , - .

– AMP- New Relic , .NET. , . , .

: !

, , , . ?

, , , .
? ? 何が機能しなかったのですか？
?
?
, ?
, ?
, , , .

— .NET, . DotNext, 12-13 , Debugging and Profiling .NET Core Apps on Linux . Production Performance and Troubleshooting of .NET Applications.

:

Karel Zikmund Microsoft ( High performance Networking in .NET Core )
JetBrains ( performance-)
(Federico Lois) Corvalius ( Patterns for high-performance C#: from algorithm optimization to low-level techniques)

, .

アプリケーションパフォーマンス分析実践ガイド