過負荷時のWebアプリケーションの 性能劣化を改善する Page-level Queue Scheduling 東京工業大学　千葉研究室 松沼正浩　千葉滋 　 佐藤芳樹　光来健一

Webアプリケーションの推移 今までは軽いアプリケーションが主体 現在、重いアプリケーションが増加している 静的なページや、せいぜい単純なCGI 現在、重いアプリケーションが増加している J2EE技術の普及 →　大量にリソースを消費するページが増加中 今後も増え続けると推測 ページ：　静的なもの・・・HTMLなど 　　　　　　動的なもの・・・ServletやJSPなどで生成されるもの

現在のWebアプリケーションサーバ 処理性能を向上させるために、リクエストを並列に処理する アプリケーションの大規模化 軽いページを想定 余剰リソースの効果的な使用 アプリケーションの大規模化 並列処理することで、リソースの競合が発生 メモリ資源を競合すると、GCなどの発生で性能劣化

並列処理による性能向上 軽いページは並列度が高いほど性能が向上 性能向上 総処理時間(ms) リクエスト数 サーバ(Solaris8) ： UltraSPARCⅢ750MHz×2, 1GB クライアント(Linux) : PenIII 733 x 15台, 512MB ネットワーク : 100BASE-TX 対象アプリケーション：fib計算 性能向上 リクエスト数

並列処理による性能劣化 重いページを並列処理するとリソース競合が発生する可能性がある 性能低下 総処理時間(ms) リクエスト数 サーバ(Solaris8) ： UltraSPARCⅢ750MHz×2, 1GB クライアント(Linux) : PenIII 733 x 15台, 512MB ネットワーク : 100BASE-TX 対象アプリケーション： XMLパース、データ検索 性能低下 リクエスト数

最適な並列度の決定は困難 しかし、以上の話は氷山の一角 考慮すべきこと 重いページや軽いページが混在 ページ毎に最適な並列度が異なる 使用リソースが多岐にわたる ページ間でリソース競合 OSのスケジューラの仕事の外 OSはページの処理内容を認識できない

Page-level Queue Schedulingの提案 ページ毎にスケジューラを用意 並列度をページ毎に独立して制御 Progress-based regulation を応用 リソース競合の判定 進捗状況を フィードバック 2 最大並列度　の制御 ページA リクエスト 3 ページB

ページ毎にスケジューラを独立 ページの差を考慮したスケジューリング可能 最大並列度を個別に制御 制御のためにページ毎にキューを用意 3 重いページには低い並列度を、 軽いページには高い並列度を与えられる OSのスケジューラに依存しない 制御のためにページ毎にキューを用意 最大並列度を超えたら、リクエストをキューイング 優先クライアントの設定が容易 3

Progress-based regulation リソースの種類に関わらず競合の影響はページ生成の進捗に現れる プロセスの進捗状況に応じてリソース割り当てを動的に変更するスケジューリング手法 [SOSP’01] 実行しながらページの進捗を測定 環境の変動をリアルタイムに取得 進捗状況の悪化から、リソース競合を判定 あらゆるリソース変動はページ毎の進捗で判定可能 ページ間の干渉も検出可能

最大並列度の小さな方が、スループットが高いと判断 最大並列度の動的な決定 Mc : 現在の最大並列度 Mp : 前回の最大並列度 Tc : Mcでのスループット Tp : Mpでのスループット スループットを測定 指定した回数のデータを　　　　　　　　　　　採取できたか？ No 　　最大並列度の小さな方が、スループットが高いと判断 Yes No (Tc–Tp) / (Mc-Mp)≧0 最大並列度の大きな方が、スループットが高いと判断 Yes 最大並列度を⊿k 増加 最大並列度を⊿k 減少

実験 リソース競合の判定、並列度制御の効果を測定 優先クライアントの処理性能の測定 単一ページだけのフィードバック制御の効果を測定 実験環境 ページ間の干渉を減少できるか 軽いページと重いページを同時に動かして、その影響を測定 実験環境 サーバ　CPU：UltraSPARCⅢ750MHz×2　　　　　　　　　　　　 　　　　　　 メモリ：1024MB　OS：Solaris8　NIC：100BaseTX クライアント15台 CPU：Pentium 733MHz　NIC：100BaseTX 　 メモリ：512MB　OS：Linux2.4.19-Ovl11(VineLinux)

重いページの性能改善 ページ内で発生する競合を検知し解消 処理性能が約30%程度向上 対象ページ 34KB程度のXMLファイルをパースしてデータ検索を行うページ 総処理時間(ms) 性能向上 リクエスト数

クライアントの優先度設定 キューの中身を入れ替えれば、簡単に処理順序の変更が可能 セッション処理などで既に開始済みのクライアントの処理を優先することが可能 セッション処理開始者を優先的に処理することで、効率良くクライアント数を減らしていける

優先度設定による レスポンス時間の短縮 最低 最高 平均 実験方法 対象ページ 実験結果 本手法 なし 優先権 あり 対象ページを常時50リクエスト処理している状況下で、優先度の有無による比較 対象ページ XMLファイルをパースしてデータ検索を行うページ 実験結果 レスポンスが平均で約30分の1程度に短縮 本手法 なし 優先権 あり 最低 41,260 　　(ms) 25,550 1,730 最高 26,370 23,060 640 平均 37,500 24,540 1,140

ページが混在する際の制御 ページ間の干渉の検知し解消できるかを検証 実験方法 軽いページへ30クライアント 重いページへ80クライアント 単純なHTML作成ページ 重いページへ80クライアント XMLファイルをパースし、データ検索を行う 10ms間隔で処理数を測定 重いページは、軽いページの処理が開始されてから10秒後に開始

Page-level Queue Schedulingを使用しない場合 処理リクエスト数 処理リクエスト数 軽いページ 重いページ 重いページの処理開始 重いページの処理開始 経過時間(ms) 経過時間(ms) 重いページの処理により、軽いページの処理が滞っている。

Page-level Queue Schedulingを使用した場合 処理リクエスト数 処理リクエスト数 軽いページ 重いページ 重いページの処理開始 重いページの処理開始 経過時間(ms) 経過時間(ms) 軽いページの処理が滞らない。

関連研究 Haboob しかし、ページ毎の制御はサポートされていない SEDA (Staged Event-Driven Architecture)に基づいたHttpServer リクエスト処理をいくつかのステージに分ける 例：HttpParse, PageCache, etc ボトルネックステージを発見し、リソースの優先割り当てやリクエストの破棄を行う しかし、ページ毎の制御はサポートされていない

まとめ Page-level Queue Schedlulingの提案 ページ単位で動的に並列度を制限 リソース競合の判定は、一つのページの進捗だけを見ることでも十分検知できる クライアントに優先度を設定できる 実験より、重いページと軽いページが混在して状況でも軽いページのレスポンスを一定量保てる

今後の課題 より現実的なケースでの実験 制御アルゴリズムの強化 今回は提案している手法の有効性を検証するために単純なケースで実験 現在の実装では、自身のページ性能を上げるためにスケジューラ間で余剰リソースを取り合う ページ間のリソース管理を強化