From nakai.norihisa ＠ yes.nttcom.ne.jp Tue Jul 24 19:46:28 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Tue, 24 Jul 2007 19:46:28 +0900 Subject: [Ultramonkey-l7-develop 42] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEIkTiVYJUMlQEosM2QbKEI=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <469F3634.9050107@yes.nttcom.ne.jp> <46A015F5.4070108@yes.nttcom.ne.jp> <46A05D63.3020702@yes.nttcom.ne.jp> <46A069DA.30002@yes.nttcom.ne.jp> Message-ID: <46A5D884.4010504@yes.nttcom.ne.jp> 竹林様 お世話になっております。 中居です。 Comware内部で機能改善用branchを切ったときに、ヘッダ分割と合わせて 各部の布石を入れさせていただきました。 以降詳細説明をさせていただきます。 少々大きな変更になりますので、複数回のメールにわたって説明させていただきます。 ご了承ください。 [sync_sessionの無効化] 今回UltraMonkey-L7の機能改善の項目に接続数を1500にしても性能劣化しないことと言う 目標がありました。 そこで現状のUltraMonkey-L7で処理に時間のかかっているであろう部分を検討しました。 1) select()システムコール 2) serviceでのconnのg_listの線形サーチ 3) プロトコルモジュールでの都度共有メモリとsemaphoreの初期化及び使用 1に関してはepoll化とnon-blockの課題が挙がっておりましたので、単純にepollとselectの 両方のシステムコールがどれぐらい違うかを計測しました。 以前メールで送信しましたとおり、この二つのシステムコールでは全体的な速度の向上の 可能性は低いと判断しました。 2は投稿したパッチには含まれていませんが、接続数が多くなた場合にリストを線形検索するよりは ハッシュを用いたほうが有利と思われますので、実装テストを行っております。 3の共有メモリとsemaphoreも問題点も多い部分と思われます。 問題点と思われるもの ・MTUのサイズによってはUDPパケットは分割される可能性があるが、UDPでのパケットの順序性などは 　保障されないため、環境によっては(MTUサイズが最小サイズだった場合など)共有メモリが崩れ、 　動作を保障できない。 ・構造上毎回match_cldata()が呼ばれるたびにsemaphoreの排他を確認している(経験上semaphoreは非常に重たい) ここで考えられるのは 1.SVR SemaphoreよりもPOSIX Semaphoreのほうが性能面で有利のためPOSIX Semaphoreに変更 　→そもそもPOSIX Semaphoreのほうが有利とはいえ重いのには違いない 2.プロセス間の調整をp_thread_mutex_tを共有メモリに配置して行うと(RHEL3より対応)パフォーマンスで 　有利と言う情報がある(確かにsemaphoreよりはmutexのほうが高速)。 　→ただし、中居が実験した限りではあまり速度的にメリットは少なかった 　> $ time ./shm_test aabb 10000000 　> real 0m24.271s 　> user 0m8.157s 　> sys 0m16.063s 　> 　> $ time ./mtx_test aabb 10000000 　> real 0m28.311s 　> user 0m8.455s 　> sys 0m19.764s 　これはsemaphoreを使って共有メモリに1000万回文字列をメモリに書き込むテストですが、 　あまり差分が見られません。 　(CPUはXeon3.2GのDualCoreだと思いましたが、去年計測したものなので…)　 上記数字を見てもらえばわかりますがかなりコストが大きいことがわかります。 ちなみにローカルメモリでは > $ time ./local_test aabb 10000000 　> real 0m0.026s > user 0m0.025s > sys 0m0.001s　 と、なりますからいかに共有メモリが重たいのかがわかります。 3.構造的にsyncsessionを見直して、速度を最優先とした実装とする が考えられます。 結果としては3の速度を最優先とした実装とするを選択しました。 そこで考えなければならない部分は 1.接続が増えたとしても共有の処理コストが上がりづらいこと 2.MTUサイズに左右されない実装とすること 3.UDPのパケット順序が保障されないことを考慮すること 4.UDPのパケットロストを考慮すること です。 3 - 4に関しては送信構造と関数の工夫で何とかなりますが、 1に関しては現状の方式では接続が増えれば増えるほど線形で時間がかかります。 したがって、configのようにselect/epoll_wait()一回につき一度同期処理を 行うという方式にすれば、接続数と同期のコストのバランスが取れます。 とりあえずsyncsessionに関しては上記理由より方式の再検討を行いました。 メールが長文になり始めてきましたのでとりあえずこの辺で一度閉めます。 次回は、実際のsyncsessionの方式と、実装の説明をいただきます。 どうぞよろしくお願いいたします。 > 中居 様 > > > 竹林です． > お疲れ様です． > > ご対応ありがとうございます． > > 内容を確認させて頂きましたが，今回のパッチはヘッダ分割だけでは > ないようですね． > > ざっと見たところ， > > ○ データ型の変更 > ○ sync_session の無効化 > ○ 各関数内の処理内容の変更 > > などが含まれているようです． > > 詳細な説明をお願いします． > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > > > *** 中居憲久 wrote in message <46A069DA.30002 ＠ yes.nttcom.ne.jp> > *** Subject: [Ultramonkey-l7-develop 40] Re: [pmo-oss-um:0492] Re: Re: > UltraMonkey-L7のヘッダ分割について > *** Date: Fri, 20 Jul 2007 16:52:58 +0900 >> 中居です。 >> お世話になっております。 >> >> 先ほど誤って古いファイルをそのまま送信してしまいました。 >> 再度送信いたします。 >> >> よろしくお願いいたします。 >> >> >>> 竹林様 >>> >>> 中居です。 >>> お世話になっております。 >>> >>> 確認しましたところ、0.6.0へとリリースするベースになったバージョンが >>> trunkとして運用されていました。 >>> Merge作業を行いましたのでご確認をお願いいたします。 >>> >>> >>> >>>> 中居 様 >>>> >>>> >>>> 竹林です． >>>> お疲れ様です． >>>> >>>> ご対応ありがとうございます． >>>> >>>> パッチは当たりましたが・・・0.5.0-3 をベースに作られているようで > す． >>>> ベースとしているバージョンの確認をお願い致します． >>>> >>>> ----------------------------------------------------------- >>>> Shinya TAKEBAYASHI >>>> >>>> E-mail(Office): takebayashi.shinya ＠ nttcom.co.jp >>>> E-mail(Private): makoto ＠ kanon-net.jp >>>> GPG ID: 70298B55 >>>> GPG FP: 98C3 25CF 8201 4881 9328 5C91 CBFA DCFC 7029 8B55 >>>> ----------------------------------------------------------- >>>> >>>> >>>> >>>> *** 中居憲久 wrote in message <46A015F5.4070108 ＠ yes.nttcom.ne.jp> >>>> *** Subject: [Ultramonkey-l7-develop 37] Re: [pmo-oss-um:0489] Re: >>>> UltraMonkey-L7のヘッダ分割について >>>> *** Date: 2007/07/20 10:55:01 >>>>> 竹林様 >>>>> >>>>> 中居です。 >>>>> お世話になっております。 >>>>> >>>>> ご指摘ありがとうございます。 >>>>> 下記件に従いましてpatchを製作いたしました。 >>>>> >>>>> 添付いたしますので、ご確認ください。 >>>>> どうぞよろしくお願いいたします。 >>>>> >>>>> >>>>> >>>>>> 中居 様 >>>>>> >>>>>> >>>>>> 竹林です． >>>>>> お疲れ様です． >>>>>> >>>>>> パッチの作成ありがとうございます． >>>>>> 早速確認しようと思いましたが，そのままではパッチが適用できませ > ん． >>>>>> >>>>>> おそらく l7vs-0.6.0-0.tar.gz を元に作成されたかと思いますが， >>>>>> ディレクトリの構成が違うためそのままでは適用できないようです． >>>>>> >>>>>>> diff -Naur ../0.6.0/Makefile.am ./Makefile.am >>>>>>> --- ../0.6.0/Makefile.am 2007-04-03 18:46:00.000000000 + >>>> 0900 >>>>>>> +++ ./Makefile.am 2007-05-18 17:47:27.000000000 +0900 >>>>>> とのことで，ディレクトリ名を 0.6.0 に変更して patch -p0 といっ > た >>>>>> 形でしょうか． >>>>>> >>>>>> すみませんが，一般的に使用されている形式（？）にしていただけま > す >>>> か． >>>>>> - work >>>>>> +--l7vs-0.6.0-0/ ← オリジナル >>>>>> +--l7vs-0.6.0-0-patched/ ← 改変されたもの >>>>>> >>>>>> といった形のディレクトリ構成をつくり，work の中で >>>>>> >>>>>> $ diff -urNP l7vs-0.6.0-0 l7vs-0.6.0-0-patched > filename. >>>> patch >>>>>> を実行すれば，work に patch -p1 で適用可能なファイルが >>>>>> できあがります． >>>>>> >>>>>> >>>>>> お忙しい中恐縮ですが，よろしくお願い致します． >>>>>> >>>>>> ------------------------------------------------------------- >>>>>> 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 >>>>>> ------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> *** 中居憲久 wrote in message <469F3634.9050107 ＠ yes.nttcom.ne.jp> >>>>>> *** Subject: [Ultramonkey-l7-develop 35] UltraMonkey-L7のヘッダ分 >>>> 割につ >>>>>> いて >>>>>> *** Date: Thu, 19 Jul 2007 19:00:20 +0900 >>>>>>> UltraMonkey-l7開発者の皆様 >>>>>>> >>>>>>> お世話になっております。 >>>>>>> NTTComwareにてUltraMonkey-L7のepoll化及び高速化を行ってる中居で > す。 >>>>>>> 現在進行形ではあるのですが、複数人にて開発を行っているため、 >>>>>>> 既存のUltraMonkeyのファイル構成ではUnitTestなどの作業に少々不便 > が >>>> ある >>>>>> ため >>>>>>> モジュールごとにヘッダファイルを分割いたしました。 >>>>>>> >>>>>>> モジュールごとのヘッダファイルを分割したパッチを送付させていただ >>>> きます。 >>>>>>> また前回のメールで説明させていただきましたが、 >>>>>>> epoll化と同時に各種機能を追加しております。 >>>>>>> >>>>>>> 以下に概要を説明させていただきます。 >>>>>>> >>>>>>> 1)Syncsessionの再設計 >>>>>>> →セッション情報をUDPでSBY側に送っているが、MTUの値を超えた場 > 合 >>>> の考 >>>>>> 慮がないため >>>>>>> 　複数回のUDPパケットを考慮した設計に変更。 >>>>>>> 　ただし、UDPのため順序とロストに関しては設計で吸収を行う。 >>>>>>> 　また、l7syncdとの情報共有をプロトコルモジュール中でsemaphore >>>> と >>>>>> shared_memoryで >>>>>>> 　行っているが、その部分での速度低下を抑える設計とする。 >>>>>>> >>>>>>> 2)QoSの導入 >>>>>>> →バーチャルサービスごとの単位時間あたりにrecv()するバイト数を >>>> 設定で >>>>>> きるようにする。 >>>>>>> 　また、コネクションごとの単位時間あたりにrecv()するバイト数を >>>> 設定で >>>>>> きるようにする。 >>>>>>> 　これはepoll()化に伴い単独clientからの分割されたパケットを複 > 数 >>>> 回の >>>>>> epoll_wait()で >>>>>>> 　処理できるようになっているため、単位時間あたりに規定値よりも >>>> 多くの >>>>>> データが >>>>>>> 　送られてきた場合には、次回のepoll_wait()時に処理するようにす >>>> る。 >>>>>>> 3)Sorry機能の修正 >>>>>>> →現状はprotocolmodule中で共有メモリに情報を持っているためバー >>>> チャル >>>>>> サービスを超えて >>>>>>> 　Sorryサーバへと飛ばされてしまう。 >>>>>>> 　また、destを直接書き換えるために戻すことができない。 >>>>>>> 　したがって、バーチャルサービス単位でsorryを設定できるように > す >>>> る。 >>>>>>> 一番の変更点は前回のメールで説明させていただいたepoll周りなので > す >>>> が、 >>>>>>> そのほかにも大きなもので上記の機能追加を行っております。 >>>>>>> >>>>>>> 次回、それぞれの方式についてもう少し掘り下げた説明のメールを投げ >>>> られれ >>>>>> ばと思っております。 >>>>>>> どうぞよろしくお願いいたします。 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> -------------------------------------------------------------------- > ---- >>> _______________________________________________ >>> Ultramonkey-l7-develop mailing list >>> Ultramonkey-l7-develop ＠ lists.sourceforge.jp >>> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > > >