過負荷時の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
© Copyright 2024 ExpyDoc