子ページ
  • IdPClusteringPerformance

比較バージョン

キー

  • この行は追加されました。
  • この行は削除されました。
  • 書式設定が変更されました。

...

- 目次 -
1. はじめに
1.1. 目的
1.2. 比較する Shibboleth-IdP冗長化方式
1.3. 検証環境の構成
2. パフォーマンスの測定方法
2.1. クライアント環境
2.2. ロードバランシング
2.3. 内容
3. ツールと使用データ
3.1. 測定ツール
3.2. テストデータ
4. テスト
4.1. テスト内容
4.2. テスト結果
5. パフォーマンス測定結果
5.1. Terracotta方式
5.1.1. パターン1(2スレッド×1000回)
5.1.2. パターン2(10スレッド×200回)
5.1.3. パターン3(20スレッド×200回)
5.2. memcached方式
5.2.1. パターン1(2スレッド×1000回)
5.2.2. パターン2(10スレッド×200回)
5.2.3. パターン3(20スレッド×200回)
5.3. repcached方式
5.3.1. パターン1(2スレッド×1000回)
5.3.2. パターン2(10スレッド×200回)
5.3.3. パターン3(20スレッド×200回)
5.4. IdP Stateless Clustering方式
5.4.1. パターン1(2スレッド×1000回)
5.4.2. パターン2(10スレッド×200回)
5.4.3. パターン3(20スレッド×200回)
5.5. 測定値の平均
6. 考察

アンカー
_1._はじめに
_1._はじめに

アンカー
_Toc315862082
_Toc315862082
1. はじめに

アンカー
_Toc315862083
_Toc315862083
1.1. 目的

本書は、冗長化したShibboleth-IdPのパフォーマンス計測の結果報告書です。
本書にてパフォーマンス計測のシステム構成と計測内容、計測結果を記載します。

アンカー
_Toc315862084
_Toc315862084

...

1.2. 比較する Shibboleth-IdP冗長化方式

パフォーマンス計測の対象となる冗長化方式は下記とします。

  • アンカー
    _Ref272941422
    _Ref272941422
    Terracotta方式
  • memcached方式(No Replication)
    • 認証情報は、ログインしたtomcatと設定された各memcachedサーバーに認証情報を分割し振り分けて保管する。memcachedの方系がダウンした場合は、ログインしたことのあるサーバーへのアクセスではtomcatに認証情報が残っていれば、再認証は求められない。しかし、ログインしていないサーバーへのアクセス、もしくは、tomcatに認証情報が残っていない状態でのアクセスでは、再認証が求められる。
    • 参考ページ
      https://wiki.shibboleth.net/confluence/display/SHIB2/Memcached+StorageService
  • repcached方式(replication)
  • IdP Stateless Clustering方式

アンカー
_Toc315862085
_Toc315862085
1.3. 検証環境の構成

 本試験における検証環境は下記に記すサーバーにて計測する。各サーバーのスペックは以下に示します。

アンカー
_Ref314672322
_Ref314672322
表 1-1 検証に使用したサーバー一覧

No

サーバー

環境

SP & 負荷テストツール

OS : CentOS 5.7 64bit
CPU : Intel Xeon 2.27GHz
Memory : 2GB

No2~No7 は 同一サーバーにて VMware で動作。

IdP Terracotta 1、LDAP

 

IdP Terracotta 2

 

IdP memcached 1、LDAP
repcached  1

 

IdP memcached 2、repcached  2

 

IdP StatelessClustering 1 & LDAP

 

IdP StatelessClustering 2

 


表 1-2 各検証に使用したソフトウェアのバージョン

No

ソフトウェア

バージョン

対象サーバー

備考

1

Apache HTTP Server

2.2.3

1,2,3,4,5,6,7

 

2

Shibboleth-SP

2.4.3-2.2

1

 

3

Shibboleth-IdP

2.3.5

2,3,4,5,6,7

 

4

memcached

1.4.10

4,5

メモリーの割り当ては512MB

5

repcached

2.2

4,5

メモリーの割り当ては512MB
repcached に使われている
memcachedのバージョンは1.2.8

6

Osuidpext

1.1

6,7

Stateless Clustering用ライブラリ

7

Terracotta

3.6.0

2,3

 

8

JDK

1.6.0_30

2,3,4,5,6,7

 

9

Apache Tomcat

7.0.23

2,3,4,5,6,7

 

10

OpenLDAP

2.3.43

2,4,6

各IdPサーバーの1台に構築

対象サーバーに記述する値は、表 1 1 検証に使用したサーバー一覧 に記載するNoです。


アンカー
_Toc315862086
_Toc315862086
2. パフォーマンスの測定方法

アンカー
_Toc315862087
_Toc315862087
2.1. クライアント環境

  • 検証環境と同一ネットワーク内にあるSPサーバーに負荷テストツールを置き、各計測対象サーバーへ負荷をかけてパフォーマンスを測定します。


アンカー
_Toc315862088
_Toc315862088
2.2. ロードバランシング

  • 冗長化した各サーバーへのロードバランシングは、計測対象ではない冗長化方式のサーバーにApacheモジュールのmod_proxy_balancer を使いリクエスト毎に分散する方式とします。


アンカー
_Toc315862089
_Toc315862089
2.3. 内容

  • 負荷テストツールを使い、下記のパターンでの測定を行います。
    • パターン1:  2スレッド×1000回
    • パターン2:  10スレッド×200回
    • パターン3:  20スレッド×200回
  • 助走期間として、各測定前に1分程度負荷ツールを実行します。
  • Teracottaのみ各測定後に再起動を実施します。
  • 計測は、1認証処理にかかる時間、および1秒間の認証処理回数を計測します。
  • スレッドは毎アクセス新しいセッションを張る方法で行います。(常に認証処理が走る)
  • 認証に利用するアカウントはひとつとします。


アンカー
_Toc315862090
_Toc315862090
3. ツールと使用データ

アンカー
_Toc315862091
_Toc315862091
3.1. 測定ツール

アンカー
_Toc315862092
_Toc315862092
3.2. テストデータ

アンカー
_Toc315862093
_Toc315862093
4. テスト

アンカー
_Toc315862094
_Toc315862094
4.1. テスト内容

各方式で冗長化構成が機能することを確認するテスト内容を下記に示します。

テスト1

それぞれのサーバーについて、テストアカウントで認証できること、および認証結果がSPへ送信されること

テスト2

一方のサーバーで認証後、他方のサーバーに認証要求を送った場合、認証済みとして正常に処理されること

テスト3

未認証の状態で一方のサーバーでパスワード要求画面(いわゆるログイン画面)を表示した後、他方のサーバーにその応答を送った場合、正常に処理されること ※1

※1 ブラウザによっては、ログイン画面を表示したサーバーのDNSがキャッシュされるため、他方のサーバーへ送信しようとしても、ログイン画面を表示したサーバーに応答を送ってしまいます。
Firefox9、IE9では、DNSをキャッシュし、Chrome16ではDNSをキャッシュしませんでした。

今回は、ログイン画面を表示後にブラウザのDNSキャッシュをクリアしてから、他方のサーバーに応答を送る手順で行っています。
また、今回のテストでは、DNSサーバーを用いずに、hostsファイルでサーバーの切り替えを行っています。



アンカー
_Toc315862095
_Toc315862095
4.2. テスト結果

各方式でのテスト結果を下記に示します。
表 4-1 テスト結果

 

方式

テスト内容

 

 

 

テスト1

テスト2

テスト3

Terracotta

memcached

×

Stateless Clustering

×

...