過負荷時のWebアプリケーションの性能劣化を改善する Page

過負荷時のWebアプリケーションの
性能劣化を改善する
Page-level Queue Scheduling
東京工業大学千葉研究室
松沼正浩千葉滋
佐藤芳樹光来健一
1
Webアプリケーションの推移

今までは軽いアプリケーションが主体


静的なページや、せいぜい単純なCGI
現在、重いアプリケーションが増加している


J2EE技術の普及
→ 大量にリソースを消費するページが増加中
今後も増え続けると推測
ページ：静的なもの・・・HTMLなど
動的なもの・・・ServletやJSPなどで生成されるもの
2
現在のWebアプリケーションサーバ

処理性能を向上させるために、リクエストを並
列に処理する



軽いページを想定
余剰リソースの効果的な使用
アプリケーションの大規模化

並列処理することで、リソースの競合が発生

メモリ資源を競合すると、GCなどの発生で性能劣化
3
並列処理による性能向上

軽いページは並列度が高いほど性能が向上
並列処理
総処理時間(ms)
8000
逐次処理
サーバ(Solaris8) ： UltraSPARCⅢ750MHz×2, 1GB
クライアント(Linux) : PenIII 733 x 15台, 512MB
ネットワーク : 100BASE-TX
対象アプリケーション：fib計算
7000
6000
5000
4000
性能向上
3000
2000
1000
リクエスト数
0
0
10
20
30
40
50
4
並列処理による性能劣化

重いページを並列処理するとリソース競合が発生す
る可能性がある
並列処理
総処理時間(ms)
35000
30000
25000
20000
逐次処理
サーバ(Solaris8) ： UltraSPARCⅢ750MHz×2, 1GB
クライアント(Linux) : PenIII 733 x 15台, 512MB
ネットワーク : 100BASE-TX
対象アプリケーション：
XMLパース、データ検索
15000
性能低下
10000
5000
リクエスト数
0
0
10
20
30
40
50
5
最適な並列度の決定は困難


しかし、以上の話は氷山の一角
考慮すべきこと





重いページや軽いページが混在
ページ毎に最適な並列度が異なる
使用リソースが多岐にわたる
ページ間でリソース競合
OSのスケジューラの仕事の外

OSはページの処理内容を認識できない
6
Page-level Queue Schedulingの提案

ページ毎にスケジューラを用意


並列度をページ毎に独立して制御
Progress-based regulation を応用

リソース競合の判定
進捗状況を
フィードバック
2
最大並列度
の制御
ページA
リクエスト
3
ページB
7
ページ毎にスケジューラを独立

ページの差を考慮したスケジューリング可能

最大並列度を個別に制御


重いページには低い並列度を、
軽いページには高い並列度を与えられる
OSのスケジューラに依存しない
3

制御のためにページ毎にキューを用意


最大並列度を超えたら、リクエストをキューイング
優先クライアントの設定が容易
8
Progress-based regulation

リソースの種類に関わらず競合の影響は
ページ生成の進捗に現れる

プロセスの進捗状況に応じてリソース割り当てを動
的に変更するスケジューリング手法 [SOSP’01]
実行しながらページの進捗を測定



環境の変動をリアルタイムに取得
進捗状況の悪化から、リソース競合を判定


あらゆるリソース変動はページ毎の進捗で判定可能
ページ間の干渉も検出可能
9
最大並列度の動的な決定
Mc : 現在の最大並列度
Mp : 前回の最大並列度
スループットを測定
Tc : Mcでのスループット
指定した回数のデータを
採取できたか？
Tp : Mpでのスループット
No
最大並列度の小さな方が、
スループットが高いと判断
Yes
No
(Tc–Tp) / (Mc-Mp)≧0
最大並列度
の大きな方
が、スルー
プットが高い
と判断
Yes
最大並列度を⊿k 増加
最大並列度を⊿k 減少
10
実験



リソース競合の判定、並列度制御の効果を測定
優先クライアントの処理性能の測定
単一ページだけのフィードバック制御の効果を測定



ページ間の干渉を減少できるか
軽いページと重いページを同時に動かして、その影響を測定
実験環境


サーバ CPU：UltraSPARCⅢ750MHz×2
メモリ：1024MB OS：Solaris8 NIC：100BaseTX
クライアント15台 CPU：Pentium 733MHz NIC：100BaseTX
メモリ：512MB OS：Linux2.4.19-Ovl11(VineLinux)
11
重いページの性能改善



ページ内で発生する競
合を検知し解消
処理性能が約30%程
度向上
対象ページ

本手法使用
本手法不使用
総処理時間(ms)
35000
30000
性能向上
25000
20000
15000
34KB程度のXMLファイ
ルをパースしてデータ検 10000
5000
索を行うページ
リクエスト数
0
0
10
20
30
40
50
12
クライアントの優先度設定


キューの中身を入れ替えれば、簡単に処理
順序の変更が可能
セッション処理などで既に開始済みのクライ
アントの処理を優先することが可能

セッション処理開始者を優先的に処理することで、
効率良くクライアント数を減らしていける
13
優先度設定による
レスポンス時間の短縮

実験方法


対象ページ


対象ページを常時50リクエス
ト処理している状況下で、優
先度の有無による比較
XMLファイルをパースして
データ検索を行うページ
実験結果

レスポンスが平均で約30分
の1程度に短縮
本手法優先権優先権
なし
なし
あり
最低
41,260
(ms)
25,550
(ms)
1,730
(ms)
最高
26,370
(ms)
23,060
(ms)
640
(ms)
平均
37,500
(ms)
24,540
(ms)
1,140
(ms)
14
ページが混在する際の制御


ページ間の干渉の検知し解消できるかを検証
実験方法

軽いページへ30クライアント


重いページへ80クライアント



単純なHTML作成ページ
XMLファイルをパースし、データ検索を行う
10ms間隔で処理数を測定
重いページは、軽いページの処理が開始されてから10秒
後に開始
15
Page-level Queue Schedulingを使用
しない場合
処理リクエスト数

処理リクエスト数
軽いページ
重いページの処理開始
重いページ
重いページの処理開始
経過時間(ms)
経過時間(ms)
重いページの処理により、軽いページの処理が滞っ
ている。
16
Page-level Queue Schedulingを使用
した場合
処理リクエスト数

処理リクエスト数
軽いページ
重いページの処理開始
重いページ
重いページの処理開始
経過時間(ms)
経過時間(ms)
軽いページの処理が滞らない。
17
関連研究

Haboob

SEDA (Staged Event-Driven Architecture)に基づいた
HttpServer



リクエスト処理をいくつかのステージに分ける
例：HttpParse, PageCache, etc
ボトルネックステージを発見し、リソースの優先割り当てやリクエ
ストの破棄を行う
しかし、ページ毎の制御はサポートされていない
18
まとめ

Page-level Queue Schedlulingの提案




ページ単位で動的に並列度を制限
リソース競合の判定は、一つのページの進捗だ
けを見ることでも十分検知できる
クライアントに優先度を設定できる
実験より、重いページと軽いページが混在して状
況でも軽いページのレスポンスを一定量保てる
19
今後の課題

より現実的なケースでの実験


今回は提案している手法の有効性を検証するた
めに単純なケースで実験
制御アルゴリズムの強化


現在の実装では、自身のページ性能を上げるた
めにスケジューラ間で余剰リソースを取り合う
ページ間のリソース管理を強化
20

Download Report