11

パフォーマンスの調整が非常に必要なプロジェクトに取り組んでいます。

最適化によってプログラムの速度が向上しない場合に失敗するテストを作成するにはどうすればよいですか?

少し詳しく説明します。

問題は、最適化するパーツを見つけることではありません。そのために、さまざまなプロファイリングおよびベンチマークツールを使用できます。

問題は、自動テストを使用して、特定の最適化が実際に意図した効果をもたらしたことを文書化することです。また、テストスイートを使用して、パフォーマンスの低下の可能性を後で発見できれば非常に望ましいでしょう。

プロファイリングツールを実行していくつかの値を取得し、最適化されたコードがより良い値を生成すると断言できると思います。ただし、これに関する明らかな問題は、ベンチマーク値が厳密な値ではないことです。それらは地域の環境によって異なります。

では、この種の統合テストを行うために常に同じマシンを使用するという答えはありますか?その場合、同じハードウェアでもベンチマークの結果が異なる可能性があるため、結果に多少のあいまいさを考慮する必要があります。では、これをどのように考慮に入れるのでしょうか?

または、おそらく答えは、プログラムの古いバージョンを保持し、前後の結果を比較することですか?これはほとんど環境にとらわれないので、私の好みの方法です。誰かがこのアプローチの経験がありますか?最新バージョンのパフォーマンスが少なくとも前のバージョンと同じくらい良ければ、すべてのテストに合格することができれば、古いバージョンを1つ保持するだけでよいと思います。

4

9 に答える 9

6

ドライブ性能にTDDを適用するのは間違いだと思います。必ずそれを使用して、優れた設計と動作するコードを取得し、TDD の過程で記述されたテストを使用して、継続的な正確性を保証します。調整する必要があり、(TDD とは) 異なる手法とツールが適用されます。

TDD は、優れた設計、信頼性の高いコード、およびテスト カバレッジ セーフティ ネットを提供します。これでチューニングに適した場所に移動できますが、あなたや他の人が挙げた問題のために、チューニングの道をさらに進むことはできないと思います. 私は、TDD の大ファンであり、支持者であり、実践者であると言っています。

于 2009-04-16T17:35:10.713 に答える
3

まず、許容可能なパフォーマンスの基準を確立する必要があります。次に、既存のコードを使用するときにその基準に失敗するテストを考案する必要があります。次に、テストに合格するまで、パフォーマンスのコードを微調整する必要があります。パフォーマンスにはおそらく複数の基準があり、確かに複数のテストが必要です。

于 2009-04-15T13:15:18.557 に答える
2

現在のコードの実行時間を記録します。

if (newCode.RunningTime >= oldCode.RunningTime) Fail
于 2009-04-15T13:16:36.523 に答える
1

CI サーバーでテストとプロファイリングを実行します。負荷テストを定期的に実行することもできます。

あなたは違いを心配しているので(あなたが言ったように)、絶対値を定義することではありません。この実行のパフォーマンス測定値を最後のビルドのパフォーマンス測定値と比較し、その差を % として報告する追加のステップがあります。時間の重要な変化に対して赤い旗を立てることができます。

パフォーマンスに関心がある場合は、達成したい明確な目標を持ち、それを主張する必要があります。システム全体でのテストでそれらを測定する必要があります。アプリケーション ロジックが高速であっても、ビューに問題があり、目標を達成できない可能性があります。それを差分アプローチと組み合わせることもできますが、これらの場合、時間の変動に対する許容度が低くなります。

開発コンピューターで同じプロセスを実行できることに注意してください。そのコンピューターでの以前の実行のみを使用し、開発者間で共有されたものは使用しません。

于 2009-04-16T10:07:01.893 に答える
0

ケントベックと彼のチームは、TDDのすべてのテストを自動化しました。

ここでパフォーマンステストを行うために、TDDでのテストを自動化することもできます。

ここでのパフォーマンステストの基準は、「はい」または「いいえ」のケースをテストする必要があるということです。

仕様をよく知っていれば、TDDでも自動化できます

于 2012-01-09T06:58:15.010 に答える
0

チューニング自体については、古いコードと新しいコードを直接比較できます。ただし、両方のコピーを保持しないでください。これを管理するのは悪夢のようです。また、あるバージョンを別のバージョンと比較するだけです。機能の変更によって機能が遅くなる可能性がありますが、それはユーザーに受け入れられます。

個人的には、「前回のバージョンよりも速くなければならない」というタイプのパフォーマンス基準を見たことがありません。これは、測定が非常に難しいためです。

あなたは「パフォーマンスのチューニングが真剣に必要だ」と言います。どこ?どのクエリ?どの機能?ビジネス、ユーザーのことを誰が言いますか? 許容できるパフォーマンスとは? 3秒?2秒?50ミリ秒?

パフォーマンス分析の出発点は、合格/不合格の基準を定義することです。これがあれば、パフォーマンス テストを自動化できます。

信頼性のために、(単純な) 統計的アプローチを使用できます。たとえば、同じクエリを同じ条件で 100 回実行します。それらの 95% が n 秒以内に返された場合、それは合格です。

個人的には、標準のマシンまたは統合サーバー自体から、統合時にこれを行います。各テストの値をどこかに記録します (クルーズ コントロールには、この種の優れた機能がいくつかあります)。これを行うと、パフォーマンスが時間の経過とともに、ビルドごとにどのように進行するかを確認できます。グラフを作成することもできます。マネージャーはグラフが好きです。

自動テストを行っているかどうかにかかわらず、パフォーマンス テストを行う場合、安定した環境を維持することは常に困難です。どのように開発しても(TDD、ウォーターフォールなど)、その特定の問題が発生します。

于 2009-04-17T07:11:03.700 に答える
0

まだこの状況に直面していません;)しかし、私が直面した場合、これが私がそれを行う方法です. (これは Dave Astel の本から拾ったと思います)

ステップ#1:「許容できるパフォーマンス」の仕様を考え出す。たとえば、これは「ユーザーはN秒(またはミリ秒)でYを実行できる必要がある」ことを意味します。
ステップ#2:失敗するテストを作成します..使いやすいタイマー クラス (たとえば、.NET には StopWatch クラスがあります) を使用し、Assert.Less(actualTime, MySpec)
ステップ 3: テストが既にパスしていれば完了です。赤の場合は、最適化して緑にする必要があります。テストが緑色になるとすぐに、パフォーマンスは「許容可能」になります。

于 2009-04-20T15:08:02.077 に答える
0

私は Carl Manaster の回答に広く同意しますが、最新のツールを使用すると、TDD が機能テストに提供するいくつかの利点をパフォーマンス テストに取り入れることができます。

ほとんどの最新のパフォーマンス テスト フレームワーク (私の経験のほとんどはGatlingでのものですが、ほとんどのパフォーマンス テスト フレームワークの新しいバージョンにも同じことが当てはまると思います) では、自動化されたパフォーマンス テストを継続的インテグレーション ビルドに統合し、それを構成して、パフォーマンス要件が満たされていない場合、CI ビルドは失敗します。

そのため、パフォーマンス要件が何であるか (一部のアプリケーションでは、ユーザーまたはクライアントと合意した SLA によって決定される場合があります) を事前に合意することができれば、変更によってパフォーマンスの問題が発生した場合に迅速なフィードバックを得ることができ、パフォーマンスが必要な領域を特定できます。改善。

優れたパフォーマンス要件は、「1 時間あたり 5000 件の注文がある場合、ユーザー ジャーニーの 95% に 10 秒以下の待ち時間が含まれてはならず、画面遷移に 1 秒以上かかることはありません」という行に沿っています。

これは、CI パイプラインで本番環境に似たテスト環境にデプロイすることにも依存しています。

ただし、パフォーマンス要件を使用して、機能要件と同じように開発を推進することは、おそらくまだ良い考えではありません。機能要件を使用すると、通常、アプリケーションを実行する前にアプリケーションがテストに合格するかどうかについてある程度の洞察が得られます。合格すると思われるコードを記述しようとすることは賢明です。パフォーマンスに関して、パフォーマンスが測定されていないコードを最適化しようとすることは、疑わしい方法です。パフォーマンスの結果は、アプリケーション開発をある程度推進するために使用できますが、パフォーマンス要件ではありません。

于 2015-11-23T13:11:01.107 に答える