LoadRunnerを活用したアプリケーションインタフェースProfiling
5909 ワード
2年前からLoadRunnerツールを使用していましたが、当時はまだ8.0版Mercuryの製品で、1年前からHPのLoadRunner 9.0を使用していて、とても実用的なツールでした.こんなに長い時間をかけてもそれに関連するものを書いたことがなく、主に本当に書くことができないと思っています.負荷生成ツールだけで、性能テストで必要な圧力を生成するために、Cや他の言語(C#など)に基づくプログラムスクリプトを柔軟に開発できます.もちろん、自動指標収集などの機能を使用するためには、フレームワーク/構造、関数セットに基づいて開発する必要があります.基本プログラムスクリプトは「録画」できます.大半を自動的に生成し、運が良ければほぼ直接パラメータ化できるので、この過程はあまり難しくありません.ここで言いたいのは,LoadRunnerツールを用いてアプリケーションシステムのインタフェース部分をProfilingすることである.実は個人的にはLoadRunnerの「録画」機能自体がProfilingの過程だと思いますが、クライアントが記録されています(Bowser/Fat client app)サーバ側アプリケーションとの通信プロセス.典型的なB/S Webアプリケーション構造では、フォーム提出、JavaScript非同期要求などの操作が記録されます.プロトコルによっては、Profilingが注目する面/レベルも異なります.もちろん、Profilingの角度の問題は普段あまり注目されません.このツールを使用するのは基本的に完了のためですシミュレーション生成負荷として性能に関するテストを行い,プログラムスクリプトを完了する目的もテスト自体を実行することである.
私のところにはこのような需要があります.MicrosoftベースのNET Remotingフレームワークの分散アプリケーションでは,先端表現層にSmart ClientとASPがある.NET二セット応用;ビジネスアプリケーション層はRemotingサービスであり、多くのWell-knownリモートオブジェクトが含まれており、ビジネス例を実現します.バックエンドはMicrosoft SQLサーバデータベースを使用して永続化されます.そう、標準的なエンタープライズ・アプリケーションです(MISシステムですか、ほほほ).このビジネス・インスタンスでは、負荷が重い場合に機能的な問題が発生し、トランザクションが少なくなることが必要です.このような問題を解決するには、まずRemotingの特定のビジネス・インスタンスで使用されるインタフェースを迅速に取得する必要があります.(Well-knownリモートオブジェクトおよび使用方法セット)この問題の記述はユーザの使用の観点から出発するため、分析プロセスを段階的に細分化し、インタフェースから始まり、最終的に使用例実装における問題の本質的な原因を見つける必要がある.一般開発者にとって、頭の中に浮かぶのは設計ドキュメントを探してコードを見ることであり、その中でwebを参考にすることもできると思う.configまたはapp.configのRemotingサービス構成は、分析、判断を支援します.この方法は正しいし、条例もあり、過程、方法にも合っているが、肝心な問題は迅速ではなく、次に他の関連設計、開発などに依存することだ.もしあなたがアプリケーションシステム(特にオンラインの生産システム)のTroubleshootingやtuningの仕事を担当したことがあるならば、あなたは私の意味を理解するかもしれません.こんなにたくさん言って急いで本題に入ります.賢い読者はきっとすでに反応して、LoadRunnerで“録画”しますアプリケーションで注目しているビジネス例を見ると、希望するRemotingインタフェースを得ることができます.正しいことを言っていますが、実際の過程にはいくつかのテクニックが必要です.以下に、私が上記のニーズを達成した方法を記録します.
まずLoadRunner 9.0が提供するMicrosoftを使用する.NETプロトコルは、「録画」フィルタ(Filters)を構成しています.ここでは、あなたが注目しているProfilingのレベルと言えます.LoadRunner 9.0は4つのプロシージャをサポートしています.ここでは、Remotingレベルの通信/呼び出しだけに注目しています.他のいくつかはあなたの必要に応じて構成されています.
上に配置したプロシージャで「録画」が完了すると、Profilingは次のRemotingインタフェース呼び出しプログラムスクリプトを得ることができます.LoadRunnerは、実際には、標準的なC#プロジェクト(csproj 8.0.50727)を作成し、その中のビジネス・インスタンス・インタフェースのクライアント・コール・コードを生成します.このプログラム・スクリプトもmsbuildツールによってコンパイルされています.次の短いセグメントを示します.
Remotingクライアントを書いたことがあると信じています.上のコードクリップには、サーバ側well-known Remotingリモートオブジェクトをアクティブ化し、パラメータオブジェクトを逆シーケンス化して準備し、リモートオブジェクトのインタフェースメソッドを呼び出し、結果を取得することが含まれています.この簡単なprofilingプロセスにより、ビジネス・インスタンスに注目するインタフェース呼び出し、実行シーケンスの詳細を明確に理解できます.正直に言うと、インタフェースprofilingという部分では、Red Gate ANTS Performance Profilerのようなprofilingツールよりも簡単で便利で、結果がかなりはっきりしています.
次に、ビジネス・インスタンスに注目するインタフェースの実行/呼び出しプロセスとステータス移行を明確にするために、上記で生成したprofilingコードを分析してUMLシーケンス図を形成することで明らかにすることができます.もちろん、これはあなたが問題を解決する必要がある複雑さにかかっています.簡単に見れば、シーケンス図を生成する必要はありません.
また、参考になる重要なリソースはRemotingプロファイル、webである.configまたはapp.config(プロセスconfig)ファイル.上のLoadRunner profilingのコードでアクティブ化された戻り結果は、4行目のコードに示すようにインタフェース(C#interface)であるためです.
これは、Remotingサービス側構成に対応するサービスremアドレスによって、インタフェースの具体的な実装クラスが何であるかを決定することができ、これは容易に見つけることができる.最後に私がここで最後に分析したフローチャートを貼り付けて、プロジェクトの内容にかかわるので小さな図に処理して、意味を見てみましょう.
上記の分析結果があれば、問題が存在できる位置や範囲を明確にすることができ、次の段階の細分化分析に正しい方向と基礎を提供し、徐々に細分化された分析過程を通じて、インタフェースから始まり、最終的に使用例の実現における問題の本質的な原因を見つけることができる.
作者:lzy.Je出典:http://lzy.iteye.com本文の著作権は作者の所有に帰して、要約と完全な全文の2つの形式で転載することを許可して、文字に対して裁断することを許可しません.著者の同意を得ずにこの声明を保留し、文章のページの明らかな位置に原文の接続を与えなければならない.そうしないと、法律責任を追及する権利を保留する.
私のところにはこのような需要があります.MicrosoftベースのNET Remotingフレームワークの分散アプリケーションでは,先端表現層にSmart ClientとASPがある.NET二セット応用;ビジネスアプリケーション層はRemotingサービスであり、多くのWell-knownリモートオブジェクトが含まれており、ビジネス例を実現します.バックエンドはMicrosoft SQLサーバデータベースを使用して永続化されます.そう、標準的なエンタープライズ・アプリケーションです(MISシステムですか、ほほほ).このビジネス・インスタンスでは、負荷が重い場合に機能的な問題が発生し、トランザクションが少なくなることが必要です.このような問題を解決するには、まずRemotingの特定のビジネス・インスタンスで使用されるインタフェースを迅速に取得する必要があります.(Well-knownリモートオブジェクトおよび使用方法セット)この問題の記述はユーザの使用の観点から出発するため、分析プロセスを段階的に細分化し、インタフェースから始まり、最終的に使用例実装における問題の本質的な原因を見つける必要がある.一般開発者にとって、頭の中に浮かぶのは設計ドキュメントを探してコードを見ることであり、その中でwebを参考にすることもできると思う.configまたはapp.configのRemotingサービス構成は、分析、判断を支援します.この方法は正しいし、条例もあり、過程、方法にも合っているが、肝心な問題は迅速ではなく、次に他の関連設計、開発などに依存することだ.もしあなたがアプリケーションシステム(特にオンラインの生産システム)のTroubleshootingやtuningの仕事を担当したことがあるならば、あなたは私の意味を理解するかもしれません.こんなにたくさん言って急いで本題に入ります.賢い読者はきっとすでに反応して、LoadRunnerで“録画”しますアプリケーションで注目しているビジネス例を見ると、希望するRemotingインタフェースを得ることができます.正しいことを言っていますが、実際の過程にはいくつかのテクニックが必要です.以下に、私が上記のニーズを達成した方法を記録します.
まずLoadRunner 9.0が提供するMicrosoftを使用する.NETプロトコルは、「録画」フィルタ(Filters)を構成しています.ここでは、あなたが注目しているProfilingのレベルと言えます.LoadRunner 9.0は4つのプロシージャをサポートしています.ここでは、Remotingレベルの通信/呼び出しだけに注目しています.他のいくつかはあなたの必要に応じて構成されています.
上に配置したプロシージャで「録画」が完了すると、Profilingは次のRemotingインタフェース呼び出しプログラムスクリプトを得ることができます.LoadRunnerは、実際には、標準的なC#プロジェクト(csproj 8.0.50727)を作成し、その中のビジネス・インスタンス・インタフェースのクライアント・コール・コードを生成します.このプログラム・スクリプトもmsbuildツールによってコンパイルされています.次の短いセグメントを示します.
namespace Script {
using LoadRunner;
using Mercury.LoadRunner.DotNetProtocol.Replay;
using System;
using System.Collections.Generic;
using System.Data;
using BusinessFacadeInterface;
using Entity;
public partial class VuserClass {
public virtual int Action() {
... ...
String url_17;
url_17 = "Tcp://192.168.0.1:9090/Query.rem";
IBusinessFacadeQuery_3 = ((IBusinessFacadeQuery)(Activator.GetObject(typeof(BusinessFacadeInterface.IBusinessFacadeQuery), url_17)));
otherChangeDec_2 = ((ChargeDescription)(LrReplayUtils.GetSerializedObject("Serialization_3016.bin")));
DataTable_27 = IBusinessFacadeQuery_3.QueryByChangeDec(otherChangeDec_2);
String url_18;
url_18 = "Tcp://192.168.0.1:9090/Query.rem";
IBusinessFacadeQuery_3 = ((IBusinessFacadeQuery)(Activator.GetObject(typeof(BusinessFacadeInterface.IBusinessFacadeQuery), url_18)));
Result_1 = IBusinessFacadeQuery_3.QueryByNO("010");
String url_19;
url_19 = "Tcp://192.168.0.1:9090/ResQuery.rem";
IBusinessFacadeResQuery_1 = ((IBusinessFacadeResQuery)(Activator.GetObject(typeof(BusinessFacadeInterface.IBusinessFacadeResQuery), url_19)));
condition_1 = ((ResEntity)(LrReplayUtils.GetSerializedObject("Serialization_3017.bin")));
user_1 = ((SystemUserEntity)(LrReplayUtils.GetSerializedObject("Serialization_3018.bin")));
List_2 = IBusinessFacadeResQuery_1.GetResEntity(condition_1, user_1);
... ...
return 0;
}
}
}
namespace Script {
using LoadRunner;
using Mercury.LoadRunner.DotNetProtocol.Replay;
using System;
using System.Collections.Generic;
using System.Data;
using BusinessFacadeInterface;
using Entity;
public partial class VuserClass {
... ...
private IBusinessFacadeQuery IBusinessFacadeQuery_3;
private OtherChargeDescription otherChangeDec_2;
private IBusinessFacadeResQuery IBusinessFacadeResQuery_1;
private ResCondition condition_1;
private User user_1;
private List List_2;
... ...
}
}
Remotingクライアントを書いたことがあると信じています.上のコードクリップには、サーバ側well-known Remotingリモートオブジェクトをアクティブ化し、パラメータオブジェクトを逆シーケンス化して準備し、リモートオブジェクトのインタフェースメソッドを呼び出し、結果を取得することが含まれています.この簡単なprofilingプロセスにより、ビジネス・インスタンスに注目するインタフェース呼び出し、実行シーケンスの詳細を明確に理解できます.正直に言うと、インタフェースprofilingという部分では、Red Gate ANTS Performance Profilerのようなprofilingツールよりも簡単で便利で、結果がかなりはっきりしています.
次に、ビジネス・インスタンスに注目するインタフェースの実行/呼び出しプロセスとステータス移行を明確にするために、上記で生成したprofilingコードを分析してUMLシーケンス図を形成することで明らかにすることができます.もちろん、これはあなたが問題を解決する必要がある複雑さにかかっています.簡単に見れば、シーケンス図を生成する必要はありません.
また、参考になる重要なリソースはRemotingプロファイル、webである.configまたはapp.config(プロセスconfig)ファイル.上のLoadRunner profilingのコードでアクティブ化された戻り結果は、4行目のコードに示すようにインタフェース(C#interface)であるためです.
Activator.GetObject(typeof(BusinessFacadeInterface.IBusinessFacadeQuery), "Tcp://192.168.0.1:9090/Query.rem");
これは、Remotingサービス側構成に対応するサービスremアドレスによって、インタフェースの具体的な実装クラスが何であるかを決定することができ、これは容易に見つけることができる.最後に私がここで最後に分析したフローチャートを貼り付けて、プロジェクトの内容にかかわるので小さな図に処理して、意味を見てみましょう.
上記の分析結果があれば、問題が存在できる位置や範囲を明確にすることができ、次の段階の細分化分析に正しい方向と基礎を提供し、徐々に細分化された分析過程を通じて、インタフェースから始まり、最終的に使用例の実現における問題の本質的な原因を見つけることができる.
作者:lzy.Je出典:http://lzy.iteye.com本文の著作権は作者の所有に帰して、要約と完全な全文の2つの形式で転載することを許可して、文字に対して裁断することを許可しません.著者の同意を得ずにこの声明を保留し、文章のページの明らかな位置に原文の接続を与えなければならない.そうしないと、法律責任を追及する権利を保留する.