パフォーマンスをテストする2つのアプローチ。 選ぶ
この記事では、アプリケーションのパフォーマンスをテストするための最も一般的なアプローチについて説明します。 「人生から」の類推と著者の経験からの例を使用して、彼はなぜこれができないのかを示しています。 そして最後に、ストレステストの重要性に対する理解の火花を、開発者、管理者、およびその他の優秀な人々の明るい頭脳に投げ込もうとしています。
いくつかの話から始めましょう。
歴史A.
先日、プログラマーと話していました。 彼はC ++で書いており、シカゴの大企業で働いています。 彼が関係していたソフトウェアは、金融会社や商社で積極的に使用されています。 製品には60万行のコードがあります。 それはすべて、株式統計を分析するための小さなアプリケーションから始まりましたが、今ではそのような怪物は20年間振られています。 いいですね。 尊敬を呼び起こします。 モンスターをどうやってテストしますか？ このために、プログラマーは私に答えます、特別なインド人がいます。 彼はある種のテストケースを実行し、レポートを書きます。 そして、彼の前に、あるマネージャーがこれを行っていましたが、彼はますます手動テストを行いました。 たとえば、新しい機能をチェックしました。 これがヒンズー教徒です。 さて、私はこじ開け続けます、これは機能テストです。 どういうわけかパフォーマンスをテストしていますか？ いいえ、彼が言うには、もし顧客が遅い仕事について不平を言うようになったら、私たち自身がボトルネックを探し、それを自分で修正します。 製品の開発者はそれをよく知っています。 どのテスターがこれを処理できますか？
賢い人だと思った、彼はナンセンスだ。
歴史B.
昨日、Habrahabrに行くと、 「1つの高負荷リソースの開発と最適化の歴史」という記事に出くわします。 読んでいない人のために-著者は、彼が特定のリソースの管理者として働き始めた方法を書きます。 まもなく、このリソースはユーザー数の増加に対応できなくなり、著者である彼は、いくつかのテクノロジーを使用して、サーバーのパフォーマンスを改善し、データベースの負荷を数回削減しました。 「MySQLの負荷は4倍減少しました」というフレーズを読んで、コメントで質問します-あなたの最適化はすべてユーザーの応答時間にどのように影響しましたか？」回答から、作成者はユーザーエクスペリエンスではなく、開いている接続の数とSQLクエリの数に関心があることがわかります。
賢い人、私はもう一度考えましたが、私は彼が何のために何をしているのか完全には理解していません。
これら2つのケースは、最も一般的な負荷テストのアプローチを説明しています。 それらは次のように非常に簡単に説明できます。
A：「パフォーマンスに問題がある場合は、決定します。 自分自身。 特別なテスターは必要ありません。」
B：「...そして、サーバーのCPUがデータベースに対応していないことがわかりました。Googledの「MySQL + CPUの問題」で、すばらしいライブラリを見つけてインストールし、負荷がN倍に減少しました。
アプローチBへの批判から始めましょう（アルファベットの乱用を減らすために「管理者」と呼びましょう）。 そのため、「管理者」アプローチの重要な問題は、パフォーマンスの問題に関する誤った観点です 。
上記のストーリーからわかるように、管理者は管理者の目を通して見ます。 彼にとっての問題の指標は、サーバーの負荷であり、それによって状況の変化をより良く判断するための指標です。リクエスト、接続などの数と速度です。 問題は、特定のサイトで同じ問題を同じように見ている人が世界でさらに何人いるのかということです。 正解はゼロです。 サイトにアクセスするユーザーは、データベース内のインデックスについて心配する必要はありません。 CPUおよびディスクサブシステムのグラフィックス負荷には関心がありません。 彼らが言うことができる最大：「このサイトは遅い」。 そしてもう1つ、「同じものをすばやく探します」 SQLクエリの数に基づいてパフォーマンスを測定する人と「ページが遅くならないように」だけを気にする人の比率は1対Nです。Nはサイトへのすべての訪問者であり、1は非常に賢いが孤独な管理者です。
...管理者にこれをすべて言うと、彼らは通常、「しかし、ユーザーはそれがすべてどのように機能するかわかりません。 そして、私たちは知っています。 そして、ユーザーの意見に基づいて、問題の原因を特定することはほとんど不可能です。」 これに対して、必ず機能する既製の回答があります。 あなたが医者に来たとき、彼はあなたに何を尋ねているのですか？ 幸福について。 圧力と温度は後でのみ測定され、分析の方向はすぐには示されません。 そして、「どこで痛みますか？」または「悪化するのは朝か夕方か？」などの質問から始まります。 質問は単純であり、数学的に正確な答えを出すことは常に可能というわけではありませんが、病気の症状が決定されるのは彼らにあります。 そして、最終的に、患者を最も喜ばせるのは症状の緩和です。 「傷つけないように何か書いてください。」 または、私たちの場合-「ページごとに少なくとも200のリクエストを行いますが、速度を落とさないようにします」。 もちろん、良い医者は、患者の気持ちを説明するだけでは決して診断を下しません。 しかし、同じように、彼は決して彼を過小評価したり、さらに悪いことに彼を無視したりしません。
合計-「管理アプローチ」は、アプリケーションまたはサイトの実際のユーザーの観点からパフォーマンスの問題を考慮しないため、悪いです。 このオプションはおそらくサーバーには適していますが、クライアントには適していません。 ただし、クライアントの数がサーバーの数とほぼ等しい場合...これはあなたのケースではないと思います。
さらに、私の実践では、サーバー負荷チャートとデータベース統計を入力として使用する最適化の結果がほぼゼロになるという状況に繰り返し遭遇しました。
例1 ：Oracle統計の分析により、インデックスを作成するとクエリが2倍速く実行されることが示されました。 インデックスが作成され、クエリは1秒ではなく0.5の実行を開始し、操作の応答時間は35秒から34.5秒に減少しました。
例2 ：特定の操作が最適化され、実行中にサーバーCPUの負荷が30％減少しました。 残念ながら、ユーザーが実行する他のすべての操作のこの操作の割合は0.1％であるため、サーバー負荷の状況に大きな変化はなく、ユーザーは改善に気付きませんでした。
など。 「医師と患者」の例えに戻る：
-患者、あなたは今、正常な体温と血液組成を持っています、あなたは健康です。
「しかし、医者、まだ気分が悪い！..」
次に、Aのアプローチについて説明します。ご想像のとおり、「開発」と呼びます。友人が発言する視点は、開発者にとって非常に典型的なものです。 「私たちとは別に、私たちのアプリケーションを理解できるのは誰ですか？」、「テストは、フォーム上のボタンがクリックされたことを確認するときです」などです。 QAを怠ることは一般に業界の問題の1つですが、このトピックは別の記事に値するものであり、気を散らすことはありません。
「開発」アプローチの主な欠点は何ですか？ 問題は、ユーザーが問題に遭遇した後にのみ認識されます。 つまり、雷が鳴るまで。 悲しいかな、この瞬間にバプテスマを受けるには遅すぎることがしばしばわかります。 システムが動作し始め、何かにパッチを当ててねじ込む必要があることが判明した場合、クライアントは不満を抱きます。 チームリーダーのティムはチベットに向かいました。 文字通りすべてが遅いため、パフォーマンスの低下の原因を特定することは不可能です。 新しいサーバーにお金はかかりません-起こりうる問題のリストは無期限に継続できます。 通常、この状況では、最も才能のある（せいぜい）または最も忙しくない（最悪の）開発者のいくつかが、新年/四半期レポートの次の更新/ピーク負荷まで、外出先でラメシステムをサポートする松葉杖を緊急に作成します。 その後、さらに多くの人々がチベットに移動します。 常に自分自身であるとは限りません。
小さな発言。 原則として、パフォーマンスと負荷テストのコンサルタントとして、「開発」アプローチは通常「管理者」アプローチほど気になりません。 システムが「燃え尽きる」と、プログラマーと管理者の言葉-「すべてが順調です」または「今すぐすべてを修正します」-プロジェクトマネージャーを説得しなくなります。 積荷のために消防士を雇うことを決定しました。そして、出来上がりです-私は新しいクライアントを持っています。 親愛なるプログラマーと管理者-良い仕事を続けてくれて、どうもありがとう。 商業休憩の終わり。
顧客とお金を失いたくない、または履歴書を送る必要に直面したくない人のために、私は贈り物として新しい類推を持っています。 体育館に行って、健康を改善し、悪化を防ぐことができます。 誰もが2番目のオプションを選択するわけではありませんが、それが望ましいことに同意します。 健康と財布の両方のために。
問題を英雄的に戦うよりも回避する方が良いという事実に加えて、友人の言葉である「特別なテスター」という言葉で、力のテストを支持するもう1つの議論があります。 誰もが無意識のうちに、彼がすることはすべて完璧であると考えています。 またはほぼ完璧に。 開発者も例外ではありません。 「すべてがうまくいくことを確信しているなら、テストして、時間を失うだけです。」 ただし、経験から、a）側の人はより創意に富み、間違いを見つけることに成功し、b）QAに時間を費やすことで、将来的に時間とお金の両方を大幅に節約できます。 ソフトウェア開発を除くすべての業界。
そこで、システム管理者の観点から、および開発者の側から、アプリケーションをロードテストする2つのアプローチを検討しました。 どちらも不完全であり、どちらも最も重要な事実を見失っています。アプリケーションが作成され、システムが展開され、サイトが主にユーザー向けに開かれています 。 また、これらのユーザーを事前に管理することをお勧めします。
パフォーマンステストを開始する場所、ストレステストの種類、使用するのに適した方法などについて -これらすべてについて多くのことが書かれており、私は自分の言葉ですべてを語るという仕事を自分自身に設定していません。 代わりに、パフォーマンステストの特定の側面、テスト用のユーティリティのレビューなどについて時々執筆する予定です。 もちろん、このトピックが視聴者にとって興味深いものである場合。 ご清聴ありがとうございました。
いくつかの話から始めましょう。
歴史A.
先日、プログラマーと話していました。 彼はC ++で書いており、シカゴの大企業で働いています。 彼が関係していたソフトウェアは、金融会社や商社で積極的に使用されています。 製品には60万行のコードがあります。 それはすべて、株式統計を分析するための小さなアプリケーションから始まりましたが、今ではそのような怪物は20年間振られています。 いいですね。 尊敬を呼び起こします。 モンスターをどうやってテストしますか？ このために、プログラマーは私に答えます、特別なインド人がいます。 彼はある種のテストケースを実行し、レポートを書きます。 そして、彼の前に、あるマネージャーがこれを行っていましたが、彼はますます手動テストを行いました。 たとえば、新しい機能をチェックしました。 これがヒンズー教徒です。 さて、私はこじ開け続けます、これは機能テストです。 どういうわけかパフォーマンスをテストしていますか？ いいえ、彼が言うには、もし顧客が遅い仕事について不平を言うようになったら、私たち自身がボトルネックを探し、それを自分で修正します。 製品の開発者はそれをよく知っています。 どのテスターがこれを処理できますか？
賢い人だと思った、彼はナンセンスだ。
歴史B.
昨日、Habrahabrに行くと、 「1つの高負荷リソースの開発と最適化の歴史」という記事に出くわします。 読んでいない人のために-著者は、彼が特定のリソースの管理者として働き始めた方法を書きます。 まもなく、このリソースはユーザー数の増加に対応できなくなり、著者である彼は、いくつかのテクノロジーを使用して、サーバーのパフォーマンスを改善し、データベースの負荷を数回削減しました。 「MySQLの負荷は4倍減少しました」というフレーズを読んで、コメントで質問します-あなたの最適化はすべてユーザーの応答時間にどのように影響しましたか？」回答から、作成者はユーザーエクスペリエンスではなく、開いている接続の数とSQLクエリの数に関心があることがわかります。
賢い人、私はもう一度考えましたが、私は彼が何のために何をしているのか完全には理解していません。
* * *
これら2つのケースは、最も一般的な負荷テストのアプローチを説明しています。 それらは次のように非常に簡単に説明できます。
A：「パフォーマンスに問題がある場合は、決定します。 自分自身。 特別なテスターは必要ありません。」
B：「...そして、サーバーのCPUがデータベースに対応していないことがわかりました。Googledの「MySQL + CPUの問題」で、すばらしいライブラリを見つけてインストールし、負荷がN倍に減少しました。
* * *
アプローチBへの批判から始めましょう（アルファベットの乱用を減らすために「管理者」と呼びましょう）。 そのため、「管理者」アプローチの重要な問題は、パフォーマンスの問題に関する誤った観点です 。
上記のストーリーからわかるように、管理者は管理者の目を通して見ます。 彼にとっての問題の指標は、サーバーの負荷であり、それによって状況の変化をより良く判断するための指標です。リクエスト、接続などの数と速度です。 問題は、特定のサイトで同じ問題を同じように見ている人が世界でさらに何人いるのかということです。 正解はゼロです。 サイトにアクセスするユーザーは、データベース内のインデックスについて心配する必要はありません。 CPUおよびディスクサブシステムのグラフィックス負荷には関心がありません。 彼らが言うことができる最大：「このサイトは遅い」。 そしてもう1つ、「同じものをすばやく探します」 SQLクエリの数に基づいてパフォーマンスを測定する人と「ページが遅くならないように」だけを気にする人の比率は1対Nです。Nはサイトへのすべての訪問者であり、1は非常に賢いが孤独な管理者です。
...管理者にこれをすべて言うと、彼らは通常、「しかし、ユーザーはそれがすべてどのように機能するかわかりません。 そして、私たちは知っています。 そして、ユーザーの意見に基づいて、問題の原因を特定することはほとんど不可能です。」 これに対して、必ず機能する既製の回答があります。 あなたが医者に来たとき、彼はあなたに何を尋ねているのですか？ 幸福について。 圧力と温度は後でのみ測定され、分析の方向はすぐには示されません。 そして、「どこで痛みますか？」または「悪化するのは朝か夕方か？」などの質問から始まります。 質問は単純であり、数学的に正確な答えを出すことは常に可能というわけではありませんが、病気の症状が決定されるのは彼らにあります。 そして、最終的に、患者を最も喜ばせるのは症状の緩和です。 「傷つけないように何か書いてください。」 または、私たちの場合-「ページごとに少なくとも200のリクエストを行いますが、速度を落とさないようにします」。 もちろん、良い医者は、患者の気持ちを説明するだけでは決して診断を下しません。 しかし、同じように、彼は決して彼を過小評価したり、さらに悪いことに彼を無視したりしません。
合計-「管理アプローチ」は、アプリケーションまたはサイトの実際のユーザーの観点からパフォーマンスの問題を考慮しないため、悪いです。 このオプションはおそらくサーバーには適していますが、クライアントには適していません。 ただし、クライアントの数がサーバーの数とほぼ等しい場合...これはあなたのケースではないと思います。
さらに、私の実践では、サーバー負荷チャートとデータベース統計を入力として使用する最適化の結果がほぼゼロになるという状況に繰り返し遭遇しました。
例1 ：Oracle統計の分析により、インデックスを作成するとクエリが2倍速く実行されることが示されました。 インデックスが作成され、クエリは1秒ではなく0.5の実行を開始し、操作の応答時間は35秒から34.5秒に減少しました。
例2 ：特定の操作が最適化され、実行中にサーバーCPUの負荷が30％減少しました。 残念ながら、ユーザーが実行する他のすべての操作のこの操作の割合は0.1％であるため、サーバー負荷の状況に大きな変化はなく、ユーザーは改善に気付きませんでした。
など。 「医師と患者」の例えに戻る：
-患者、あなたは今、正常な体温と血液組成を持っています、あなたは健康です。
「しかし、医者、まだ気分が悪い！..」
* * *
次に、Aのアプローチについて説明します。ご想像のとおり、「開発」と呼びます。友人が発言する視点は、開発者にとって非常に典型的なものです。 「私たちとは別に、私たちのアプリケーションを理解できるのは誰ですか？」、「テストは、フォーム上のボタンがクリックされたことを確認するときです」などです。 QAを怠ることは一般に業界の問題の1つですが、このトピックは別の記事に値するものであり、気を散らすことはありません。
「開発」アプローチの主な欠点は何ですか？ 問題は、ユーザーが問題に遭遇した後にのみ認識されます。 つまり、雷が鳴るまで。 悲しいかな、この瞬間にバプテスマを受けるには遅すぎることがしばしばわかります。 システムが動作し始め、何かにパッチを当ててねじ込む必要があることが判明した場合、クライアントは不満を抱きます。 チームリーダーのティムはチベットに向かいました。 文字通りすべてが遅いため、パフォーマンスの低下の原因を特定することは不可能です。 新しいサーバーにお金はかかりません-起こりうる問題のリストは無期限に継続できます。 通常、この状況では、最も才能のある（せいぜい）または最も忙しくない（最悪の）開発者のいくつかが、新年/四半期レポートの次の更新/ピーク負荷まで、外出先でラメシステムをサポートする松葉杖を緊急に作成します。 その後、さらに多くの人々がチベットに移動します。 常に自分自身であるとは限りません。
小さな発言。 原則として、パフォーマンスと負荷テストのコンサルタントとして、「開発」アプローチは通常「管理者」アプローチほど気になりません。 システムが「燃え尽きる」と、プログラマーと管理者の言葉-「すべてが順調です」または「今すぐすべてを修正します」-プロジェクトマネージャーを説得しなくなります。 積荷のために消防士を雇うことを決定しました。そして、出来上がりです-私は新しいクライアントを持っています。 親愛なるプログラマーと管理者-良い仕事を続けてくれて、どうもありがとう。 商業休憩の終わり。
顧客とお金を失いたくない、または履歴書を送る必要に直面したくない人のために、私は贈り物として新しい類推を持っています。 体育館に行って、健康を改善し、悪化を防ぐことができます。 誰もが2番目のオプションを選択するわけではありませんが、それが望ましいことに同意します。 健康と財布の両方のために。
問題を英雄的に戦うよりも回避する方が良いという事実に加えて、友人の言葉である「特別なテスター」という言葉で、力のテストを支持するもう1つの議論があります。 誰もが無意識のうちに、彼がすることはすべて完璧であると考えています。 またはほぼ完璧に。 開発者も例外ではありません。 「すべてがうまくいくことを確信しているなら、テストして、時間を失うだけです。」 ただし、経験から、a）側の人はより創意に富み、間違いを見つけることに成功し、b）QAに時間を費やすことで、将来的に時間とお金の両方を大幅に節約できます。 ソフトウェア開発を除くすべての業界。
* * *
そこで、システム管理者の観点から、および開発者の側から、アプリケーションをロードテストする2つのアプローチを検討しました。 どちらも不完全であり、どちらも最も重要な事実を見失っています。アプリケーションが作成され、システムが展開され、サイトが主にユーザー向けに開かれています 。 また、これらのユーザーを事前に管理することをお勧めします。
* * *
パフォーマンステストを開始する場所、ストレステストの種類、使用するのに適した方法などについて -これらすべてについて多くのことが書かれており、私は自分の言葉ですべてを語るという仕事を自分自身に設定していません。 代わりに、パフォーマンステストの特定の側面、テスト用のユーティリティのレビューなどについて時々執筆する予定です。 もちろん、このトピックが視聴者にとって興味深いものである場合。 ご清聴ありがとうございました。
All Articles