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

2015年6月

スケーラビリティとパフォーマンス

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秒あたりのトランザクション数は、ユーザー数および管理対象サー バー数に比例して増加することが分かりました。また、平均サーバー応答時間は、ユーザー数が増え るほど増加しました。

3

変更履歴

バージョン 変更内容 0.1 2014 年 7 月の元のバージョン 最新バージョン サイジングに関する更新

対象範囲

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

4

ユースケース

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

5

 部門固有のサイト ユーザーが部門固有のサイトにナビゲートすると、メニュー・ナビゲーションとペー ジ・コンテンツが変化します。それぞれのLOBは独自のドキュメント・セットを所有 しますが、このドキュメント・セットはフォルダとサブフォルダに整理されます。 図2：部門ページ 権限を持つユーザーはサイトにコンテンツを投稿することができます。  イントラネット・ポータルの構造 o この会社には合計25の部門がある。 o イントラネット・ポータルは、部門あたり1,001ページで構成される。 o 各部門は独自のポータルを所有し、メイン・イントラネット・ポータルのナビゲーショ ン・モデルで表示される。 o 部門ポータルのどこからでもメイン・ポータルにナビゲートできる。 o 各部門にはホームページがあり、このページはイントラネットのランディング・ペー ジとは異なる。ホームページは異なるページとナビゲーションのセットで構成される。

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 部門ごとにホームページがありますが、それはイントラネット・ポータルのホームペー ジとは異なる。

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

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サーバー上で稼働する。

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

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'分 が経過するまでそのページで待機します。

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秒です。

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}"

<IfModule mpm worker module>

AcceptMutex fcntl

LockFile

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>

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秒あ たり のト ラン ザク ショ ン数

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秒あ たり のト ラン ザク ショ ン数（ TPS ） 平均応答 時間（秒）

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

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

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

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

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 コア

21

結論

結果から以下のことが分かりました。 • TPSおよび1秒あたりのヒット数は、ユーザー数に比例して直線的に増加するパターンを示 している。 • ユーザー・ロードの増加に伴いフルGCの平均実行時間は長くなるが、システムが不安定に なることはない。 • ユーザー数の増加に伴い、平均応答時間を維持するために必要になる管理対象サーバー数 も増加する。

スケーラビリティとパフォーマンス 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