Hideaki Kondo
kondo****@oss*****
2008年 8月 25日 (月) 17:44:05 JST
田沼さま、各位 近藤です。 お疲れ様です。 追加検討情報有難うございます。 > 1. 現在の QoS 上りの問題点と修正 > 2. 現在の l7vsadm で出力されるスループットの問題点と修正 修正案、採用案等内容をざっと確認しました。 上記どちらについても、今のところ特に大きく 問題となりそうな修正箇所は見当たらないので、 田沼さんの採用案・修正内容で良いと考えます。 On Mon, 25 Aug 2008 14:21:36 +0900 Kouhei TANUMA <tanum****@nttco*****> wrote: > UltraMonkey-L7開発者の皆様 > > 田沼です。 > > 2 点ほど追加です。 > > > 1. 現在の QoS 上りの問題点と修正 > 2. 現在の l7vsadm で出力されるスループットの問題点と修正 > > > ■ 1. 現在の QoS 上りの問題点と修正 > > ▼ 問題点 > > QoS は、VirtualService 単位に設定するため、クライアントからの通信が > どの VirtualService 宛であるか判断できるまで、制限をかけることが > できません。 > 次に、どの VirtualService 宛であるか判断するまでのフローとしては、 > クライアントのデータを全て受信→判断という流れになっています。 > そのため、データを全て受信するまでは、上りの帯域制御はかからない > ことになります。（問題1） > また、クライアントから 1GB のデータ送信があった場合、UltraMonkey-L7 で > 1GB 全て溜め込むことになります。（問題2） > この場合に、どこで上りの帯域制御されるかというと、HTTP の > KeepAlive 時などサーバから返答を受けた後に、同一コネクションを使った > クライアントからの通信が制御対象になります。 > > また、「クライアントのデータを全て受信」と書きましたが、 > クライアントからのデータがそれで全てと、どのように判断しているか > というと、現在は epoll_wait で反応した FD から 20480 バイト > (L7VS_CONN_READ_BUFSIZE) 読み込み、20480 バイト未満しかデータが > なかったら、それで全てと判断しています。（問題3） > つまり、クライアントからのデータ転送速度が epoll_wait でバッファから > 読むスピードよりも遅くなった場合、そこでクライアントからのデータは > 終わりとみなしています。（CD-R のバッファアンダーランに似てます） > > > ▼ 修正案 > > 修正についてですが、まずクライアントのデータをどこまで読んで、 > VirtualService を判断するかについて検討します。 > > 考えた修正は、以下の 2 点です。 > > 1. VirtualService を決定できる段階（Cookie文字列がみつかった等）に > なるまで受信し続ける > 2. 最初の 20480 バイトの読み出しのみで判断する > > 1. の場合、受信の度に VirtualService 決定可能か確認するため明らかに > 性能が落ちると考えます。また、VirtualService を決定できるかどうか > 調べる関数が各プロトコルモジュールに必要になりそうです。 > また、最後まで VirtualService を決定できる文字列等が > 見つからなかった場合、タイムアウト処理等を入れる必要があります。 > ただし（問題3）は解決されます。 > > 2. の場合、20480 バイト内に VirtualService を決定できる情報が > 入っている確証はありません。また、クライアントの転送速度が > 遅いため、本来 20000 バイトあるクライアントデータが 10 バイトしか > 読まれない可能性もあります。 > ただし（問題1）（問題2）は解決されます。 > > > ▼ 採用案 > > 2. 最初の 20480 バイトの読み出しのみで判断する > > 1. は変更点が多く、（問題1）（問題2）も改善されない場合がある。 > これに対して 2. の場合、既存のコードの修正点は極小であり、 > 20480 バイト内に VirtualService を決定できる情報がない可能性に > ついても、現在のプロトコルモジュールでは、20480 バイト以内に > VirtualService を決定できる情報がまず間違いなく入っている。 > さらに 20480 バイトという値は設定ファイルに切り出すことが容易で > あるため、チューニングによる最適化ができる。 > > > ▼ 修正内容 > > ・conn での recv を最初の一回のみにし、続きがあるなどの判定を > しない > ・L7VS_CONN_READ_BUFSIZE を設定ファイルに切り出す > > > ■ 2. 現在の l7vsadm で出力されるスループットの問題点と修正 > > ▼ 問題点 > > ・1. の（問題1）の影響もあり、ほとんどの場合で 0 と出力される > ・前のメールにも記述したとおり、多少のトラフィックでも epoll_wait > のループ速度が速すぎるため、膨大なスループットとして出力される > ・トラフィックが終了した後も、直前のスループットが残り続ける > > ▼ 修正内容 > > ・前のメールの type2 の考え方で、任意の時間帯でスループットを計算する > ・l7vsadm で出力要求された時間帯のひとつ前の時間帯のスループットを > 出力する > （現在の時間帯のスループットは、徐々に増加していくため不安定） > > > > 以上、五月雨なメールで申し訳ありませんが、ご確認下さい。 > 以上よろしくお願い致します。 -- Hideaki Kondo（近藤 秀明）
UltraMonkey-L7
Fork