Get Slide

過負荷時のWebアプリケーションの
性能劣化を改善する
Session-level Queue Scheduling
東京工業大学大学院情報理工学研究科
数理・計算科学専攻千葉研究室
松沼正浩指導教官:千葉滋
修士論文発表
1
セッション処理性能の重要性


消化セッション数がサイトの利益に直結
セッション処理とは？



複数のWebページを通して行う処理
例:ログインからログアウトまでの一連の処理
最後のページ(ログアウト)まで処理して完了
例：商用サイトの物品購入アプリケーション
セッション
ページ
ログ
イン
商品
検索
商品
決定
購入
送信
修士論文発表
ログ
アウト
2
過負荷時のセッション処理性能

リクエスト殺到時には増加比率以上に低下



10倍のリクエストで100分の1以下の性能になることも
一定の数を超えるとセッション処理性能がゼロになる場
合も
処理性能低下の原因は


リソース競合による各ページの処理性能の低下
途中失敗の増加によるセッション完了数の低下
殺到
ログイン空き状況観戦予約
購入完了
修士論文発表
成功
3
原因1:ページ処理性能の低下

リクエスト殺到時にページ処理性能が低下

計算リソースが競合するため

重いページの並列処理によりリソースが不足


競合にともなう余計な処理増加


大規模アプリケーションが増加傾向
例:メモリ競合によりGC,スワップイン・アウト増加
各ページのリソース競合を解消する必要

ページ処理性能が低下すると、集合体である
セッションの処理性能も低下
修士論文発表
4
原因2:セッションの途中失敗

過負荷時にセッションが途中失敗する可能性大

ページの処理失敗が原因

サーバタイムアウトやブラウザタイムアウト


ユーザが待ちきれずにリクエストを中止


11秒以上待たされるとイライラを感じる[Jakob’02]
ページの数だけ失敗する危険性も高まる


Safari 1.2.3で1分、Mozilla系ブラウザでは2分
重要な処理ほどセッションが長くなる[Cherkasova’98]
セッションの途中失敗を抑制する必要

途中で失敗するとそれまでの処理が全て無駄になる
修士論文発表
5
Session-level Queue Scheduling
の提案


ページ単位制御とセッション単位制
御の両方を連動
ユーザの挙動を考慮したスケ
ジューリング

シンクタイム


次のページに移動するまでの時間
ページページページ
スケジューラ
スケジューラ
スケジューラ
タイムアウト


セッション
スケジューラ
一定時間以内にレスポンスが得られない
場合にリクエストを中断
途中退場

正規手続きを踏まずに途中でセッション
処理を中断
修士論文発表
6
ページスケジューラ

ページ単位で並列度を設定してリソース競合を解消



リソース競合を起こさない最大の並列度を動的に決定
並列度をこえるリクエストはページキューで待機させる
並列度は各ページの進捗状況により決定

Progress-based Regulation [Douceur’99] を応用


進捗が悪化しているとリソース競合を起こしていると判定
個別のリソースを監視する必要はない
進捗状況を
フィードバック
リクエストページスケジューラ
３
クライアント
ページキュー
並列制御処理実行
進捗測定
7
セッションスケジューラ

同時に処理するセッション数を制御

同時セッション数の動的な決定


ページスケジューラからの情報を利用
ページキューの長さを一定に保つ




キューの長さを
フィードバック
セッション
キュー
セッションスケジューラ
キューが長い：途中失敗の可能性大
キューが短い：リソース使用の効率低下
制御はセッション参加時の1回のみ
許可を得られるまで、リクエストはセッ
ションキューで待機させる
修士論文発表
ページ
スケジューラ
8
セッションスケジューラによる
同時セッション数の制御方法

リクエストの投入間隔(遅延)を制御



長くすれば、同時セッション数が減少
短くすれば、同時セッション数が増加
全てのページキューの長さを監視し遅延を変化

待機リクエスト数の総和が多い＝ページキューが長い


同時セッション数が多すぎると判断し、遅延を長くする
待機リクエスト数の総和が少ない＝ページキューが短い

同時セッション数が少なすぎると判断し、遅延を短くする
修士論文発表
9
プロトタイプ実装


Tomcat上にて実装
単純なアルゴリズムを用いて効果を検証

ページ単位の並列度の決定


各ページのスループットを進捗とした
セッション開始の時間的遅れの決定


セッション開始時に次回の遅延を変更
ページキューの平均長を算出し、しきい値と比較

しきい値以上なら間隔を長くし、以下なら間隔を短くする
修士論文発表
10
性能比較実験


同時クライアント数を変動させセッション処理性能を測定
対象アプリケーション

1.login
30ms

商品購入アプリケーションに見立てたServlet群
２.閲覧
30ms
3.閲覧
30ms
4.閲覧
30ms
5.商品検索
400ms
6.購入
30ms
７.logout
30ms
クライアントの挙動



シンクタイム:一定時間が経過した後で次のページに移動
タイムアウト:リクエストを送ってから一定時間応答がなければリ
クエストを破棄
リトライ:途中失敗した場合は最初から
修士論文発表
11
比較対象


制御なし
ページスケジューラのみ使用


セッションを保護しない
セッション参加人数を固定(1or30)


途中失敗しない(1)
競合するがシンクタイムを有効利用する(30)
サーバ CPU：Intel Xeon 2.40GHz×2 メモリ：2GB OS：
Linux2.4.2ギガビットイーサネット WebAppサーバ:Tomcat3.3.1
クライアント CPU：Intel Xeon 3.06GHz メモリ：2GB OS：
Linux2.6.8 ギガビットイーサネット
修士論文発表
12
タイムアウトがない場合の性能
スループット[sessions/sec]
3
ページスケジューラが
リソース競合解消
2.5
本手法
制御なし
ページ単位
1セッション
30セッション
2
1.5
シンクタイム3秒
タイムアウト無制限
1
処理が逐次的
0.5
タイムアウト1分
シンクタイム3秒
0
0
100
200
クライアント数
300
400
13
タイムアウトが1分の場合の
性能
3
本手法
制御なし
ページ単位
1セッション
30セッション
スループット[sessions/sec]
過負荷時でも性能維持
2.5
2
1.5
途中から急激に
性能が低下
1
シンクタイム3秒
タイムアウト1分
0.5
0
0
100
200
クライアント数
300
400
14
レスポンスタイム
(125クライアント)
タイムアウト1分
シンクタイム3秒
50
制御なし
ページ単位
本手法
ページ単位・本手法とも
レスポンスタイムに関しても向上
30
20
10
経過時間 [sec]
24
0
22
0
20
0
18
0
16
0
14
0
12
0
10
0
80
60
40
20
0
0
クライアント数
40
15
レスポンスタイム
(400クライアント)
タイムアウト1分
シンクタイム3秒
35
ページ単位
本手法
30
本手法のレスポンスタイムは
クライアント殺到時でも高性能
20
15
10
経過時間 [sec]
700
680
660
640
620
600
560
540
490
420
390
350
280
220
200
180
160
140
120
100
80
60
40
0
20
5
0
クライアント数
25
16
セッションの途中失敗数
失敗セッション数
1000
900
本手法
制御なし
ページ単位
1セッション
30セッション
失敗の内訳
800
700
600
500
400
急激に失敗数が増加
シンクタイム3秒
タイムアウト1分
ほぼ同比率で増加
300
200
100
0
0
100
200
クライアント数
300
400
17
失敗したページの内訳
クライアント数125の時の失敗数の内訳
ページ番号
1ページ
2~4ページ
5ページ
6~7ページ
制御無し
０
３
１５０
150
０
ページ単位
本手法
０
０
０
０
０
０
０
０
クライアント数400の時の失敗数の内訳
本手法を用いない場合は、重い処理を
ページ番号
1ページ 2~4ページ 5ページ 6~7ページ
行っているページで起きている
本手法を用いた場合には、セッション失敗は
制御無し
ー
ー
ー
ー
全てセッションの先頭ページでのみ発生した
ページ単位
０
０
７３５
０
735
18
226
本手法
２２６
０
０
０
スケジューラの挙動の時間変化
セッションスケジューラの挙動
30
ページスケジューラの挙動
400
3.5
ページキュー
ページ5用並列度
350
25
3
セッション間隔
ページ1用並列度
250
15
200
2.5
並列度
20
セッション間隔 [msec]
ページキューの長さ
300
2
1.5
キューが長くなると
1
セッション間隔が伸びる
制御すべきページの並列度
0.5
が頻繁に変動
150
10
100
5
50
0
0
0
20
43
68
94
122
経過時間 [sec]
151
184
200
0
0
50
経過時間 [sec]
100
19
タイムアウトを短縮 (1分→30秒)
3
スループット[sessions/sec]
高い処理性能を依然維持することができた
2.5
2
本手法
制御なし
ページ単位
1セッション
30セッション
1.5
シンクタイム3秒
タイムアウト30秒
1
0.5
より少ないクライアント数でも
タイムアウトが発生する
0
0
100
200
クライアント数
300
400
20
シンクタイムを短縮 (3秒→1秒)
スループット[sessions/sec]
3
本手法
制御なし
ページ単位
1セッション
30セッション
2.5
2
1.5
1
シンクタイムの長さは性能
にあまり影響を与えない
0.5
シンクタイム1秒
タイムアウト1分
0
0
100
200
クライアント数
300
400
21
関連研究

Application-aware admission Control
[Carlstorm’02]



ページ単位制御、セッション単位制御の組み合わせ
それぞれが個別に動作
SEDA Architecture[Welsh’03]

リクエスト処理をステージに分割して負荷を制御



より細かいリソース管理を実現
ページスケジューラと直交する
ハートビート


通信にタグを埋め込み
ブラウザのタイムアウトの抑制
修士論文発表
22
まとめ

Session-level Queue Scheduling[DSW’05]を提案


ページスケジューラ[SPA’04]とセッションスケジューラを連動
させることで過負荷時のセッション処理性能を向上・維持
プロトタイプ実装を用いた実験により有効性を示した

ユーザの複雑な挙動を考慮したモデルを使用した性能比較


シンクタイム・タイムアウト・リトライを考慮
過負荷時においても一定のセッション処理性能を維持

単純なアルゴリズムでも効果あり
修士論文発表
23
今後の課題

より複雑なユーザの挙動を考慮したモデ
ルで対応できるかの確認
修士論文発表
24

Download Report