パフォーマンステスト---問題レコード

1.安定性を実行する前に環境を確認するには：

• プレスディスクスペース（結果ファイルの走行安定性の間に生成されたデータは、プレスが停止する圧力につながる十分なディスク容量がない場合は、増加し続けているため）。
• 空のサーバーのログには、エラーモードにログインサーバースペースを確認してください。
• データベースの表スペースは十分です。
• クリアログGC（GCケース簡単に安定性を観察します）。
• 実装プロセスは、ディスク上に格納されたデータとデータが生成された場合は、（これらのデータは削除することができるかどうかの場合には）定期的に削除データにスケジュールされたタスクを作成を検討する必要があります。

2、スクリプトエラー

• 圧力は、エラー、エラーを開始しませんでしたChengzhongギャングを行い、後に続け
  • 完全または表スペースが満杯であるかどうかをログで確認してください。
  • あまりにも多くによって引き起こされる結果を返すためにあまりにも多くのデータであるかどうか。

3、プロセスの安定性の応答時間は、より高いトランザクションを実行するように分岐しています。

• タイムアウトが最適化するために、持っている、そうでない場合は、時間外になる場合は、トランザクションタイムアウトの最大応答時間かどうかを確認し、最適化の可能性は？
• 実行する単一のトランザクション、観測された応答時間は、より高い実行するかどうか。
• トランザクションが表に依存データまたはクエリデータを処理していることを確認するために、依存データテーブルの増加は、トランザクション応答時間が増加した結果ではありません。
• 削除再テストシーンのトランザクション応答時間が増加するかどうかを確認するために増加します。
• あなたは最高のを最適化することができる場合に最適化されていない場合、それは、試験報告書に記載しなければなりません。
• データ量の増加は、他のテーブルによって引き起こされるため、トランザクション応答の結果を分析することにより、時間をかけて成長トランザクションの応答時間は、生産タイムアウト存在の増加をもたらさないように、毎朝は、生産上のいくつかのデータをクリーンアップします。

図4に示すように、負荷試験タイムアウト

• 分析から始めるための最も簡単な場所：ハードウェアのボトルネックがある場合は、ネットワークのボトルネックがあるかどうか、を押して、アプリケーションサーバ、データベースサーバをチェックしてください。
• トランザクションデータは、主に起因するデータベースのタイムアウトの理由に、あまり表に対応するかどうかを確認してください。
• 残業取引の重量、テーブルにインデックスがない参照してください全表スキャン。いくつかのデータがインデックスをしていないかどうかを確認するためにインデックスがある場合。
• あなたは、トランザクションのクエリかどうかを確認するために、インデックス、あまりにも多くのフィールドを取る場合（事業が365を加工するワンタイムデータを必要など、操作が比較的大きいです）。
• 行ロックの応答時間を使用してデータベースに得小さすぎるパラメトリックデータは、期限切れになる、プラス十分なデータをパラメータ化することができます。
• パラメトリックデータは、デッドロックが生じ、稼ぐために使用されるデータベーステーブルを引き起こし、小さすぎると、それはタイムアウトエラーを報告し、プラスに十分なパラメーター化データとすることができます。
• データベースのテーブルロック、行ロック、ロック待ち、デッドロックがタイムアウト（これらの問題かどうか、対応するSQLクエリを使用してOracle）になります。

5、スレッドプールがいっぱい

• TomcatはTomcatは、データベース接続のプールを備えているだけでなく、データベース接続プールの使用状況を監視する場合、スレッドプールの使用状況を監視するためにミドルウェアを監視します。構成300スレッドプールた場合は、300スレッドプールへの監視はすべて忙しくしている場合ので、それがスレッドプールは十分ではないことを意味し、後続の要求を待つためにキューイング、国に属するキューイングされ、応答時間の増加につながります。スレッドプールの設定が大きすぎるしかし、それは資源を浪費することになります。そのため、スレッドプールの不要な廃棄物を削減する必要があります。
• tomcat-users.xmlのは、configureの役割、ユーザー名、パスワード、Tomcatを再起動して管理者のステータスのTomcat、Tomcatの設定変更/ confにすることにより監視することにより。
• http：// localhost：8080にアクセス/管理/状態監視。
• キューは、直接ごみ接続いっぱいだった場合acceptCountを=「300」は、スレッドの数を参照するときです。maxthreads後続の要求がキューに配置されます、達し、これは、キューacceptCountをのサイズです。
  • シナリオ1：要求が受信され、この時点で開始したTomcatのスレッドの数がまだmaxThreadsのに達していない、Tomcatは要求を処理するスレッドを開始します。
  • シーン2：要求が受信され、この時点で開始したTomcatのスレッドの数は再びアイドルプロセスを待って、待ち行列にmaxThreadsの、Tomcatの場所の要求を達しています。
  • シナリオ3：要求を受け付け、この時間は、スタートアップのTomcatのスレッドの数は、maxThreadsのに達し、そしてacceptCountをも最大に達し、その後、Tomcatは要求を拒否し、戻って接続エラーを拒否する。
• 接続のTomcatの最大数を調整し、maxThreadsのacceptCountをを向上させることができ、より大きいまたは等しいacceptCountをするmaxThreadsの。
• 値は、要求がスレッド処理を解放した後に処理されている場合にのみ、待機状態になります流れの大きさに基づくべきである、と値が低すぎる場合は、すべての要求を処理するための十分なスレッドを持っていないだろうMaxTreads;のセットが高すぎる、tomcatの場合スタートは多くの時間がかかります。したがって、実際のテストのニーズ分析の値はmanagerstatusの前に話すことによってページを監視されていることを結論付けました。時間のボトルネックを突破することができない、盲目的に値を拡張しないように注意してください、あなたはパフォーマンスを改善するために、Tomcatのクラスタを使用することができます。