Transcript 過負荷時の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