nakai norihisa
nakai****@yes*****
2007年 8月 10日 (金) 16:07:41 JST
TO:UltraMonkey-L7開発者の皆様 お世話になっております。 NTTコムウェアの中居です。 前回前々回と既存のUltraMonkey-L7の速度的な改良部分を説明させていただきま したが、新たに実装する機能としてQoSがありますので、QoSの説明をさせていた だきます。 必要と思われるQoSの要求条件は以下のものとなっています。 1) サービス単位でのひとつのclientの短時間あたりの通過量の設定 2) ひとつのserviceの単位時間あたりの通過量の設定 全体へのQoSの設定はserviceに設定されるQoSの合計値で決まります。 ここでのバランシング(*1)は今回考慮に入れません。 考え方は単純です。 まず、1)に関してはstruct l7vs_connに二つ、変数を導入します。 struct timeval recvtime; [1] size_t recvsize; [2] [1]は、recvしたときの時間、 [2]は、recvしたときのバイト数です。 これを実際にclientからrecv()するときに (1)現在の時刻をとる (2)保存されているrecvtimeとの差分を求める (3)これによりrecvsizeから(2)と(1)より単位時間あたりの通過量が求まる。 例) 前回のrecv()したときとの時間差が0.001secだった場合で前回1024byteを recvした場合にはこのときの1024000byte/secの通信量となる。 (4)指定されている制限値以上の場合には、recv()せずに次回のepoll_wait()で 反応するようにeventを設定し、終了する。 (5)制限値以下の場合にはrecv()を行い、[1]に(1)で求めたtimevalを、[2]に revv()したバイト数を入れる。 この実装が可能になったのは、複数回でのepoll_wait()での読み込みを可能とし たところが大きいです。 これでclient別の単純なQoSは解決できるとして2)のservice別のQoSに関しては l7vs_serviceに別途値を追加する必要があります。 同じようにrecvtimeとrecvsizeを追加し、clientのときと同じように、サーバー 別でもほとんど同じ処理を入れてやります。 この場合、client別の場合にはepoll_wait()一度あたり同じクライアントからは 一度しか現在時刻を取得しませんが、server別の場合には反応するclientの数だ け変数が参照及び書き換えられる結果になります。 ただし、timevalを取得する回数はepoll_wait()あたり、反応のあったconnの数 のみです。 QoSの機能としては必要最低限だと思われますが、コード量もあまり多くないた め、上記の実装といたしました。 以上簡単ながらQoSの実装を説明させていただきました。 どうぞよろしくお願いいたします。 (*1)全体でのバランシング設定 UltraMonkey全体の上限値を100Mbps、service1を50Mbps、service2を50Mbpsのよ うな設定を行い、service1の通信量が60Mbpsになった場合でもservice2が10Mbps だった場合に全体通信料が70Mbpsのため、service1のQoSは行わないような処理。
UltraMonkey-L7
Fork