アプリケーションのストレス テストやアプリケーションのデータベース インデックスの調整など、定期的なメンテナンスをどのくらいの頻度で実施していますか?
たとえば、データベース インデックスを週に 1 回、6 か月ごとに調整 (デフラグ、再編成、または再構築) しますか、それとも大量のデータが入力された後にのみ行いますか? また、メジャーまたはマイナー ビルドごとに、毎週、毎年、アプリケーションのストレス テストを行いますか?一度もない？
4 に答える
1
大手3DCAD会社で働いていたとき、次のようなテストを実行しました。
- コードをチェックインしたいときはいつでも。約40回のテスト。コードをチェックインする前に、すべてのテストに合格する必要がありました（コードレビューにも合格する必要がありました）。
- ビルドサーバーがローリングビルドを終了したときはいつでも
- 毎晩（多くのテスト、約8時間かかります）。
- 週に1回（さらに多くのテスト-この一連のテストは完了するまでに何日もかかります）。
各テストでは、さまざまな問題を強調するために、QAチームによって作成された特定の3Dモデルをロードしていました。一部のモデルは、以前から知られている顧客のバグを強調するために顧客から提供されたものだと確信しています。モデルのサイズは、3方向すべてでミクロンから1kmの範囲でした。
于 2010-03-11T18:54:32.253 に答える
1
コードが進化しているライブの本番システムでは、毎日がストレス テストです。同様に、データベースのチューニングとは、いつ停止するかを知ることです。パフォーマンスが許容できる場合は停止します。
特に Oracle に関して言えば、インデックスを再構築するかどうかについての議論は何年もの間激しさを増しています。そうすることを信じている人もいれば、信じていない人もいます。インデックスは B*tree 構造です。テーブルのデータを正確に反映します。多くの場合 (例外はありますが)、インデックスを再構築することは、クラッシュ ダイエットを行うことに似ています。確かに、インデックスは短期的には少なくなりますが、時間の経過とともに (おそらく数日または数時間の処理で)、元の状態に戻ります。パフォーマンスが目標を達成している限り、心配する必要はありません。インデックスを再構築すると、大量の I/O アクティビティが発生し (テーブルやインデックスを読み取る必要があります)、大量の REDO アクティビティが発生する (新しいインデックス エントリの REDO ベクトルを書き込む) か、即時のバックアップが必要になります (NOLOGGING を指定してインデックスを再構築した場合)。
例外:
ビットマップ インデックスは、DML アクティビティを介して異常に肥大化する可能性があるため、通常、オフラインにしてデータロード間で再構築する必要があります。
大量のデータを根本的にオフロードし、グローバル インデックスまたはその他の非ローカル パーティション インデックスを使用している場合は、合体 (再構築ではなく、隣接するリーフの隣接スペースを一緒にプッシュするだけ) が賢明です。
于 2010-03-03T14:52:07.257 に答える
0
私たちの（Web）アプリケーションは、新しいバージョンをライブでインストールする前に、ライブ前の環境でストレステストされています。テスト計画は、顧客に直接報告する外部企業によって作成および実行されます。
唯一の問題：多くの場合、ライブ前のストレステストが問題なく機能していても、ライブ環境でパフォーマンスの問題が発生しました。「合成」負荷は「実際の」負荷とは大きすぎるようです。
于 2010-03-02T10:03:55.433 に答える
0
私の推測では、これは、クライアントがパフォーマンスについて不平を言う前ではなく、最初に不平を言うときに行われる可能性のある種類のことです。
于 2010-03-02T09:55:26.697 に答える