Oracle Load Testingの詳細...Oracle Load...

Oracleホワイト・ペーパー

2013年6月

Oracle Load Testingの詳細


製品概要 ...................................................................................................................................................... 1

はじめに ...................................................................................................................................................... 1

OpenScriptの負荷テスト・スクリプトを使用した実際的な負荷の生成 ........................................ 2

デフォルトの記録設定 ........................................................................................................................ 2

記録設定の変更 .................................................................................................................................... 4

Oracle Load Testingアーキテクチャ ...................................................................................................... 9

Oracle Load Testingでの負荷テストのライフ・サイクル ........................................................ 10

Oracle Load Testing Controllerとエージェントの実行時動作 ....................................................... 12

エージェント・プロセスの起動 ..................................................................................................... 12

JVMヒープのチューニング ............................................................................................................. 13

負荷テスト中のデータバンク・レコードの分散 .............................................................................. 15

結論 ............................................................................................................................................................ 18


製品概要 Oracle Application Testing Suite（Oracle ATS）はライフ・サイクル全体に対応した統合ソリューションであり、エンド・ツー・エンドの包括的なテストとテスト管理機能を通じてアプリケーションの品質とパフォーマンスを確保します。Oracle Application Testing Suiteは、個別にライセンス提供される次の3つの製品を通じて、高品質なアプリケーションの提供に貢献します。

• Oracle Functional Testingは、WebアプリケーションやWebサービス、Oracleパッケージ・アプリケーションの機能テストとリグレッション・テストを自動化します。

• Oracle Load Testingは、WebアプリケーションやWebサービス、Oracleパッケージ・アプリケーションおよびデータベースの負荷テストとパフォーマンス・テストを自動化します。

• Oracle Test Managerは、テスト計画、要件管理、テスト管理、テスト実行、不具合のトラッキングを含むテスト・ライフ・サイクル全体を通じてプロセスを管理します。

はじめに

IT組織は日常業務に多くの課題を抱えています。その1つは、エンドユーザーの要求を満たすスケーラビリティをアプリケーションとインフラストラクチャで確保することです。これを実現するには、アプリケーションのパフォーマンスを詳しく調べて、ボトルネックがあればこれを見つける必要があります。Oracle Application Testing SuiteのコンポーネントであるOracle Load Testingは、テスト対象のアプリケーションに対して実際的な負荷のシミュレーションを行うことで、本番稼働前にボトルネックとスケーラビリティの問題を見つけられるようにします。本書では、Oracle Load Testing内部の仕組みについて説明するとともに、負荷テストのスクリプトとシナリオを作成するための最適な設定を紹介します。堅牢な負荷テスト・スクリプトの作成について説明した後で、Oracle Load Testingのアーキテクチャとライフ・サイクルに焦点を絞ります。また、Oracle Load Testingの実行時の状況と負荷テスト中のデータバンク・レコードの動作についても説明します。

1


OpenScriptの負荷テスト・スクリプトを使用した現実的な負荷の生成

負荷テスト・レポートから正しい結果を得るには、テスト対象のアプリケーションに対して現実的なトラフィックを生成する負荷テスト・スクリプトの作成が絶対不可欠です。ここでは、現実的なトラフィックを実行時に生成するスクリプトを作成するための、OpenScript1の記録および再生時のプリファレンスについて確認していきます。

OpenScriptの記録プリファレンスは、デフォルトでは、静的なWebリソースをスクリプトに記録しません。静的なWebリソースがスクリプトに含まれないため、スクリプトがクリーンに保たれ、理解しやすく、拡張やデバッグが容易になります。その一方で、実際のトランザクションをシミュレートするため、OpenScriptは、スクリプトの実行中にこれらの静的Webリソースに対して自動的にリクエストを送信します。Load Testモジュールの記録と再生に対するデフォルト設定では、スクリプトの実行中に必ずしも現実的なトラフィックが生成されるとは限りません。スクリプト再生で、シミュレートされたキャッシュを使用してすべてのリクエストが生成されるように、デフォルトの設定を変更できます。

デフォルトの記録設定

デフォルトの記録がどのように動作するのかを理解するには、OpenScriptとテスト対象のアプリケーション間に2つのフィルタがあると仮定します。それぞれのhttpリクエスト/レスポンスがこれらのフィルタを通るときに、OpenScriptはこのリクエストをスクリプトに記録するかどうかを決定します。

図1に示すように、URLフィルタが最初のフィルタになります。URLフィルタは正規表現またはワイルド・カードに基づいて、リクエストURLまたはレスポンスのコンテンツ・タイプを突き合わせます。いったんリクエスト（またはレスポンス）がこれらのルールのいずれかによって除外されると、このリクエストはスクリプトに記録されません。たとえば、レスポンスのコンテンツ・タイプによってすべてのイメージが除外された場合、記録されるスクリプトにはいずれのイメージも含まれません。

表1：Download Managerによって解析されるタグのリスト

静的リソース・タイプ解析されるタグ

CSS <link>

イメージ <img>、タグのbackground属性、バックグラウンドurlの<style>

埋込みオブジェクト・リソース <embed>、<object>

スクリプト・リソース <script>

アプレット <applet>

1 OpenScriptはEclipse RCPベースのスタンドアロン・アプリケーションです。Oracle Functional Testingのコン

ポーネントで、負荷テスト・スクリプトおよび機能テスト・スクリプトの生成に使用されます。

2

--------------------------------------------------


図1で有効化されたDownload Manager（ダウンロード・マネージャ）が2番目のフィルタになります。記録の実行中、HTMLページなどの非静的リソースにアクセスするたびに、Download Managerは次に示すルールを使用してレスポンスを解析し、ページ内に埋め込まれた静的リソースを認識します。

リクエストまたはレスポンスがURLフィルタのルールによって除外されておらず、レスポンスが静的Webリソース（css、js、swfなど）である場合、Download Managerは、この静的Webリソースが解析済みの静的Webリソースのリストに含まれるかどうかをチェックします。リストに含まれない場合、このレスポンスに対するリクエストはスクリプトに記録されます。

再生中、Download Manager（有効化されている場合）は複数の接続を使用して、可能な限りすべての静的リソースをページから自動的に取得します。

図1：デフォルトの記録設定

3


制限

デフォルト設定はほとんどのケースで有効に機能しますが、一部のリソースが取得されないケースがあります。

• HTMLタグ内にないリソースURLは、Download Managerによって解析されません。たとえば、Download ManagerはJavaScriptによって動的に構成されるリソースURLを解析できません。

• HTMLページ・コンテンツ内に直接表示されないリソースURLは、Download Managerによって解析されません。たとえば、'css'ファイルをインポートするHTMLページは解析されません。ブラウザがHTMLページをロードするときに、自動的に'css'ファイルをロードし、'gif'リソースがあればこれをダウンロードします。

記録設定の変更

上記の制限を考慮に入れると、スクリプト再生中にすべてのリソースをダウンロードするには、記録設定と再生設定を変更し、カスタム・コードを加える必要があります。

図2：変更後の記録設定

4


図2に示した新しい設定では、すべてのURLフィルタが無効化されているため、すべてのレスポンスはDownload Managerフィルタのみを通過します。これにより、Download Managerによって解析されるHTMLページ内のリソースは、スクリプトに記録されるようになります。ブラウザは複数の接続を使用して、静的なWebリソースを並列でダウンロードするため、各ステップ・グループに含まれる静的リソースは、次のようにconcurrentブロックで囲む必要があります。

図3に、スクリプト再生中に静的Webリソースを取得する再生設定を示します。実際のブラウザ・セッションをシミュレートするには、Download Managerの他にキャッシングを有効化する必要があります。'Do Not Request URLs Ending In:'(次で終わるURLはリクエストしない)が空白になっていることを

確認します。

5


図3：再生の設定

6


例

この例では、ユーザーがアプリケーションにログインしたときに、次のCSSスニペットがイメージを要求します。

図4に、デフォルトの記録設定を使用した簡単なワークフローの記録を示します。図5に、変更後の記録設定（フィルタが削除され、Download Managerのみが有効）を使用して同じワークフローを記録した場合の、静的リソースに対するスクリプト内の追加リクエストを示します。

図4：デフォルトの記録設定を使用したスクリプト

7


URLフィルタが削除されているため、Download Managerは、すべてのアプリケーション・リソースに対してルールを適用します。Download ManagerはCSSファイルのイメージURLを解析できないため、レコーダを使用してこのリクエストをスクリプトに書き込みます。次に、変更した設定を使用して記録したスクリプトを再生すると、デフォルト設定で記録されたスクリプトとは異なり、すべてのリソース・リクエストがサーバーに送信されます。

図5：変更済み後の記録設定を使用したスクリプト

OpenScriptで負荷テスト・スクリプトを記録し、再生を検証したら、負荷テスト・プロジェクトでの次のフェーズは、Oracle Load Testingインフラストラクチャのセットアップと構成です。

8


Oracle Load Testingアーキテクチャ

ここでは、Oracle Load Testingのアーキテクチャについて確認します。選択したインストール・タイプでインストールされるコンポーネントについて説明した後で、Load Testingのライフ・サイクルについて詳しく説明します。

図6に、Oracle Load Testingのおおまかなコンポーネント全体像を示します。すべてのコンポーネントは、Oracle ATSのフル・インストールとともにインストールされます。テスト対象のアプリケーションに対する負荷の生成だけに使用されるリモート・マシンでは、ATS Agentのみをインストールすれば十分です。ATS Agentは、Data Collector、Agent Manager、Oracle Load Testing Agentコンポーネントをインストールして構成します。

図6：Oracle Load Testingアーキテクチャ

• Oracle Database - Oracle ATSの完全インストールでは、Oracle Database 10g Express Edition（XE）がインストールされます。Oracle XEデータベースはデモ目的としては便利ですが、本番の負荷テストではOracle Database 11g Enterprise Editionを別のサーバーにインストールして使用することを推奨します。

• Oracle Load Testing Controller - WindowsまたはLinux上で稼働するOracle WebLogicにデプロイされたWebアプリケーション。Agent Managerによる認証が成功したら、Oracle Load Testing ControllerはAgent Managerに対してコマンドを発行し、負荷テストをコントロールします。

• Agent Manager - Agent ManagerはOracle Load Testing AgentとData Collectorのライフ・サイクルを管理します。

• Oracle Load Testing Agent - エージェント・プロセスは、テスト対象アプリケーションに対して負荷を生成します。エージェント・プロセスの各スレッドが仮想ユーザー（Vuser）をシミュレートします。Agent Managerによって起動されるエージェント・プロセスの数は、負荷テスト・シナリオの設定によって異なります。

9


• Data Collector – 負荷テスト・シナリオ内にServerStatsが設定されている場合、Oracle Load Testing ControllerはAgent ManagerにData Collectorプロセスを起動するよう要求します。Data Collectorプロセスは監視対象システムに接続し、設定されたメトリックを指定された間隔で取得します。

Oracle Load Testingでの負荷テストのライフ・サイクル

負荷テスト・シナリオを実行するためにOracle Load Testingの各種コンポーネントがどのように連携するかを理解することが、負荷テストの環境をセットアップし、Oracle Load Testing ControllerとAgent Manager間でよくある接続の問題をトラブルシューティングするために役立ちます。図7にOracle Load Testingを使用した負荷テストのライフ・サイクルを示します。

図7：Oracle Load Testingコンポーネント間の通信

1. 負荷テストが開始されると、Oracle Load Testing Controllerは、ポート9001でリスニングしているAgent Managerに対して接続を開始します。接続が確立されると、Agent Managerは、Oracle Load Testing Controllerがサービスを利用するために適切な資格証明を提供したかどうかをチェックします。負荷テストの開始に失敗した場合は、エージェント・マシン上の<oracleats>/logs/agentmanager_auth.logファイルを確認して、Oracle Load Testing Controllerの認証が失敗したかどうかをチェックします。Oracle Load Testing Controllerに関するログ出力は、<oracleats>/logs/wls_oats.logファイルに含まれています。

10


2. 認証が成功すると、Oracle Load Testing ControllerはAgent Managerに対して、テスト対象アプリケーションの負荷を生成するエージェント・プロセスを起動するよう要求し、同時にトランザクション・メトリックを取得します。各エージェント・プロセスが、ポート8088でリスニングするOracle Load Testing Controllerへの接続を確立します。シナリオ実行中に生成されるすべてのエラー・メッセージと警告メッセージは、エージェント・マシン上の<oracleats>/logs/java_agent.log ファイルに記録されます。その他の出力は<oracleats>/logs/process_console_<xxx>.logファイルに書き込まれます。各エージェント・プロセスが1つのprocess_console_xxx.logファイルを作成し、このファイルはすべてのロギング要求に対応します。

3. シナリオ内でServerStatsが設定されている場合、Agent ManagerはData Collectorプロセスを起動します。Data Collectorプロセスは監視対象システムに接続し、一定の間隔でメトリックを収集します。Data Collectorは、ログ出力を<oracleats>/logs/dc-log_j0.txtファイルに送ります。

4. Oracle Load Testing AgentプロセスとData CollectorはOracle Load Testing Controllerへの接続を確立し、トランザクションとServerStatsメトリックをOracle Load Testing Controllerに送信します。

5. Oracle Load Testing Controllerは、Oracle Load Testing AgentとData Collectorから受け取ったデータをデータベースに保存します。

負荷テストが完了するか、ユーザーがテストの実行を停止または中断すると、Oracle Load Testing Controllerは、Oracle Load Testing AgentとData Collectorに対してkillシグナルを送信します。

11


Oracle Load Testing Controllerとエージェントの実行時動作

ここでは、Oracle Load Testingシナリオの設定がOracle Load Testingプロセスとエージェント・プロセスの実行時動作にどのような影響を与えるかについて確認します。負荷テストで利用できるシステム・リソースを有効に活用する必要がある場合、実行時動作のコントロールが非常に重要になります。

エージェント・プロセスの起動

負荷テストのライフ・サイクルの項で説明したように、Oracle Load Testing Controllerは、負荷テスト中にエージェント・プロセスを起動します。Oracle Load Testing Controllerが起動するエージェント・プロセスの数と起動されたエージェント・プロセスのヒープ・サイズを決めるのは、'Maximum Users per Process'(プロセス当たりの最大ユーザー数)と'Java Client Preferences'(Javaクライアントのプリファレンス)の設定です（図8を参照）。

図8：Edit Scenario Detailsウィンドウ

デフォルトの'Java Client Preferences'を使用する場合、Oracle Load Testing Controllerは1Gのヒープ・サイズを持つエージェント・プロセスを1つ起動し、このプロセスがシナリオに含まれるすべてのスクリプトのVuserを実行します。'Maximum Users Per Process'が2に設定されており、シナリオに対する全Vuser負荷の半分以上がプロセスによって実行されている場合、Oracle Load Testing Controllerは、最初のプロセスと同じプロパティを使用して、2番目のエージェント・プロセスを起動します。ここで注意すべき重要な点は、シナリオに含まれるすべてのスクリプトに同じ'Java Client Preferences'が設定されているため、別のエージェント・プロセスによって負荷が分散されるまでは、1つのエージェント・プロセスがシナリオ内のすべてのスクリプトのVuserを実行することです。

12


シナリオに2つのスクリプト（AとB）が含まれており、スクリプトAのヒープ・サイズがデフォルト（1G）で、スクリプトBは512MBである場合、スクリプトごとに'Java Client Preferences'設定が異な

るため、Oracle Load Testing Controllerは2つのエージェント・プロセスを起動します。このケースでは、スクリプトAの全Vuserが1Gのヒープ・サイズを持つエージェント・プロセスによって実行され、スクリプトBの全Vuserは512MBのヒープ・サイズを持つエージェント・プロセスによって実行されます。このケースでは、'Maximum Users per Process'は、起動されるすべてのプロセスに影響します。

JVMヒープのチューニング

場合によっては、負荷テスト・シナリオの要件に合わせて、Oracle ATS出荷時のデフォルトJVM設定を変更する必要があります。ここで留意すべき重要な点は、64ビットのLinuxビルドを除くすべてのOracle ATSビルドには、32ビットのJVMが付属している点です。ユーザーがJVMパラメータを変更できるおもな領域は、次の2つです。

• Oracle Load TestingをデプロイしたWebLogicサーバーのヒープ・サイズ。これは、負荷の大きいテスト中にOracle Load Testingに過度の負荷がかからないようにするために実行します。

• テスト対象アプリケーションに対する負荷を生成するOracle Load Testing Agentプロセスのヒープ・サイズ。

Oracle Load Testing Controllerに対するJVMヒープ・サイズの変更

次の表に、オペレーティング・システムとアーキテクチャに基づいてWebLogicサーバーに推奨されるヒープ・サイズを示します。

表2：Oracle Load Testing Controllerのヒープ・サイズ

オペレーティング・システム 32ビット 64ビット

Windows 変更不要。ヒープ・サイズのデフォルト値は1G

（-Xmx1g）

4GTが有効化されている場合は、ヒープ・サイズを

2Gに設定（-Xmx2g）2

最大ヒープ・サイズを3Gに設定（-Xmx3g）3

Linux（OEL、RHEL）ヒープ・サイズを2Gに変更（-Xmx2g） Linux 64ビット向けのOracle ATSビルドでは、ヒー

プ・サイズを大きい値に設定できます。

2 4GTが有効化されている場合、プロセスが使用できる仮想アドレス空間の最大値は3GBです。32ビットのWindowsで4GTを有効

化する手順については、http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473%28v=vs.85%29.aspxを参照し

てください。 3 ATSはWindows（32または64ビット）上で32ビットのJVMを使用します。64ビットのWindowsでは、32ビットのプロセスが4GB

の仮想アドレス空間全体を使用できます。

13

--------------------------------------------------


Windowsでのヒープ・サイズ変更手順

1. services.mscを使用して、Oracle ATS Serverサービスを停止します。

2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleATSServer\Parameters へ移動します。

3. CmdLineという名前のキーを探します。

4. ヒープの最大値を-Xmx1024mから適した値に変更します。

例：2GBのヒープを使用する場合、値を-Xmx2gに変更します。

Linux（OEL、RHEL）でのヒープ・サイズ変更手順

1. ATS Serverのデーモンを停止します（/sbin/service OracleATSServer stop）。

2. /etc/init.d/OracleATSServerを編集します。

3. 次の行を見つけます。“export USER_MEM_ARGS="-Xms256m -Xmx1024m"

4. ヒープの最大値を-Xmx1024mから適した値に変更します。

例：2GBのヒープを使用する場合、値を-Xmx2gに変更します。

Oracle Load Testingエージェント・プロセスに対するヒープ・サイズの変更

Oracle Load Testingエージェント・プロセスのヒープ・サイズは、'Edit Scenario Details'(シナリオ詳細の編集)ダイアログで設定します。Oracle Load Testingにスクリプトを追加した後で、スクリプトの横にある'Configure All Parameters'(すべてのパラメータの構成)をクリックしてヒープ・サイズを設定します。エージェント・プロセスのデフォルト・ヒープ・サイズは1Gです。

表3：Oracle Load Testingエージェント・プロセスのヒープ・サイズ

オペレーティング・システム 32ビット 64ビット

Windows 'Maximum JVM Heap size'(最大JVMヒープ・サイズ)のデフォ

ルト値を使用します。

'Maximum Users Per Process'を使用して、複数のエージェン

ト・プロセス間で負荷を分散します。

Oracle ATSはWindows上で64ビットのJVMを

使用しないため、設定は32ビットの場合と同様

です。

Linux 'Maximum JVM Heap size'(最大JVMヒープ・サイズ)のデフォ

ルト値を使用します。

'Maximum Users Per Process'を使用して、複数のエージェン

ト・プロセス間で負荷を分散します。

ヒープ・サイズを大きい値に設定できますが、4Gを上回るヒー

プ・サイズの設定は推奨されません。4

必要に応じて'Maximum Users Per Process'を

使用して、複数のエージェント・プロセス間で

負荷を分散します。

4大きいヒープ・サイズを有効活用するには、JVMのチューニングが必要になる場合があります。複数の負荷エージェント・プロ

セスを小さいヒープ・サイズで実行することで、ユーザーはエージェント・プロセスのチューニングに時間をかけるのではな

く負荷テスト自体に集中できます。

Oracle Load Testingに'ハードウェア見積もり'機能が導入されたことで、負荷テストの実施に必要なシステム・リソースやマシ

ンの見積もりは簡単な作業になりました。また、この機能を使用することで、試行錯誤や処理の監視に頼って値を決定しなく

14

--------------------------------------------------


負荷テスト中のデータバンク・レコードの分散

負荷テストから正確な結果を得るには、シナリオの設定が不可欠です。シナリオの詳細で指定できる各種パラメータに加えて、負荷テストを開始する前に各スクリプトに対してデータバンク・レコードの分散を設定する必要があります。パフォーマンス上の理由から、エージェント・プロセスはデータバンクから20ブロック単位でレコードを読み取ります。エージェント・プロセスによってシミュレートされるVuserがもっと多くのデータバンク・レコードを必要とする場合、エージェント・プロセスは追加の20レコードのセットを要求します。ローカル実行かリモート実行かに関係なく、複数のエージェント・プロセスが同じデータバンク・ファイルにアクセスする場合に限り、この動作がもたらす結果に問題はありません。これを理解するため、次の属性を持つ負荷テストについて考えてみましょう。

• スクリプトは、実行されるたびにデータバンクから1レコードを読み取る。

• 1回のスクリプト実行には少なくとも15分かかる。

• それぞれのVuserは1回だけ実行される。

• 総負荷は30 Vuserであり、30秒ごとに5 Vuser増加する。

• 'Maximum Users per Process'は10に設定されている。

• データバンクには100レコードが格納されている。

ても、一連のVuserに対する最適なヒープ・サイズが算出できるようになります。

15


図9：データバンク・キャッシュとOracle Load Testing

16


基本的には、3つの負荷エージェント・プロセスがそれぞれ10のVuserを実行します。留意すべき重要な点は、実行中のすべてのエージェント・プロセスに含まれるアクティブVuser数が'Maximum Users Per Process'の設定値（このユースケースでは10）に達した場合のみ、新しいエージェント・プロセスが起動されることです。30のVuserすべてが同じデータバンクにアクセスするため、エージェント・プロセス1が最初の10 Vuserのセットを実行し始めると、データバンクから最初の20レコードのセットがキャッシングされます。11番目のVuserを開始しようとすると、エージェント・プロセス2が起動され、2番目の20レコードのセットがデータバンクからキャッシングされます。同様に、エージェント・プロセス3は、3番目の20レコードのセットをデータバンクから読み取ります。

事実上、各エージェント・プロセスが使用するのは10レコードのみです。Vuser 1～10はレコード・セット1～10を使用し、Vuser 11～20はレコード・セット21～30を使用し、Vuser 21～30はレコード・セット41～50を使用します。キャッシング・メカニズムのせいで、複数プロセス間で分散されて同じデータバンクにアクセスするVuserは、レコードを順番に使用しない場合があります。

Vuserがデータバンクのレコードを順番に使用する必要がある場合は、'Maximum Users Per Process'を20に設定する必要があります。この設定を使用した場合に起動されるエージェント・プロセスは2つのみになり、エージェント・プロセス1はデータバンクのレコード・セット1～20を使用してVuser 1～20を実行し、エージェント・プロセス2はデータバンクのレコード・セット21～40を使用して（使用されるレコードは21～30の範囲のみ）Vuser 21～30を実行します。

17


結論

Oracle Load Testing負荷テスト・インフラストラクチャのセットアップは、複雑なタスクではありません。ただし、Oracle Load Testingは多数のサブシステムを使用しており、これらは同様に複雑なネットワークおよびITインフラストラクチャと相互作用するため、エンドユーザーは何らかの課題に直面する可能性があります。Oracle Load Testingの設定およびOracle Load Testingサブシステム間の相互作用を理解することが、環境セットアップに関する問題の克服につながります。同様に、堅牢な負荷テスト・スクリプトを容易に作成できることが、実際的な負荷テストを成功させるためには重要です。上述のとおり、OpenScriptを使用した堅牢な負荷テスト・スクリプトの作成は、直感的で簡単です。

Oracleパッケージ・アプリケーションやWebサービス、Webアプリケーションの実装におけるボトルネックを特定し、パフォーマンスの向上を目指す組織にとって、Oracle Application Testing Suiteは最適なソリューションです。

18


2013年6月

著者：Raja Vengala

共著者：Karilyn Loui、Yutaka Takatsu

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

oracle.com

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがない

ことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての

黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、

本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、

いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC

International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標また

は登録商標です。UNIXは、The Open Groupの登録商標です。0113

Oracle Load Testingの詳細...Oracle Load...

Documents

Transcript of Oracle Load Testingの詳細...Oracle Load...