From makoto ＠ kanon-net.jp Wed Jul 4 01:38:04 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Wed, 04 Jul 2007 01:38:04 +0900 Subject: [Ultramonkey-l7-develop 32] Re: =?iso-2022-jp?b?bDd2c19zZXJ2aWNlIBskQjk9QiRCTiROSlE5OSRLGyhC?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: <20070628230919.A39F92DC652@mail.valinux.co.jp> References: <20070628230919.A39F92DC652@mail.valinux.co.jp> Message-ID: 黒澤 様 竹林です． お疲れさまです． 返信が遅れまして，すみません． ○ sched_data は使えないか sched_data の利用も考えて作ってはみたのですが，やはりどれが最初の， つまり構造の初期化を要する呼び出しなのかを判定するのが難しい状況です． ＃ 黒澤さんが最後に指摘されたところです 今考えている処理の流れとしては・・・ 1. l7vs_sched_wrr_schedule が呼ばれる 2. 管理テーブル（ハッシュ）を探る 3. 当たらなければ新しいサービスなので，管理テーブルを初期化 4. gcd を用いて振り分け先の候補を決め，返す というものですが，上位から仮想サービスを識別できる何らかの 情報がなければ，上記「2」の処理ができなくなります． 現状で使える情報が無いかと言われればゼロではありませんが， 使えても仮引数で渡ってくる service のポインタくらいです． それも，同じアドレスが渡ってくる事が保証されていなければアウトです． ○ 識別子の必要性について スケジューラが一つの仮想サービスからしか使われないことが保証されて いるのであれば，現在の l7vs_service の構造でも実現はできるのですが， 複数の仮想サービスから同じスケジューラを呼ばれると言う時点で 呼び出し元の仮想サービスが何者かを知る手段は確保しておいた方が 良いと考えています． むしろ，今回のように複数のルートから同一の関数が呼ばれる場合， 識別子は上位が管理して下位に流さなければならない情報だと思います． 今後プロトコルモジュールを作る際も，この構造を用意しておいても 無駄にはならないと思いますし． ＃ 必要なければ無視すれば良いことなので > ただ，いろいろ考えると，サービスが生成・削除されたときにスケジューラに > 通知してあげる仕組みも必要になりそうですね．おそらくサービスが生成され た > ときに，スケジューラ側で何らかの初期化処理をしたいはずですので…… 仮想サービス削除についても通知される機能がないため，現状では スケジューラ内で動的なメモリの確保はできません． 何分，free するタイミングが掴めないので・・・． 従って，sched_data に対して計算済みのコストを格納した構造を 繋げることも不可能となっています． 仮想サービスを識別出来るものがあれば，スケジューラ内で固定長の 管理テーブルを持っておいてハッシュを使って引いてこれるかと 思っているのですが・・・． 最善の処置としては，仮想サービスの追加と削除をスケジューラや プロトコルモジュールに通知する機能を実装することですが，新しく インタフェイスを増やすのはインパクトが大きいので，既存の構造体に一つ， メンバを追加することで初期化の部分だけでも対処はできると思います． 急いでリリースに含めて貰おうとは思っていませんので，そのうちの リリースの際にでも盛り込めれば，と思った次第です． ＃ コムウェアさんの方で動きがあるとか無いとか聞いていますが・・・ ＃＃ 上手いこと紛れ込ませる事も可能・・・？ ------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp E-mail(private)： makoto ＠ kanon-net.jp GPG ID： FFD20D1F GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ------------------------------------------------------------- *** KUROSAWA Takahiro wrote in message <20070628230919.A39F92DC652 ＠ mail.valinux.co.jp > *** Subject: [Ultramonkey-l7-develop 31] Re: l7vs_service 構造体の変更に ついて *** Date: Fri, 29 Jun 2007 08:09:19 +0900 > 竹林さん > > 黒澤です．お疲れさまです． > > l7vs_service 構造体の sched_data は，この用途に使うことはできませんか？ > スケジューラに状態を持たせるために存在するメンバとして考えていたので， > まさにこの用途に使えると思います． > > ただ，いろいろ考えると，サービスが生成・削除されたときにスケジューラに > 通知してあげる仕組みも必要になりそうですね．おそらくサービスが生成され た > ときに，スケジューラ側で何らかの初期化処理をしたいはずですので…… > > From makoto ＠ kanon-net.jp Wed Jul 4 02:07:00 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Wed, 04 Jul 2007 02:07:00 +0900 Subject: [Ultramonkey-l7-develop 33] Re: =?iso-2022-jp?b?bDd2c19zZXJ2aWNlIBskQjk9QiRCTiROSlE5OSRLGyhC?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: References: <20070628230919.A39F92DC652@mail.valinux.co.jp> Message-ID: 竹林です． お疲れさまです． メールを送ってしまってから気付きました． > 仮想サービス削除についても通知される機能がないため，現状では > スケジューラ内で動的なメモリの確保はできません． > 何分，free するタイミングが掴めないので・・・． モジュールのファイナライズ関数があるので，最悪ここで free すれば いいですね． > 仮想サービスを識別出来るものがあれば，スケジューラ内で固定長の > 管理テーブルを持っておいてハッシュを使って引いてこれるかと > 思っているのですが・・・． free する場所はあるので，可変長でもいけそうな気がします． ------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp E-mail(private)： makoto ＠ kanon-net.jp GPG ID： FFD20D1F GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ------------------------------------------------------------- *** Shinya TAKEBAYASHI wrote in message *** Subject: [Ultramonkey-l7-develop 32] Re: l7vs_service 構造体の変更に ついて *** Date: Wed, 04 Jul 2007 01:38:04 +0900 > 黒澤 様 > > > 竹林です． > お疲れさまです． > 返信が遅れまして，すみません． > > > ○ sched_data は使えないか > > sched_data の利用も考えて作ってはみたのですが，やはりどれが最初の， > つまり構造の初期化を要する呼び出しなのかを判定するのが難しい状況です． > ＃ 黒澤さんが最後に指摘されたところです > > 今考えている処理の流れとしては・・・ > > 1. l7vs_sched_wrr_schedule が呼ばれる > > 2. 管理テーブル（ハッシュ）を探る > > 3. 当たらなければ新しいサービスなので，管理テーブルを初期化 > > 4. gcd を用いて振り分け先の候補を決め，返す > > というものですが，上位から仮想サービスを識別できる何らかの > 情報がなければ，上記「2」の処理ができなくなります． > 現状で使える情報が無いかと言われればゼロではありませんが， > 使えても仮引数で渡ってくる service のポインタくらいです． > それも，同じアドレスが渡ってくる事が保証されていなければアウトです． > > > ○ 識別子の必要性について > > スケジューラが一つの仮想サービスからしか使われないことが保証されて > いるのであれば，現在の l7vs_service の構造でも実現はできるのですが， > 複数の仮想サービスから同じスケジューラを呼ばれると言う時点で > 呼び出し元の仮想サービスが何者かを知る手段は確保しておいた方が > 良いと考えています． > むしろ，今回のように複数のルートから同一の関数が呼ばれる場合， > 識別子は上位が管理して下位に流さなければならない情報だと思います． > > 今後プロトコルモジュールを作る際も，この構造を用意しておいても > 無駄にはならないと思いますし． > ＃ 必要なければ無視すれば良いことなので > > > > > ただ，いろいろ考えると，サービスが生成・削除されたときにスケジューラ に > > 通知してあげる仕組みも必要になりそうですね．おそらくサービスが生成さ れ > た > > ときに，スケジューラ側で何らかの初期化処理をしたいはずですので…… > > 仮想サービス削除についても通知される機能がないため，現状では > スケジューラ内で動的なメモリの確保はできません． > 何分，free するタイミングが掴めないので・・・． > 従って，sched_data に対して計算済みのコストを格納した構造を > 繋げることも不可能となっています． > > 仮想サービスを識別出来るものがあれば，スケジューラ内で固定長の > 管理テーブルを持っておいてハッシュを使って引いてこれるかと > 思っているのですが・・・． > > 最善の処置としては，仮想サービスの追加と削除をスケジューラや > プロトコルモジュールに通知する機能を実装することですが，新しく > インタフェイスを増やすのはインパクトが大きいので，既存の構造体に一つ， > メンバを追加することで初期化の部分だけでも対処はできると思います． > > > 急いでリリースに含めて貰おうとは思っていませんので，そのうちの > リリースの際にでも盛り込めれば，と思った次第です． > ＃ コムウェアさんの方で動きがあるとか無いとか聞いていますが・・・ > ＃＃ 上手いこと紛れ込ませる事も可能・・・？ > > ------------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp > E-mail(private)： makoto ＠ kanon-net.jp > GPG ID： FFD20D1F > GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F > ------------------------------------------------------------- > > > > *** KUROSAWA Takahiro wrote in message <20070628230919.A39F92DC652 ＠ mail.valinux.co.jp > > > *** Subject: [Ultramonkey-l7-develop 31] Re: l7vs_service 構造体の変更 に > ついて > *** Date: Fri, 29 Jun 2007 08:09:19 +0900 > > 竹林さん > > > > 黒澤です．お疲れさまです． > > > > l7vs_service 構造体の sched_data は，この用途に使うことはできません か？ > > スケジューラに状態を持たせるために存在するメンバとして考えていたので， > > まさにこの用途に使えると思います． > > > > ただ，いろいろ考えると，サービスが生成・削除されたときにスケジューラ に > > 通知してあげる仕組みも必要になりそうですね．おそらくサービスが生成さ れ > た > > ときに，スケジューラ側で何らかの初期化処理をしたいはずですので…… > > > > > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop From nakai.norihisa ＠ yes.nttcom.ne.jp Wed Jul 4 15:17:15 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Wed, 04 Jul 2007 15:17:15 +0900 Subject: [Ultramonkey-l7-develop 34] =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEJKUTk5JEskRCQkJEYbKEI=?= Message-ID: <468B3B6B.2090104@yes.nttcom.ne.jp> TO:UltraMonkey-L7開発をなさっている皆様 お世話になっております。 NTTComwareの中居です。 このたびepoll化に合わせまして、既存のUltraMonkey-L7での高速化について 検討してきました。 また、課題も検討しておりますが、今回は高速化について下記部分の修正を考えております。 1)struct l7vs_serviceがGListでconn_listを持っている部分 0.6.0の現状ではserviceにconnの双方向リストを持っており、service_register_conn時に リスト追加、conn_destroy時にリストから削除されている。 この部分の検索は線形検索であり、計算時間はO(n)となる。 前回のメール(すいません、佐々木さんへの宿題は後述します)で書きましたように select()とepoll_wait()のAPI時間は30%程度しか違わないため、 上記部分等の検索(g_list_remove()等)をGHashに変更することで計算時間をO(1)として 計算コストを下げる必要があると思っております。 2)client-connが初回のデータ受信時に別途select()を回している部分 clientからの最初のリクエストパケットを全て受信しなければmatch_cldata()にてhttpの場合 httpヘッダを解釈するために複数回のrecv()を発行し、全て読み込む必要がありますが、、 遅く巨大なデータを送るclientが居た場合にはこの部分がボトルネックになる可能性があると 思われます。 上記はselect()/epoll_wait()のループを複数回またいでsend()/recv()を行う 必要があると思われます。 また、I/O空間が使い尽くされたときにはrecv()やwrite()で返すバイトサイズは 必ず全て読み込まれるor書き込まれる保障がないため、 2-1) write()を発行する場合もepoll_wait()にEPOLLOUTイベントの問い合わせを行うべきである。 2-2) write()の返り値が書き込む量より少なかった場合には、再びepoll_wait()に戻り 　　 書き込み可能なイベントをキャッチした段階で残りを送信すべきである。 上記2点を考慮する必要があると認識しております。 つまるところselect()/epoll_wait()ループの処理をまたぐことを前提としての 設計を行っております。 この部分に関しては状態遷移が複雑になるため、状態変数を導入し明確な状態を定義を行おうと思っております。 どうぞ宜しくお願いいたします。 佐々木さんへの質問への回答 すいません、遅れてしまって申し訳ありません。 以下に簡単ではありますが、書かせていただきます。 >(Q1) クライアントのsend()前後を計測していますが、これは、 > ・複数スレッドから同時に、比較的大きな64Kバイトのデータ > を送信。 > ・サーバ側の受信処理がおいつかず、TCPバッファにデータが > たまる。 > ・TCPバッファに空きができるまで、send()がブロック。 > ・TCPバッファに書き込めたということは、サーバ側で処理し > たということだから、それが、select/epollの処理性能 > と考える。 > と解釈されば良いのでしょうか？ 本文中にある解釈であっております。 client側から見た場合の処理が問題になると考えましたので 敢えてclient側からの計測を行っています。 >(Q2) クライアント側のスレッド数(コネクション数)はいくつでしょ > うか？ (パラメータの1000がそうですか？) > また、コネクション数の違いより、どれくらいの差異があった > でしょうか？ パラメーターの1000がThread数です。 300Threadから1000Threadまでを確認してみました。 300Threadではslect()とepoll()の差が明確でないのですが、 (逆にselect()のほうが早いときもありました)、 負荷がかかった状態ではepoll()のほうが30%高速と見えます。 >(Q3) 1回のselect/epollで、通知されたイベント数は、何個ぐら > いでしょうか？ イベント数を確認していませんでした。 時間がありましたらイベント数を出力させてみようと思います。 >(Q4) epollとselectで、スレッドによって、処理時間のバラツキは > あったでしょうか？ (最大と最小は、どれくらいでしょうか？) 各Threadでの時間は取得しておりません。 理由は各Threadの情報をlogやコンソール等に出力する場合には mutexの排他処理が大きくなるため、共有関数ひとつにまとめるように 設計しました。 Threadの分配列を作成してもかまわなかったかもしれませんが、 過去の経験上、各Threadが参照するメモリ領域が24byte以内にある場合 intelのCPUでは劇的に速度が遅くなる事象がありましたので。 (#キャッシュタグが24byte単位のため24byte境界に引っかかるデータはCore間のCacheで Snoopが流れてボトルネックになっているのではないかと憶測) どうぞ、宜しくお願いいたします。 _____________________ 中居憲久[Nakai Norihisa] nakai.norihisa ＠ yes.nttcom.ne.jp