製品を開発するとき、彼らはその性能に十分な注意を払うことはめったにありません。 ほとんど、またはまったくこれをしません-十分な時間、専門家、または彼らは典型的なフレーズで自分自身を正当化しません：「すべてが製品で私たちと一緒にすぐに機能するので、なぜ他のものをチェックしますか？」 そのような場合、例えばハブラ効果の下で、来場者の急増のために、うまく機能している作品が突然落ちる瞬間が来るかもしれません。 そして、生産性に関する研究を行うことが本当に必要であることが明らかになります。
このタスクには多くの人が困惑しています。なぜなら、何をどのように測定し、どのように結果を解釈するかについての明確な理解がなく、非機能的な要件が形成されていない場合があるからです。 次に、このルートに進む場合の開始点について説明し、パフォーマンス調査で重要な指標とその使用方法について説明します。
理論のビット
球状のアプリケーションが真空状態にあると想像してください-要求を受け取り、それらに答えを返します。 簡単にするために、どこにも行かず、他のコンポーネントやアプリケーションに依存しない1つのメソッドを持つマイクロサービスにすることができます。 この場合、私たちはそれが何に書かれているのか、どのように機能するのか、どの環境で起動されるのかにはあまり関心がありません。
一般的なパフォーマンスについて何を知りたいですか？ サービスが安定している着信要求の最大フロー、このフローでのパフォーマンス、および1つの要求を完了するのにかかる時間を知ることは、おそらく有益です。 生産性のさらなる成長を制限する理由を特定できれば、非常に便利です。
明らかに、リクエストへの応答時間を、それぞれ着信リクエストのフローまたは強度によって測定する必要があります。これは、単位時間あたりのリクエスト数（通常は1秒あたり）と生産性（同じ時間単位へのレスポンス数）を意味します。 応答時間は広範囲に分散する可能性があるため、初心者には1秒あたりの平均として表示するのが理にかなっています。
さらに、さまざまなレベルで問題が発生する可能性があります。サービスがエラーで応答するという事実から始まり（「200 OK {"status"： "error"}」ではなく、500である場合は問題ありません）。ネットワークレベルで応答がまったく停止するか、応答が失われます。 失敗したリクエストはキャッチできる必要があり、それらを合計のパーセンテージとして提示すると便利です。 パフォーマンス、応答時間、エラー率と強度のグラフは次のようなものです。
クエリの強度が増加すると、応答時間とエラー率が増加します
生産性は集中的に直線的に増加していますが、サービスは正常に機能しています。 着信要求ストリーム全体が正常に処理され、応答時間が変更されず、エラーも発生しません。 強度の増加を続けると、生産性が最大に達し、応答時間が伸び始める飽和の時間まで、生産性の伸びが鈍化します。 その後の強度の増加は混乱につながります-応答時間の大幅な増加と生産性の低下、エラーの積極的な成長が始まります。 成長と飽和の段階では、2つの重要なポイント- 通常の パフォーマンスと最大のパフォーマンスがあります。
通常および最大パフォーマンスの位置
通常の生産性は、成長率が低下し始めた瞬間に達成され、成長率がゼロになった瞬間に最大になります。 通常のパフォーマンスと最大のパフォーマンスを分離することは非常に重要です。 通常のパフォーマンスに対応する強度では、アプリケーションは安定して動作するはずです。 通常のパフォーマンスの値は、サービスのボトルネックが発生し始めるしきい値を特徴づけ、その動作に悪影響を及ぼします。 生産性が最大に達すると、ボトルネックがさらなる成長を完全に制限し始め、サービスは不安定になり、原則として、この時点でエラーの小さいが安定した背景が現れ始めます。
この問題はさまざまな理由で発生する可能性があります-キューが詰まっている、十分なスレッドがない、プールが使い果たされている、CPUまたはRAMが完全に使用されている、ディスクからの読み取り/書き込み速度が不十分など 1つのボトルネックを修正すると、次のボトルネックなどによってパフォーマンスが制限されることを理解することが重要です。 ボトルネックを完全に取り除くことは不可能であり、移動することしかできません。
実験
まず、サービスが通常および最大のパフォーマンスに達する強度の大きさ、および対応する平均応答時間を決定する必要があります。 これを行うには、実験で、着信要求のフローを単純に増やすだけで十分です。 最大強度の値と実験の時間を決定することはより困難です。
非機能要件（存在する場合）に記述されているものから、販売からの最大ユーザー負荷から、または単純に上限から値を取得できます。 着信ストリームの強度が十分でない場合、サービスは飽和状態に達する時間がなく、実験を繰り返す必要があります。 強度が高すぎる場合、サービスはすぐに飽和状態に達し、その後デバッグされます。 このような場合、エラーの数が大幅に増加しても、無駄に時間を浪費して実験を停止しないように、監視するのが便利です。
実験では、10分間、1秒あたりの要求数を0から1000に徐々に増やします。 サービスが飽和状態に達するにはこれで十分です。必要に応じて、次の実験で時間と強度を調整して、より正確な結果を取得します。 上記のグラフでは、すべてがスムーズで美しいものでしたが、現実の世界では、通常のパフォーマンスの価値を判断することは一見困難な場合があります。
サービスパフォーマンスの時間依存の真の依存性
この場合、通常のパフォーマンスの最大値の80〜90％を使用します。 飽和に達した後にエラーの活発な成長を観察する場合、それらはボトルネックの結果であるため、調査することは理にかなっています。エラーを調査することは、ローカライズし、修正のために渡すのに役立ちます。
したがって、最初の結果が取得されます。 これで、通常および最大のアプリケーションパフォーマンスと、それらに対応する応答時間がわかりました。 それだけですか？ もちろん違います！ 通常のパフォーマンスでは、サービスは安定して動作するはずです。つまり、通常の負荷でしばらく動作を確認する必要があります。 どっち？ 再び非機能要件を調べたり、アナリストに尋ねたり、製品の最大活動期間を監視したりできます。 この実験では、負荷を0から通常まで直線的に増加させ、10〜15分間負荷をかけます。 最大ユーザー負荷が通常よりも大幅に少ない場合はこれで十分ですが、匹敵する場合は、実験時間を増やす必要があります。
実験の結果をすばやく評価するには、取得したデータを次のメトリックの形式で集計すると便利です。
- 平均応答時間
- 中央値
- 90％パーセンタイル
- エラー率
- パフォーマンス。
平均応答時間は理解できますが、平均はサンプルの正規分布の場合にのみ適切な尺度です。これは、「外れ値」に敏感すぎるためです。一般的な傾向から大きく外れた大きすぎるまたは小さすぎる値です。 中央値は応答時間のサンプル全体の中央で、値の半分はそれより小さく、残りは大きくなります。 なぜ必要なのですか？
まず、その定義に基づいて、外れ値に対する感度が低くなります。つまり、より適切なメトリックです。次に、平均と比較することにより、応答の分布をすばやく評価できます。 理想的な状況では、それらは等しくなります-応答時間の分布は正常であり、サービスは正常です！
応答時間の正規分布。 この分布では、平均と中央値は同等です
平均が中央値と大きく異なる場合、分布は歪んでおり、実験中に「外れ値」が存在する可能性があります。 平均が大きい場合-サービスの応答が非常に遅い、つまり、速度が低下する期間がありました。
長い回答の「外れ値」による応答時間の分布。 この分布では、平均は中央値よりも大きくなります。
そのような場合は、追加の分析が必要です。 「排出」の規模を推定するために、分位またはパーセンタイルが助けになります。
取得したサンプルのコンテキストでの変位値は、すべての要求の対応する部分が適合する応答時間の値です。 クエリの％を使用する場合、これはパーセンタイルです（ところで、中央値は50％パーセンタイルです）。 90％パーセンタイルを使用して排出量を推定すると便利です。 たとえば、実験の結果として、中央値100ミリ秒が得られ、平均-250ミリ秒は中央値を2.5倍超えています！ 明らかに、これは完全に良いわけではありません。90％の変位値を見て、1000ミリ秒です。成功したリクエストの10％が1秒以上で完了しました。理解する必要があります。 長いクエリを検索するには、実験結果でファイルを噛むか、すぐにサービスログで噛むことができますが、時間とグラフの形式で平均応答時間を提示する方がより良いです。
まとめ
したがって、実験を正常に実行し、結果を得ました。 良いか悪いかに関係なく、それはサービスの要件に依存しますが、得られる数値ははるかに重要ではありませんが、これらの数値がなぜ重要であり、さらに成長が制限されるものを理解します。 ボトルネックを見つけることができれば-非常に良い、そうでなければ、遅かれ早かれ生産性の必要性が増加する可能性があり、それを探す必要があるので、状況を未然に防ぐのが簡単な場合があります。
このノートでは、最初に行った質問に答えることで、パフォーマンスを調査するための基本的なアプローチを示しました。 パフォーマンスを研究することを恐れないでください、それは必要です！
PS
居心地の良いテレグラムチャットルームにアクセスして、質問したり、アドバイスを求めたり、パフォーマンス調査について話し合ったりできます。