From n.nakai ＠ sdy.co.jp Tue Aug 26 02:04:23 2008 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Tue, 26 Aug 2008 02:04:23 +0900 Subject: [Ultramonkey-l7-develop 189] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> Message-ID: <20080826020423.e4ca6044.n.nakai@sdy.co.jp> 中居です。 お疲れ様です。 下記件において一つ質問させてください。 keepalive onの場合のプロトコルモジュールの動作はどのようになるでしょう? HTTP1.1のRFCには連続してHTTPヘッダをつけることができます。 つまり、 1) POSTのリクエストの後にGETのリクエストがあった場合 と、なるとこのQoSでは対応できない気がするんですが。 (少なくてもapacheは上記の方式に対応しています) どうぞよろしくお願いいたします。 > 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 で出力要求された時間帯のひとつ前の時間帯のスループットを > 出力する > （現在の時間帯のスループットは、徐々に増加していくため不安定） > > > > 以上、五月雨なメールで申し訳ありませんが、ご確認下さい。 > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop -- 株式会社SDY 中居憲久 From takebayashi.shinya ＠ oss.ntt.co.jp Tue Aug 26 08:15:12 2008 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Tue, 26 Aug 2008 08:15:12 +0900 Subject: [Ultramonkey-l7-develop 190] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: <20080826020423.e4ca6044.n.nakai@sdy.co.jp> References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> <20080826020423.e4ca6044.n.nakai@sdy.co.jp> Message-ID: たけばやしです． お疲れ様です． > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > と、なるとこのQoSでは対応できない気がするんですが。 > (少なくてもapacheは上記の方式に対応しています) どの点が対応出来ないか，もう少し具体的に示して頂けると助かります． e.g.) POST の GET について，X-Forwarded-For が付けられない, et.al. ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- 中居憲久 wrote in message <20080826020423.e4ca6044.n.nakai ＠ sdy.co.jp > *** Subject: [Ultramonkey-l7-develop 189] Re: QoSコードの修正および追加 - 2 *** Date: 2008/08/26 2:04:23 > 中居です。 > お疲れ様です。 > > > 下記件において一つ質問させてください。 > keepalive onの場合のプロトコルモジュールの動作はどのようになるでしょう? > HTTP1.1のRFCには連続してHTTPヘッダをつけることができます。 > つまり、 > > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > と、なるとこのQoSでは対応できない気がするんですが。 > (少なくてもapacheは上記の方式に対応しています) > > どうぞよろしくお願いいたします。 > > > > 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 で出力要求された時間帯のひとつ前の時間帯のスループットを > > 出力する > > （現在の時間帯のスループットは、徐々に増加していくため不安定） > > > > > > > > 以上、五月雨なメールで申し訳ありませんが、ご確認下さい。 > > > > _______________________________________________ > > Ultramonkey-l7-develop mailing list > > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > -- > 株式会社SDY > 中居憲久 > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop From n.nakai ＠ sdy.co.jp Tue Aug 26 10:38:37 2008 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Tue, 26 Aug 2008 10:38:37 +0900 Subject: [Ultramonkey-l7-develop 191] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> <20080826020423.e4ca6044.n.nakai@sdy.co.jp> Message-ID: <20080826103837.3a07ae0e.n.nakai@sdy.co.jp> 中居です。 お疲れ様です。 HTTP1.1のサーバであった場合、コネクションは継続的である場合があります。 *)RFC2616参照 [メッセージヘッダ] [メッセージボディ] [メッセージヘッダ] [メッセージボディ] と、複数が一つのコネクションにまとまった場合が該当します。 この場合一つのコネクションの最初20kの間にメッセージヘッダがあるはずだという 仮定が成り立たないと思われますが。 またQoSの制御がHTTPに特化しているのもちょっと気になりますが。 Monkeyは他のプロトコルは意識せず、HTTPのみという意識でよろしいのでしょうかね? どうぞよろしくお願いいたします。 > たけばやしです． > お疲れ様です． > > > > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > > > と、なるとこのQoSでは対応できない気がするんですが。 > > (少なくてもapacheは上記の方式に対応しています) > > どの点が対応出来ないか，もう少し具体的に示して頂けると助かります． > > e.g.) POST の GET について，X-Forwarded-For が付けられない, et.al. > > ----------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail: takebayashi.shinya ＠ oss.ntt.co.jp > GPG ID: 395EFCE8 > GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 > ----------------------------------------------------------- > > > 中居憲久 wrote in message <20080826020423.e4ca6044.n.nakai ＠ sdy.co.jp > > > *** Subject: [Ultramonkey-l7-develop 189] Re: QoSコードの修正および追加 - 2 > *** Date: 2008/08/26 2:04:23 > > 中居です。 > > お疲れ様です。 > > > > > > 下記件において一つ質問させてください。 > > keepalive onの場合のプロトコルモジュールの動作はどのようになるでしょう? > > HTTP1.1のRFCには連続してHTTPヘッダをつけることができます。 > > つまり、 > > > > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > > > と、なるとこのQoSでは対応できない気がするんですが。 > > (少なくてもapacheは上記の方式に対応しています) > > > > どうぞよろしくお願いいたします。 > > > > > > > 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 で出力要求された時間帯のひとつ前の時間帯のスループットを > > > 出力する > > > （現在の時間帯のスループットは、徐々に増加していくため不安定） > > > > > > > > > > > > 以上、五月雨なメールで申し訳ありませんが、ご確認下さい。 > > > > > > _______________________________________________ > > > Ultramonkey-l7-develop mailing list > > > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > > > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > > > > -- > > 株式会社SDY > > 中居憲久 > > > > _______________________________________________ > > Ultramonkey-l7-develop mailing list > > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > -- 株式会社SDY 中居憲久 From takebayashi.shinya ＠ oss.ntt.co.jp Tue Aug 26 12:36:50 2008 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Tue, 26 Aug 2008 12:36:50 +0900 Subject: [Ultramonkey-l7-develop 192] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: <20080826103837.3a07ae0e.n.nakai@sdy.co.jp> References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> <20080826020423.e4ca6044.n.nakai@sdy.co.jp> <20080826103837.3a07ae0e.n.nakai@sdy.co.jp> Message-ID: 竹林です． お疲れ様です． > この場合一つのコネクションの最初20kの間にメッセージヘッダがあるはずだという > 仮定が成り立たないと思われますが。 > たとえば，Keepalive が有効になっているコネクション（セッション）で 下記ふたつのリクエストを処理するとします． [GET /index.html ] [GET /error.html ] ○ cookie insert の場合 index.html を取得するときにサービスが決定し，宛先リアルサーバも 決定するので，問題ない． ＃ リクエスト事にリアルサーバが異なることはあり得ないため ○ URL モジュールの場合 index.html に適合するルールが無い場合は，接続拒否． 動作は現在の実装と変わらない． ○ Sessionless モジュールの場合 リクエストごとの負荷分散はできない． 同一コネクションの中のリクエストは，同じリアルサーバで処理される． これも現在の実装で Keepalive を有効にしている場合と同様． ○ SSL SessionID 対象外． > またQoSの制御がHTTPに特化しているのもちょっと気になりますが。 > Monkeyは他のプロトコルは意識せず、HTTPのみという意識でよろしいのでしょうかね? 先頭から L7VS_CONN_READ_BUFSIZE 分だけ読み込んだバッファを， サービス判定のフローに丸投げすることで回避できそうです． プロトコルモジュールに新しくサービス判定用のインタフェイスを作ったりして， 各プロトコルに応じた判定処理をすれば問題ないと思います． いかがでしょうか． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- 中居憲久 wrote in message <20080826103837.3a07ae0e.n.nakai ＠ sdy.co.jp > *** Subject: Re: [Ultramonkey-l7-develop 189] Re: QoSコードの修正および追加 - 2 *** Date: 2008/08/26 10:38:37 > 中居です。 > お疲れ様です。 > > HTTP1.1のサーバであった場合、コネクションは継続的である場合があります。 > *)RFC2616参照 > > [メッセージヘッダ] > [メッセージボディ] > [メッセージヘッダ] > [メッセージボディ] > > と、複数が一つのコネクションにまとまった場合が該当します。 > この場合一つのコネクションの最初20kの間にメッセージヘッダがあるはずだという > 仮定が成り立たないと思われますが。 > > またQoSの制御がHTTPに特化しているのもちょっと気になりますが。 > Monkeyは他のプロトコルは意識せず、HTTPのみという意識でよろしいのでしょうかね? > > どうぞよろしくお願いいたします。 > > > > たけばやしです． > > お疲れ様です． > > > > > > > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > > > > > と、なるとこのQoSでは対応できない気がするんですが。 > > > (少なくてもapacheは上記の方式に対応しています) > > > > どの点が対応出来ないか，もう少し具体的に示して頂けると助かります． > > > > e.g.) POST の GET について，X-Forwarded-For が付けられない, et.al. > > > > ----------------------------------------------------------- > > Shinya TAKEBAYASHI > > > > E-mail: takebayashi.shinya ＠ oss.ntt.co.jp > > GPG ID: 395EFCE8 > > GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 > > ----------------------------------------------------------- > > > > > > 中居憲久 wrote in message <20080826020423.e4ca6044.n.nakai ＠ sdy.co.jp > > > > > *** Subject: [Ultramonkey-l7-develop 189] Re: QoSコードの修正および追加 - 2 > > *** Date: 2008/08/26 2:04:23 > > > 中居です。 > > > お疲れ様です。 > > > > > > > > > 下記件において一つ質問させてください。 > > > keepalive onの場合のプロトコルモジュールの動作はどのようになるでしょう? > > > HTTP1.1のRFCには連続してHTTPヘッダをつけることができます。 > > > つまり、 > > > > > > 1) POSTのリクエストの後にGETのリクエストがあった場合 > > > > > > と、なるとこのQoSでは対応できない気がするんですが。 > > > (少なくてもapacheは上記の方式に対応しています) > > > > > > どうぞよろしくお願いいたします。 > > > > > > > > > > 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 で出力要求された時間帯のひとつ前の時間帯のスループットを > > > > 出力する > > > > （現在の時間帯のスループットは、徐々に増加していくため不安定） > > > > > > > > > > > > > > > > 以上、五月雨なメールで申し訳ありませんが、ご確認下さい。 > > > > > > > > _______________________________________________ > > > > Ultramonkey-l7-develop mailing list > > > > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > > > > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > > > > > > > -- > > > 株式会社SDY > > > 中居憲久 > > > > > > _______________________________________________ > > > Ultramonkey-l7-develop mailing list > > > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > > > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > > > > > -- > 株式会社SDY > 中居憲久