22
20156スケーラビリティとパフォーマンス Oracle WebCenter Portal ®

スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

  • Upload
    ngokien

  • View
    244

  • Download
    9

Embed Size (px)

Citation preview

Page 1: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

2015年6月

スケーラビリティとパフォーマンス Oracle WebCenter Portal®

Page 2: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

2

目標 このホワイト・ペーパーでは、Oracle WebCenter Portal 11.1.1.8.0のベンチマーク結果について説明します。デプロイメントに必要なハードウェアをサイジングする際は、このベンチマーク結果を参考にしてください。

概要

以下のタスクを実行する際の参考にしたいということで、WebCenter Portalのパフォーマンス・ベンチマーク情報を求められることがこれまでに何度もありました。

1. 特定のデプロイメントに必要なハードウェアの決定

2. ユーザー数に応じたハードウェア要件の算定

これまではベンチマーク情報がなかったため、経験に基づいてサイジングを行うか、サイジング・ツールに頼る必要がありました。しかしツールでは、自社固有の要件が完全には表現できないリスクがありました。

WebCenter Portal 11.1.1.8.0でパフォーマンスが大幅に改善されたため、信頼できるパフォーマンス・ベンチマークを公開するには良いタイミングです。

オラクルでは、実際のデプロイメントに近い結果が得られるとの認識から、パフォーマンス・テストにはサンプルに基づくサイジング手法を用いることにしました。

利用者ごとにデプロイメントが大きく異なることは容易に予測できるため、万能な1つのデプロイメントをリファレンスにするという無理な試みはあらかじめ除外しています。そこでオラクルが採ったのは、この製品の利用方法を正確に反映した1つのユースケースでテストを行うというアプローチです。

ユースケースとしては、個々の実装に依存する、ディスカッション・フォーラムやSOA/BPMなどのサービスが統合されていない、よくある大規模な企業イントラネットを反映するものを選択しました。重点を置いたのは、ページ・ナビゲーション、コンテンツ更新、コンテンツ読取りといったごく一般的なコア・ユースケースです。

このホワイト・ペーパーでは、ベンチマーク・テストで利用したユースケース、デプロイメント・トポロジ、ベスト・プラクティス、構成/最適化、および推奨されるハードウェアについて説明します。

従業員やマネージャーがイントラネット上で実行するアクティビティとして一般的な利用フローを使用し、ユーザー・ロードを変えて結果を出しています。テストしたユーザー・ロードは、400、800、1600です。このテストにより、1秒あたりのトランザクション数は、ユーザー数および管理対象サーバー数に比例して増加することが分かりました。また、平均サーバー応答時間は、ユーザー数が増えるほど増加しました。

Page 3: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

3

変更履歴

バージョン 変更内容

0.1 2014 年 7 月の元のバージョン

最新バージョン サイジングに関する更新

対象範囲

このホワイト・ペーパーでは、WebCenter Portal 11.1.1.8.0リリースを使用して作成された大規模な企業イントラネットのリファレンス・デプロイメント上で、パフォーマンス・ベンチマークを実施した結果について説明します。

Page 4: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

4

ユースケース

企業イントラネットは、情報提供を目的とした記事や各種案内用のポートレットなどのコンテンツで構成されるランディング・ページを提供します。ランディング・ページは、ログインの有無に関係なくすべての従業員が閲覧できます。これ以外に、部門ごとの独自セクションがあり、そこへのアクセスや編集はその事業部門(LOB)にのみ許可されます。LOBのコンテンツやブランド付きページを作成できるのは、そのLOBの認証を受けたユーザー(ログイン済みの人)のみです。ログインしたユーザーは、カスタマイズされたページでさまざまなコンテンツやドキュメントなどを閲覧できます。

このイントラネット・ポータルのセットアップにはランディング・ページがあります。ランディング・ページのプレビューを以下に示します。

図1:イントラネットのランディング・ページ

Page 5: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

5

部門固有のサイト

ユーザーが部門固有のサイトにナビゲートすると、メニュー・ナビゲーションとページ・コンテンツが変化します。それぞれのLOBは独自のドキュメント・セットを所有しますが、このドキュメント・セットはフォルダとサブフォルダに整理されます。

図2:部門ページ

権限を持つユーザーはサイトにコンテンツを投稿することができます。

イントラネット・ポータルの構造

o この会社には合計25の部門がある。

o イントラネット・ポータルは、部門あたり1,001ページで構成される。

o 各部門は独自のポータルを所有し、メイン・イントラネット・ポータルのナビゲーション・モデルで表示される。

o 部門ポータルのどこからでもメイン・ポータルにナビゲートできる。

o 各部門にはホームページがあり、このページはイントラネットのランディング・ページとは異なる。ホームページは異なるページとナビゲーションのセットで構成される。

Page 6: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

6

o それぞれの部門ポータルは、通常1,001ページで構成される。

o ページにはページ階層がある。ページ階層の深さは3レベルまで設定できる。

o システム内には10万件のドキュメントがある。

25の部門があり、各部門は4,000のドキュメントを所有する。ドキュメントは8つのフォルダに整理され、各フォルダにドキュメントが500ずつ格納される。各フォルダの特性は以下のとおり。

ドキュメントの種類 ドキュメントの数 各ドキュメントのサイズ

100KB .doc 100 100KB

1000KB .doc 138 1MB

.mp4 25 20MB

.pdf 137 1MB

.xls 100 100KB

o 各ドキュメントには、検索用のメタデータが添付される。このテストでは、いくつかの単純なメタデータ・フィールドと値(作成者名、ドキュメント名など)を設定した。

イントラネット・ポータルの匿名ランディング・ページ

o どのユーザーも、最初にこのランディング・ページ(ホームページ)にアクセスする。

o ホームページにはカスタムのルック・アンド・フィールが適用され、企業ブランドが反映される。

o ブランディングはポータル全体で統一される。

ホームページ

ホームページは次のコンポーネントで構成される。

o 新着記事や業界関連トピックを示すコンテンツ・プレゼンタ項目。

o 一部の項目には画像が含まれる。

o 水平、垂直方向のナビゲーション。一部のリンクは、ポータルのルック・アンド・フィールを維持しながら、外部のシステムにジャンプする。

o ポータル内のコンテンツ検索機能。

o ポータルには複数の水平ナビゲーション・モデルを設定できる。

o ユーザーはポータルにログインするかを選択可能。

o ログイン後

ユーザーがログインすると水平ナビゲーション・モデルが変更され、ユーザーのアクセス・レベルに応じたモデルが表示される。

ユーザーには、所属する各部門の情報が表示される。

ナビゲーション・モデルは、部門に含まれるページとページ階層を反映したもので、画像が含まれる場合がある。

部門ポータル

o 部門ごとに独自のポータルがあり、そのポータルはメイン・イントラネット・ポータルのナビゲーション・モデルで表示される。

o 部門ポータルのどこからでもメイン・ポータルにナビゲートできる。

o 部門ごとにホームページがありますが、それはイントラネット・ポータルのホームページとは異なる。

Page 7: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

7

o それぞれの部門ポータルは通常、最大1,001ページで構成されまる。

o ページにはページ階層があります。ページ階層の深さは3レベルまで設定できる。

ページの階層

o Class A

部門のホームページ。

ホームページは他のページへのナビゲーションで構成される。

o Class B

部門ポータルのトップレベル・ページ。

このページは、部門固有のサイトに似たページで構成することもできる。

o Class C

このページは、部門固有のサイトに似たページで構成することもできる。

インライン編集が可能なコンテンツが含まれるページが少しある。

部門に所属するすべての従業員が利用できるページが少しある。

部門の一部の従業員しか利用できないページが少しある。

その他のページは誰でもアクセスできる(パブリック・ページ)。

o Class D

部門に所属するすべての従業員が利用できるページが少しある。

部門のごく一部の従業員しか利用できないページが少しある。

o Class A、B、C、Dのページのコンテンツ

通常1つのページは、ドキュメントの一覧、新着記事、プレス・リリース、画像で構成される。

ページのコンテンツは、コンテンツ・プレゼンタ(新着記事、リリース、画像などのタイプのコンテンツを表示するためのWebCenter Portalの機能)を使用して表示される。詳細については、WebCenter Portalドキュメントのコンテンツ・プレゼンタに関する説明を参照してください。

コンテンツ・プレゼンタによってレンダリングされるコンテンツの断片には、それぞれテキスト(2,200語前後)、画像、および書式設定(箇条書き、イタリックなど)が含まれる。コンテンツ・プレゼンタに設定されるコンテンツはそれぞれ異なる。

それぞれのページにはコンテンツ・プレゼンタが設定されている。

各部門ポータルには、平均4,000のドキュメントが含まれる。

o これらのページはナビゲーション・モデル(2レベル)を使用して表現され、部門固有のさまざまなページがここからリンクされる。

o グローバル検索と部門内検索の両方が可能。部門内検索では、ユーザーが所属する部門を検索した結果が表示される。グローバル検索では、グローバルに利用可能なドキュメントを検索した結果が表示される。

Page 8: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

8

ベンチマークの仕様と方法

トポロジ

以下の図にハードウェア・デプロイメント・トポロジを示します。この図には、システム内で稼働する各ノードのハードウェア構成が含まれます。

ハードウェア

トポロジの詳細

1. 各ノードは、管理対象サーバーを実行するJVM。

2. 2台の物理マシンの間でクラスタが構成される。

3. 各JVMは、管理対象サーバーによって内部的にクラスタ化される。

4. セットアップはすべて1つのネットワーク・ドメインに属する。

5. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別のマシン上でさらに4つのWebCenter Portalノードが稼働する。したがって、2台の物理マシンに8つのノードが存在していることになる。

6. BigIPは"ラウンドロビン"アルゴリズムに従って構成されている。

7. データベースはNFSマウントされている。

8. WebCenter PortalはWebLogicサーバー上で稼働する。

Page 9: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

9

以下の表に、このトポロジの各ノードで稼働するハードウェアについて示します。

表1:パフォーマンス・テストに使用したマシンの詳細

1 台の物理マシンの

ハードウェアの詳細

CPU メモリ OS 用途 ローカ

ル・ディ

スク

タイプ

タイプ プロセッサ CPU あたりの

コア数

速度

2 台の物理マシン、

各マシンでは

WebCenter Portal 用

の 4つの JVMが稼働

Intel(R)

Xeon(R) CPU

24(2 CPU*6

コア*2(ハイ

パー・スレッ

ディング))

6 3.07

GHz

142GB RHEL 5.8 WC 中間層 3.7

TB

Westmere(2 つの物

理 CPU、CPU あたり

6 コア、ハイパー・

マルチ・スレッディ

ング)

1台の物理マシン、こ

のマシンでは

WebCenter Content用の

2つの JVMが稼働

Intel(R)

Xeon(R) CPU

24 6 3.07

GHz

142GB RHEL 5.8 WC 中間層 3.7

TB

Westmere

WebCenter

Portal/WebCenter

Contentデータベース

Intel(R)

Xeon(R) CPU

E5- 2690 0

2.90GHz

32(4 CPU) 8 2.9

GHz

264GB RHEL 5.8 Portal/UCM

DB

2TB Westmere

Oracle Internet

Directory/DB

Intel(R)

Xeon(R) CPU

E5- 2690 0

2.90GHz

32(4 CPU) 8 2.9

GHz

264GB RHEL 5.8 OID/OID DB 2TB Westmere

Oracle HTTP Server

(1)

Intel® Xeon®

CPU

2 2 2.33

GHz

32GB RHEL 5.4 OHS2 133

GB

WoodCrest

Oracle Secure

Enterprise Search

Intel(R)

Xeon(R) CPU

4 4 2.27

GHz

71GB RHEL 5.8 SES 103

GB

Harpertown

ソフトウェア

以下の表に、テストに使用したソフトウェアの概要を示します。

名前 バージョン

WebCenter Portal 11.1.1.8.0

WebCenter Content 11.1.1.8.0

WebCenter Portal/WebCenter Contentデータベース 11.2.0.4.0

Oracle Internet Directory/Oracle Internet Directoryデータベース 11.2.0.4.0

Oracle Secure Enterprise Search(SES) 11.2.2.2.0

Page 10: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

10

パフォーマンス・ベンチマークの方法

1. ソフトウェアをインストールし、最適なパフォーマンスが発揮されるように構成しました。

2. 基本のユーザー・セットを用いて、ユーザー・フローをパラレルで実行しました。応答時間が3秒を超えるかCPU使用率が80%を超えるまでユーザー数を増やしました。

3. その結果を取得しました。

ユーザー・フロー

ユーザーが業務中に通常実行する典型的なシナリオのことを"ユーザー・フロー"と定義します。

ユーザー・フロー1(従業員)

1. ランディング・ページまたはホームページにアクセスします。

2. ログインします。

3. ログイン後、アクセス可能なその他の情報やLOB固有の情報を含むホームページにナビゲートします。'x'分が経過するまでそのページで待機します。

4. グローバル検索ボックスを使用してドキュメントを検索します。検索結果が表示されるまで待機します。結果をクリックして表示します。'x'分が経過するまでそのページで待機します。

5. ログアウトします。

ユーザー・フロー2(パブリック、匿名)

1. ログインはしません。

2. イントラネット・ポータルのホームページにアクセスします。'x'分が経過するまでそのページで待機します。

3. 部門ポータルの特定のパブリック・ページにナビゲートします。部門ポータルの選択はランダムです。'x'分が経過するまでそのページで待機します。

4. ページ階層内をランダムにナビゲートします。'x'分が経過するまでそのページで待機します。

5. 検索ボックスを使用してドキュメントの部門内検索を実行します。検索結果が表示されるまで待機します。検索結果の1つをクリックして表示します。'x'分が経過するまでそのページで待機します。

6. ログアウトします。

ユーザー・フロー3(マネージャー)

1. ホームページにログインします。

2. 部門のパブリック・ページにアクセスします。'x'分が経過するまでそのページで待機します。

3. その部門に所属する従業員だけがアクセスできる部門内ページにアクセスします。部門ポータルの選択はランダムです。'x'分が経過するまでそのページで待機します。

4. 部門内の特定のユーザーだけがアクセスできる部門ポータルのページにアクセスします。'x'分が経過するまでそのページで待機します。

Page 11: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

11

5. ログアウトします。

ユーザー・フロー4(管理者)

1. ホームページにログインします。

2. 部門のパブリック・ページにアクセスします。'x'分が経過するまでそのページで待機します。

3. その部門に所属する従業員だけがアクセスできる部門内ページにアクセスします。部門ポータルの選択はランダムです。'x'分が経過するまでそのページで待機します。

4. このユーザーは、部門内のページを作成する権限を持っています。ページを作成します。ページを編集し、構成します。'y'分が経過するまでそのページで待機します。

5. 1MBのドキュメントのアップロード/ダウンロードも実行します。

6. ログアウトします。

*このシステムではOracle WebCenter ContentのInbound Refineryを構成していないため、ドキュメントのプレビューを表示するのではなく、ドキュメントのプロパティのみ表示しました。

ユーザー・ロード

テスト前の構成手順

1. シナリオをセットアップしました。

2. シングル・ユーザーの実行によってこのシナリオを検証しました。

3. シナリオに従って、関連するすべてのデータを調査し、データベースおよびSESで更新処理が行われているかを手動で検証しました。

1,600ユーザーの場合のユーザー・フローの配分:

ユーザー・フロー ユーザー・タイプ ユーザーの割合(%)

ユーザー・フロー1 従業員 25% = 400人

ユーザー・フロー2 匿名 45% = 720人

ユーザー・フロー3 マネージャー 15% = 240人

ユーザー・フロー4 管理者 15% = 240人

注('x'と'y'については上記のユーザー・フローを参照してください):

1. 'x' = それぞれのページで1分待機します。

2. 'y' = それぞれのページで5分待機します。

3. 待機時間を示していないユーザー・フローでの待機時間は30秒です。

Page 12: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

12

ベンチマークの結果

テスト・ソフトウェア

HP LoadRunner®を使用してベンチマーク・テストを実施しました。

パフォーマンス・チューニング

1. 思考時間 = 30秒のランダムな思考時間(ユーザー・フローでの次のトランザクションまでの時間)

2. コールド・セッション - セッション間のユーザーのログイン/ログアウト

3. WebCenter Portal用の各ノードのJVM設定

4. Oracle HTTP Serverのチューニング

JVMの引数"-server -Dweblogic.ProductionModeEnabled=true - Dweblogic.SocketReaders=1 -Xms20G -Xmx20G -Xns5G -Xgc:genpar - XXcompaction:maxReferences=40000000 -XX:+UseLargePagesForHeap -noverify - Djrockit.codegen.newlockmatching=true -Xverbose:gc,compaction - Djps.auth.debug=false -Djps.subject.cache.key=5 - Djps.policystore.grantee.cache=false - Xverboselog:/scratch/aime1/WCP_WC8Stg8/user_projects/domains/wc_domain/lo g/WC_GC_1.log -Doracle.mds.bypassCustRestrict=true - Dweblogic.security.SSL.trustedCAKeyStore="/scratch/aime1/WCP_WC8Stg8/wlserv er_10.3/server/lib/cacerts" ${JAVA_OPTIONS}"

Page 13: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

13

5. JDKバージョン:javaバージョン"1.6.0_37" Java(TM) SE Runtime Environment(ビルド1.6.0_37- b06 Oracle JRockit(R)(ビルドR28.2.5-50-153520-1.6.0_37-20121220-0843-linux-x86_64、コンパイル・モード)

6. 安定状態:30分(60分~90分)(システム総実行時間は2時間)

7. サーバーのログイン設定はデフォルト値に設定(ログ・レベルはlogging.xmlでERRORに設定)

8. セッション・タイムアウト - (デフォルト)

9. ヒープ・サイズは20GBに設定

10. 3GBのMDSキャッシュ(TTLは0に設定)

11. Oracle Java Server Pageキャッシュのチューニングは以下のとおりです。

12. contentDelivery="lazy"(コンテンツ配信を制御するためのOracle ADFのパラメータ)

13. JDBCプールは最大400に設定

14. 追加したJVM引数:“-XXcompaction:maxReferences=40000000”

15. Coherenceキャッシュの構成(http://docs.oracle.com/cd/E21764_01/webcenter.1111/e12405/wcadm_documents.htm#BA

BHFCJHのページを参照してください)

16. WebCenter Portal BP3(11.1.1.8.3)バンドル・パッチの適用が推奨されます。

次の<inti-parm>のコードを、以下の<servlet>の下に追加します。 <servlet>

<servlet-name> oraclejsp

</servlet-name>

<init-param> <param-name>

jsp_idle_entry_count </param-name> <param-value>

2000 </param-value>

</init-param> <init-param>

MaxSpareThreads 75

ThreadsPerChild 50

MaxRequestsPerChild 0

AcceptMutex

LockFile "${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/$ {COMPONENT NAME}/http lock"

</IfModule>

Page 14: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

14

1秒あたりのトランザクション数(TPS)、CPU使用率、メモリ使用率 ユーザー数/管理対象サー

バー台数

CPU使用率

(ポータル・サーバー)

TPS(1秒あたりのトランザク

ション数)

メモリ 平均サーバー応答時間(秒)

200/1 11.32 4.59 5.23 0.81

400/2 12.33 9.21 6.27 0.87

800/4 24.8 18.46 6.51 0.9

1600/8 64.75 36.59 6.90 1.29

このテストでは、1つの操作(ログイン、ポータル間のナビゲーション、ポータル内のページ間のナビゲーション、ポータルの作成、ページの作成など)を実行する際のクリック1回を"トランザクション"と定義しました。

スループットはユーザー数に比例しています。

スループット

40

35

30

25

20

15

10

5

0

0 500 1000 1500 2000

ユーザー数

1秒あ

たり

のト

ラン

ザク

ショ

ン数

(TP

S)

Page 15: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

15

ユーザー数の増加に伴って、平均サーバー応答時間を維持するために必要になる管理対象サーバー数も増加します。

TPSと管理対象サーバー数 40

35

30

25

20

15

10

5

0

0 2 4 6 8 10

管理対象サーバー数

平均サーバー応答時間(秒) 1.4

1.2

1

0.8

0.6

0.4

0.2

0

0 500 1000 1500 2000

平均サーバー応答時間は、ユーザー数が増えるほど増加しています。

1秒あ

たり

のト

ラン

ザク

ショ

ン数

(TP

S)

平均応答時間(秒)

Page 16: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

16

クライアントの応答時間

テスト用のセットアップ

• デスクトップ:Windows 7/Internet Explorer 9

• モバイル:Apple iPad3/iOS 6.1.3

• テスト時はバックグラウンドで20のユーザー・ロードが発生

デスクトップ・ブラウザの結果

全体的な応答時間(秒)

ユーザー・フロー1(従業員ロールを持つユーザーがドキュメントを検索/閲覧する。

詳細については前述のユーザー・フローの説明を参照)

2.5

ユーザー・フロー2(ログインしていないユーザーがポータルをナビゲートし、ドキュ

メントを検索/閲覧する。詳細については前述のユーザー・フローの説明を参照)

2.1

ユーザー・フロー3(マネージャー・ロールを持つユーザーがログインしてポータ

ルをナビゲートし、ドキュメントを検索/閲覧する。詳細については前述のユー

ザー・フローの説明を参照)

2.2

ユーザー・フロー4(ポータル管理者がログインしてポータルをナビゲートし、ポー

タルのコンテンツを作成/編集する。詳細については前述のユーザー・フローの説

明を参照)

2.3

全体 2.3

iPadの結果

全体的な応答時間(秒)

ユーザー・フロー1(従業員ロールを持つユーザーがドキュメントを検索/閲覧する。

詳細については前述のユーザー・フローの説明を参照)

2.8

ユーザー・フロー2(ログインしていないユーザーがポータルをナビゲートし、ド

キュメントを検索/閲覧する。詳細については前述のユーザー・フローの説明を参

照)

2.3

ユーザー・フロー3(マネージャー・ロールを持つユーザーがログインしてポータ

ルをナビゲートし、ドキュメントを検索/閲覧する。詳細については前述のユー

ザー・フローの説明を参照)

2.5

ユーザー・フロー4(ポータル管理者がログインしてポータルをナビゲートし、ポー

タルのコンテンツを作成/編集する。詳細については前述のユーザー・フローの説

明を参照)

2.3

全体 2.5

Page 17: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

17

ユーザー・フローの測定値

以下の表に、前述のユーザー・フローに関わるさまざまな操作の測定値を示します。測定したのはサーバー側の応答時間のみです。

ユーザー・フロー1:認証済みコンテンツへのアクセス

以下の表に、ユーザー・フロー1で実行した操作の平均サーバー応答時間(秒)を示します。

平均サーバー応答時間(秒):

同時ユーザー数/管理対象サーバー数 200/1 400/2 800/4 1600/8

URL呼出し 0.49 0.55 0.56 0.83

ページにログイン 0.18 0.18 0.20 0.35

ログインを実行 0.52 0.60 0.63 0.96

ユーザーのLOBへ移動 0.81 0.90 0.93 1.43

ドキュメントを検索 1.44 1.51 1.61 2.07

ドキュメントを表示 0.68 0.72 0.73 1.02

閉じる 1.08 1.17 1.17 1.67

ユーザー・フロー2:パブリック・コンテンツへのアクセス

以下の表に、ユーザー・フロー2で実行した操作の平均サーバー応答時間(秒)を示します。

同時ユーザー数/管理対象サーバー数 200/1 400/2 800/4 1600/8

呼出し 0.50 0.52 0.57 0.84

ランダムなLOB選択 0.65 0.74 0.79 1.19

パブリック・ページ1にアクセス 0.38 0.42 0.46 0.74

ページ階層をランダムにナビゲート 0.38 0.44 0.47 0.72

ドキュメント検索 1.40 1.47 1.51 2.05

検索結果をクリック 0.63 0.67 0.68 0.99

ドキュメント表示ダイアログ・ボックスを閉じる 1.01 1.07 1.12 1.61

Page 18: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

18

ユーザー・フロー3:セキュアなコンテンツへのアクセス

以下の表に、ユーザー・フロー3で実行した操作の平均サーバー応答時間(秒)を示します。

同時ユーザー数/管理対象サーバー数 200/1 400/2 800/4 1600/8

URL呼出し 0.50 0.52 0.55 0.85

ページにログイン 0.17 0.21 0.20 0.38

ログインを実行 0.52 0.56 0.59 0.98

ランダムなLOBに移動 0.74 0.86 0.87 1.40

パブリック・ページ1 0.43 0.43 0.52 0.77

パブリック・ページ2 0.41 0.44 0.47 0.78

ユーザーのLOBに移動 1.49 1.61 1.66 2.56

従業員ページ1 0.43 0.51 0.55 0.88

従業員ページ2 0.43 0.50 0.56 0.88

マネージャー・ページ 0.50 0.57 0.59 0.88

ログアウト 0.84 0.92 0.99 1.64

Page 19: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

19

ユーザー・フロー4:管理者向けコンテンツへのアクセス

同時ユーザー数/管理対象サーバー数 200/1 400/2 800/4 1600/8

URL呼出し 0.48 0.52 0.52 0.8

ページにログイン 0.19 0.18 0.2 0.34

ログインを実行 0.51 0.56 0.59 0.96

ランダムなLOBに移動 0.8 0.85 0.88 1.37

パブリック・ページ1 0.42 0.43 0.52 0.76

パブリック・ページ2 0.43 0.44 0.46 0.8

ユーザーのLOBに移動 1.48 1.67 1.75 2.58

従業員ページ1 0.43 0.51 0.61 0.89

従業員ページ2 0.41 0.52 0.53 0.91

ユーザーのLOBホームに移動 0.65 0.73 0.77 1.16

ポータルを編集 0.89 1.03 1.06 1.67

新規ページ・リンク 0.8 0.9 1.05 1.24

空のテンプレートを使用 0.88 0.88 0.96 1.17

作成ボタンをクリック 7.14 7.07 6.87 8.29

ページを編集 2.38 2.51 2.34 2.98

コンテンツを追加 1.1 1.2 1.34 1.82

コンテンツ管理を開く 0.46 0.46 0.46 0.66

コンテンツ・プレゼンタを追加 0.52 0.54 0.54 0.82

コンテンツ追加ポップアップを閉じる 0.4 0.44 0.42 0.64

コンテンツ・プレゼンタを編集 0.79 0.81 0.84 1.15

コンテンツ・タブ 0.41 0.42 0.47 0.66

参照 0.54 0.56 0.55 0.87

1レベル上へ移動 0.47 0.45 0.47 0.69

moc1を開く 1.3 1.38 1.42 2.12

画像を開く 0.92 0.94 1.08 1.4

画像をクリック 1.2 1.25 1.42 1.94

画像を選択 0.72 0.78 1 1.24

コンテンツを保存 0.84 0.9 0.89 1.34

ページを保存 1.03 1.06 1.02 1.38

ドキュメント・タブ 1.33 1.52 1.54 2.39

ページをアップロード 0.29 0.3 0.31 0.56

ファイルを選択 0.05 0.07 0.07 0.12

ドキュメントをアップロード 0.67 0.69 0.68 1.03

ドキュメントをダウンロード 0.19 0.19 0.21 0.31

ログアウト 0.87 1.23 1.1 1.67

Page 20: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

20

サイジングに関するガイド

サイジングに関する以下のガイダンスは、このパフォーマンス・テストに基づいています。なお、これはあくまで参考情報であり、実際のサイジングはユースケースによって異なります。これらの数値や計算結果は、思考時間30秒、同時ユーザー数1,600として、WebCenter Portalのdot8リリースに対して前述のユースケースを実行した結果に基づいています。

サイジング要件 パラメータ名 サイジング値

コアあたりのポータルTPS PortalTPSPerCore 1.52(TPS/コア)

コアあたりの同時ユーザー数 UsersPerCore 66.65(ユーザー/コア)

コアあたりのメモリ量(GB) MemoryPerCore 7(GB/コア)

DBコア相当数 DBCoreRatio ポータルのコア1に対してDBのコア0.05

SESコア相当数 SESCoreRatio ポータルのコア1に対してSESのコア0.08

その他のコンポーネントのコア数 CompCoreRatio ポータルのコア1に対してその他のコンポーネントのコア0.02

例 - コンテンツの同時ユーザー数10,000のシナリオ(ピーク使用率20%)

以下の表に、ユーザー数が100,000の例を示します。アクティブなユーザーを全体の10%、ピーク使用率を20%と仮定しています。

サイジング要件 計算式 サイジング値

WebCenterのコア数 UsersPerCore/PortalTPSPerCore 180コア

WebCenterマシン台数 マシン1台あたり24コア 8台

マシン1台あたりのメモリ容量(GB) WCCores*MemoryPerCore/マシンの台数 170GB

DBのコア数 WCCores*DBCoreRatio 9コア

SESのコア数 WCCores*SESCoreRatio 14コア

コンポーネントのコア数 WCCores*CompCoreRatio 4コア

Page 21: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

21

結論

結果から以下のことが分かりました。

• TPSおよび1秒あたりのヒット数は、ユーザー数に比例して直線的に増加するパターンを示している。

• ユーザー・ロードの増加に伴いフルGCの平均実行時間は長くなるが、システムが不安定になることはない。

• ユーザー数の増加に伴い、平均応答時間を維持するために必要になる管理対象サーバー数も増加する。

Page 22: スケーラビリティとパフォーマンスOracle …. 1台の物理マシン上で4つのWebCenter Portalノード(管理対象サーバー)が稼働し、別の マシン上でさらに4つのWebCenter

スケーラビリティとパフォーマンス Oracle WebCenter® Portal 2015年6月 著者:Vihang Pathak、Shaun Lin 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