3

私たちの製品は性能面で評判が悪い。まあ、これは 13 年前の大きなエンタープライズ アプリケーションであり、軽食、特にパフォーマンスの向上が必要です。

このバージョンでは、パフォーマンスの問題に戦略的に対処することにしました。その方法についていくつかのオプションを評価しています。

市場で最高のツールを備えた経験豊富な負荷テスト エンジニアがいますが、通常、バージョン開発ライフ サイクルの後半に安定したリリースを取得します。(はい、以前の安定したバージョンを提供する必要があることはわかっています。このプロセスにも取り組んでいますが、私の領域ではありません)

私が推進している方向の 1 つは、開発者がコードのパフォーマンスへの影響をテストできるように、ナイトリー ビルドと共にインストールされたラボ環境をセットアップすることです。この環境が、実際のユーザー エクスペリエンスをシミュレートするスクリプトによって常に読み込まれるようにしたいと考えています。このロードされた環境では、各開発者は自分のコードをテストする特定のスクリプトを作成する必要があります (つまり、実際の環境での単一のユーザー エクスペリエンス)。新しい機能のパフォーマンスだけでなく、既存の機能に対する各反復の影響を示すレポートを生成したいと考えています。

目標が高すぎて、複雑になりすぎてしまうのではないかと少し心配です。

そのような考えについてどう思いますか。そのような環境をセットアップした経験がある人はいますか? あなたの経験を共有できますか?

4

5 に答える 5

2

生産性の最大の向上の 1 つは、夜間に実行される自動ビルド システムです (これは継続的インテグレーションと呼ばれます)。昨日犯したエラーは、今日の早朝、私がまだ新鮮で、昨日何をしたかをまだ覚えている可能性があるときに発見されます (数週間/数か月後ではなく)。

ですから、これを最初に実現することをお勧めします。これが他のすべての基盤となるからです。製品を確実に構築できない場合、開発プロセスを安定させるのが非常に難しくなります。

これを完了すると、パフォーマンス テストの作成に必要なすべての知識が得られます。

ただし、1 つのアドバイス: 一度にすべてを達成しようとしないでください。一度に 1 つずつ作業し、問題を 1 つずつ修正します。誰かが「私たちもこれをやらなければならない」と思ったら、他の機能要求と同じトリアージを行う必要があります。これはどのくらい重要ですか? どのくらい危険ですか?実装にはどのくらいかかりますか?いくら得するの?

基本が整理されるまで、難しいが重要なタスクを延期します。

于 2009-02-13T09:20:07.080 に答える
2

良いアイデアのように思えますが、正直なところ、組織がこの目的のためだけに雇用した高価な負荷テスト チームにビルドを提供できない場合、あなたのアイデアは機能しません。

最初にぶら下がっている果物を探してください。プロセスの早い段階で、パフォーマンス テスト チームが利用できるナイトリー ビルドを取得します。

実際、このバージョンがすべてパフォーマンスに関するものである場合、チームはこのバージョンだけを使用して、最後のバージョンのイテレーションの後半に発生したすべてのパフォーマンスの問題に対処する必要があります。

編集:「開発者はパフォーマンステストコードに責任を負わないでください」はコメントでした。そうですね。個人的には、すべての開発者に YourKit Java プロファイラー (安価で効果的) のコピーを持たせ、その使用方法を知ってもらいたいと考えています。ただし、残念ながら、パフォーマンス チューニングは非常に楽しい技術的な作業であり、機能の開発に適している場合は、これに多くの時間を費やすことができます。

開発者チームが著しく遅いコードを繰り返し開発している場合、パフォーマンスやより優れたプログラマーに関する教育が唯一の答えであり、費用のかかるプロセスではありません。

于 2009-02-13T08:56:03.580 に答える
1

ナイトリー ビルドは、パフォーマンス テストの正しいアプローチです。毎晩自動的に実行されるスクリプトを要求することをお勧めします。その後、結果をデータベースに記録し、定期的なレポートを提供します。実際には、次の 2 種類のレポートが必要です。

  • 経時的な各指標のグラフ。これで自分の傾向がわかります
  • ベースラインに対する各メトリックの比較。1 日の中で何かが劇的に低下したときや、パフォーマンスのしきい値を超えたときを知る必要があります。

その他のいくつかの提案:

  • マシンが意図した環境と同様に変化することを確認してください。プールにロー エンド マシンとハイエンド マシンを配置します。
  • 測定を開始したら、マシンを変更しないでください。好きなように比較する必要があります。新しいマシンを追加できますが、既存のマシンを変更することはできません。
于 2009-02-17T05:29:14.487 に答える
0

サニティテストを行うための小さなテスト ベッドを構築しました。つまり、ボタンを押したときにアプリが起動して期待どおりに動作したか、検証作業を行ったかなどです。ブラウザ。これらの実行からの出力は Xml ドキュメントとして作成され、CI ツール (クルーズ コントロール) は結果、エラー、およびパフォーマンスを各ビルド ログの一部として出力できます。全体がうまく機能し、適切な負荷テストのために複数の PC にスケーリングすることもできました。

しかし、私たちは道具よりも体が多かったので、それをすべて行いました。必要なすべてを実行する、いくつかの大きなエンド ストレス テスト ハーネスがあります。コストはかかりますが、手巻きに費やす時間よりも短くなります。私たちが抱えていたもう 1 つの問題は、開発者に Ruby/Watir のテストを作成させることでした。最終的には 1 人が担当し、それが原因でテスト作業がボトルネックになりました。

于 2009-02-13T08:58:40.673 に答える