パフォーマンスの問題をアプリケーション インフラストラクチャの特定のコンポーネントに切り分けるにはどうすればよいでしょうか? 具体的には、Web、アプリケーション、および/またはデータベース サーバー レベルでのボトルネックを区別する、結果ログに明確なマーカーはありますか?
インタビューでこの質問をされて、真っ白になりました。この情報はどこにもないようです。
パフォーマンスの問題をアプリケーション インフラストラクチャの特定のコンポーネントに切り分けるにはどうすればよいでしょうか? 具体的には、Web、アプリケーション、および/またはデータベース サーバー レベルでのボトルネックを区別する、結果ログに明確なマーカーはありますか?
インタビューでこの質問をされて、真っ白になりました。この情報はどこにもないようです。
SiteScopeおよびその他のエージェントレスによるシステムコンポーネントの監視に加えて、シナリオとスクリプトが期待どおりに機能していることを確認する必要があります。これには、適切なエラーチェックとトランザクション(および他の多くのもの)の使用が含まれます。トランザクションが十分にきめ細かい場合、これにより、少なくともパフォーマンスの問題があるリクエストについての洞察が得られます。これらの指標を取得したら、インフラストラクチャチームと協力して、ログやその他の情報を確認します。反復プロセスであるため、インフラストラクチャのますます小さなセクションに焦点を当ててテストを行うことができます。
さらに、loadrunnerスクリプトは、厳密に「フロントドアから入ってくる」ようにする必要はありません。多層システムを使用している場合は、スクリプトを作成してWeb/アプリ/データベースサーバーに直接アクセスできます。
何を探すべきかについては、「膝」または「ホッケースティック」タイプの動作を持つ測定値に焦点を当ててください。コントローラーでサーバーリソースタイプの測定値のいずれかに直接接続し、分析フェーズで他のチームの統計を統合できます。より低い仮想ユーザーレベルのベンチマークと比較して、許容できるものと許容できないものを判断します。
幸運を!
インタビューが LoadRunner に焦点を当てていて、SiteScope が考慮されている場合、それは HP/Mercury ソリューションにより焦点を当てているという結論に達するでしょう。
通常、この種の情報は、パフォーマンス テストの標準的な結果を見るだけでは入手できません。
探している情報の一部は、SiteScope を使用して、テストで関連するすべてのサーバーを監視することによって見つけることができます。SiteScope は、各サーバーで見られるように、CPU、メモリ、ディスク I/O、ネットワーク I/O など、調べるための多くのカウンターを提供します。
この情報は、ボトルネックがどこにあるかの手がかりを与える可能性があり、SiteScope に追加するカウンタが多いほど、ボトルネックを特定するための変更が大きくなります。
AppServer と DBServer のボトルネックは、生の応答時間やヒット数、ページなど (Web プロトコル) を見るだけで特定できるというのは非常によくある誤解です。もちろん、アクセスされた URI がシステム内の正確なコンポーネントを定義している場合を除きます。 .