From nakai.norihisa ＠ yes.nttcom.ne.jp Tue Nov 13 13:48:37 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Tue, 13 Nov 2007 13:48:37 +0900 Subject: [Ultramonkey-l7-develop 65] Re: =?iso-2022-jp?b?YWNjZXB0KCkbJEIkTiUzJTklSCRLJEQkLSReJDcbKEI=?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: References: <473421B3.1070401@sdy.co.jp> Message-ID: <47392CA5.5020102@yes.nttcom.ne.jp> 竹林様 中居です。 お疲れ様です。 > accept をノンブロッキングで動かすのは・・・ちょっと危ないかと． > 危ないというか，危ないところをガードする部分を作り込むところが > 大きくなりそうです > ＃ デグレが気になります・・・ 上記に書いたようにコード的なデグレと言うよりは、管理する部分が難しいでしょう。 ガードする部分はaccept()自体が内部でシリアライズされているので問題ありませんが、 (先にacceptが走っていると終了しない限り後続のacceptは必ず失敗する) 現状、lsockがacceptしている状態を持っていないため、状態を確定するのが辛いです。 > 現在の実装では，1 つの論理 CPU しか握れないので，部分的にも > マルチスレッド化することで負荷分散ができそうですね． 基本的にこの場合の処理の重さは演算量ではなく、 clientとの新しいTCPハンドシェイクを確立するのが遅いので、 負荷分散…と言うよりはwaitを隠蔽するといったほうが正しいかもしれません。 #イメージ的にはCPUのSMTかと。メモリアクセスに時間がかかる間はパイプラインが遊ぶので #その間に他のものができる…みたいな。 > ただ，pthread_create() のコストの大きさが半端ないので，性能に影響が > ないか気になります． > この辺りはどうでしょうか． > やはりスレッドプールがベターなのでしょうか． pthread_create()のコストで大きいのはthread分のヒープ確保ですね。 threadのヒープ量を少なくすることで軽くすることは可能ですが (それでも一度accept()でTCPハンドシェイクを行うよりは格段に軽いと思われます) ベストなのはThreadPoolでしょうね。 ただ、ThreadPoolの管理のコーディングコストを考慮する必要はあります。 >> threadの上限はRHEL4U4の32bitでは300個と言うbugがあったり…。 >> 　　RHEL4U4の64bitでは数万個のthreadを作成できます) > この情報のソースはどこでしょう． > Redhat の Bugzilla を見てみましたが見あたりません． これに関しては3000client試験の時に32bitマシンで3000threadを起こせなくて 四苦八苦したときに発見しました。 RHEL4U5のChangeLogにある -fix for bogus resource data w/multi-threaded exec (Ernie Petrides) [240349] この部分だと思われます。 どうぞよろしくお願いいたします。 From kitani.yumi ＠ nttcom.co.jp Tue Nov 13 16:39:07 2007 From: kitani.yumi ＠ nttcom.co.jp (Yumi Kitani) Date: Tue, 13 Nov 2007 16:39:07 +0900 Subject: [Ultramonkey-l7-develop 66] =?iso-2022-jp?b?c3luYxskQjUhRz0kSyREJC0kXiQ3JEYbKEI=?= Message-ID: <007f01c825c8$45bde960$df4b850a@NTT47BF06BD9FE> UltraMonkey-L7-Devの皆様 はじめまして、NTTコムウェア UltraMnokey-L7開発メンバーの 木谷と申します。 以後、宜しくお願い致します。 今回、sync機能を使用するプロトコルモジュールの追加に伴い、 sync機能の見直しを考えております。 syncが必要と考えている情報は、以下のものです。 ・Cookie　Persistence Hash 情報 ・URL Persistence Active 情報 ・SSL Session ID 情報 ・QoSの重み値 ・sorry flag 複数モジュールの情報の同期に使用することから、同期情報が 入っているメモリをsyncで一括管理し、一定量ずつ定期的に 送受信を行うようにしたいと考えております。 是非皆様にもコメント等、色々と御教授頂けたらと思いますので、 宜しく御願い致します。 ****************************************************** Yumi Kitani mail ： kitani.yumi ＠ nttcom.co.jp ****************************************************** From nakai.norihisa ＠ yes.nttcom.ne.jp Tue Nov 13 17:30:11 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Tue, 13 Nov 2007 17:30:11 +0900 Subject: [Ultramonkey-l7-develop 67] Re: =?iso-2022-jp?b?c3luYxskQjUhRz0kSyREJC0kXiQ3JEYbKEI=?= In-Reply-To: <007f01c825c8$45bde960$df4b850a@NTT47BF06BD9FE> References: <007f01c825c8$45bde960$df4b850a@NTT47BF06BD9FE> Message-ID: <47396093.3050902@yes.nttcom.ne.jp> TO:木谷様 CC:皆様 中居です。 よろしくお願いいたします。 本文中にコメントしますね。 > 今回、sync機能を使用するプロトコルモジュールの追加に伴い、 > sync機能の見直しを考えております。 0.6.0では共有メモリでsyncプロセスにデータを引き渡し、 syncプロセスがそれぞれに共有を行う方式だったと思いますが、 今回はl7vsdの中で閉じる(=semaphoreのコストを嫌う)でよいのですね? > syncが必要と考えている情報は、以下のものです。 > ・Cookie　Persistence Hash 情報 > ・URL Persistence Active 情報 > ・SSL Session ID 情報 > ・QoSの重み値 > ・sorry flag SSLSessionID情報は現状のprotocol_moduleでは扱えないと思うのですが、 この情報を扱うmoduleを作成する、と言うことですかね。 > 複数モジュールの情報の同期に使用することから、同期情報が > 入っているメモリをsyncで一括管理し、一定量ずつ定期的に > 送受信を行うようにしたいと考えております。 同期情報は0.6.0と同じようにudpで互いに送信しあうという 構造でよいのですよね? ひとつだけ疑問があります。 初期状態 UM1(ACT) -> UM2(SBY) となって同期を行うと思いますが、ACTが死んだ場合 UM2(ACT) となると思います。ここでUM1がSBYで復帰してきた場合 UM1(SBY) <- UM2(ACT) と逆方向の同期になると思いますがどのように解決するのでしょうか? どうぞよろしくお願いいたします。 From takamaru.akira ＠ yes.nttcom.ne.jp Tue Nov 13 17:39:46 2007 From: takamaru.akira ＠ yes.nttcom.ne.jp (=?ISO-2022-JP?B?GyRCOWI0XSEhTEAbKEI=?=) Date: Tue, 13 Nov 2007 17:39:46 +0900 Subject: [Ultramonkey-l7-develop 68] =?iso-2022-jp?b?bG9nZ2luZxskQiVpJSQlViVpJWokTkpROTkkSyREJC0bKEI=?= =?iso-2022-jp?b?GyRCJF4kNyRGGyhC?= Message-ID: <473962D2.30703@yes.nttcom.ne.jp> ultraMonkey-l7-developの皆様 はじめまして、NTTコムウェアにて UltraMnokey-L7の開発をしております高丸と申します。 以後、宜しくお願い致します。 今回、ログ機能の機能UPを考えており、 強化の方針として以下の2点を考慮しております。 ・通常運用時に最低限必要な情報のみをログ出力することにより 　パフォーマンスを上げる ・保守、トラブル対応時に切り分けができる十分な情報を提供する そのため、vanessa_loggerの代わりにapacheのlog4cxxを 採用することを考えております。 理由と致しまして、 ・ログレベルという概念があり、指定されたレベル以下のログを 　出力しないようにできる 　（コーディングでは先にログレベルを判定し、文字列生成の 　　コストも抑えるようにする予定です） ・カテゴリという概念があり、ログをカテゴリで区別し、 　カテゴリ毎にレベルを設定することにより、 　問題領域に的を絞ったログを出力することができる また、先の中居さんのメールにもありましたとおり、 acceptをマルチスレッド化する要件も出てきており、 現状使用しておりますvanessa_loggerはマルチスレッドに 対応していないため、この点でもloggingライブラリを 変更する必要があるかと思います。 以上、上記改良案にご意見等いただけましたら幸いです。 宜しくお願いいたします。 From nakai.norihisa ＠ yes.nttcom.ne.jp Tue Nov 13 18:05:02 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Tue, 13 Nov 2007 18:05:02 +0900 Subject: [Ultramonkey-l7-develop 69] Re: =?iso-2022-jp?b?bG9nZ2luZxskQiVpJSQlViVpJWokTkpROTkkSyREGyhC?= =?iso-2022-jp?b?GyRCJC0kXiQ3JEYbKEI=?= In-Reply-To: <473962D2.30703@yes.nttcom.ne.jp> References: <473962D2.30703@yes.nttcom.ne.jp> Message-ID: <473968BE.30805@yes.nttcom.ne.jp> TO:高丸様 中居です。 本文中にコメントを入れさせていただきます。 > 今回、ログ機能の機能UPを考えており、 > 強化の方針として以下の2点を考慮しております。 > > ・通常運用時に最低限必要な情報のみをログ出力することにより > 　パフォーマンスを上げる > ・保守、トラブル対応時に切り分けができる十分な情報を提供する 上記理由は相反するものと思われますが、どのように解決するのでしょう? 現状でもvanessa_loggerにはDEBUG出力と通常出力がありますが、 それでは不足する理由はありますでしょうか? > そのため、vanessa_loggerの代わりにapacheのlog4cxxを > 採用することを考えております。 > > 理由と致しまして、 > ・ログレベルという概念があり、指定されたレベル以下のログを > 　出力しないようにできる > 　（コーディングでは先にログレベルを判定し、文字列生成の > 　　コストも抑えるようにする予定です） > > ・カテゴリという概念があり、ログをカテゴリで区別し、 > 　カテゴリ毎にレベルを設定することにより、 > 　問題領域に的を絞ったログを出力することができる log4cxxのデメリットとしてはどのような点がありますでしょうか? また、log4cxxを導入する場合他のapache logging programのように logの設定をどのように保存するんでしょうか? どうぞよろしくお願いいたします。 From makoto ＠ kanon-net.jp Tue Nov 13 21:52:21 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Tue, 13 Nov 2007 21:52:21 +0900 Subject: [Ultramonkey-l7-develop 70] Re: =?iso-2022-jp?b?c3luYxskQjUhRz0kSyREJC0kXiQ3JEYbKEI=?= In-Reply-To: <007f01c825c8$45bde960$df4b850a@NTT47BF06BD9FE> References: <007f01c825c8$45bde960$df4b850a@NTT47BF06BD9FE> Message-ID: 木谷 さま 竹林です． お疲れ様です． ＃ そんなに気張らなくて OK ですよ（汗 > 今回、sync機能を使用するプロトコルモジュールの追加に伴い、 > sync機能の見直しを考えております。 今までのバージョンで sync が必要なものとしては，chash，urla が ありましたが，他にも何か追加したいものがある，ということでしょうか． 後に SSL Session ID というキーワードが出ているところを考えると， 中居さんがおっしゃるように，SSL Session ID を見るような プロトコルモジュールを追加する方針だということになりそうですが． 何にせよ，プロトコルモジュールのバリエーションが増えることについては Welcome です． > 複数モジュールの情報の同期に使用することから、同期情報が > 入っているメモリをsyncで一括管理し、一定量ずつ定期的に > 送受信を行うようにしたいと考えております。 l7vsd に sync のバッファを管理させて，プロトコルモジュールに 払い出す方式，ということで良いでしょうか． つまり，今までのように shared buffer に情報を持たせて外部のツールに 同期を任せるのではなくて，l7vsd に内蔵してしまうという形． もしこの方式であれば，問題なくできそうですね． どんな方式を考えていらっしゃるのか，もし考えをお持ちであれば 教えていただけますか． たとえば・・・ 「l7vsd で大きなメモリを一括で確保して，それを一定サイズに分けて プロトコルモジュールに払い出す．メモリの使い方は プロトコルモジュールに任せてしまい，同期を担当するモジュールは 単純にメモリの同期のみをする」 など，より具体的な実現方法があればベターですが，まだ構想段階で あるならば，ML の場で練ることも一つの手段です． よろしくご検討願います． ---------------------------------------------------------------- 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 CC FP : 7456 70EE 0A68 BC95 B1FC F78F C6A9 3E0E F798 A218 ---------------------------------------------------------------- *** Yumi Kitani wrote in message <007f01c825c8$45bde960$df4b850a ＠ NTT47BF06BD9FE> *** Subject: [Ultramonkey-l7-develop 66] sync機能につきまして *** Date: Tue, 13 Nov 2007 16:39:07 +0900 > UltraMonkey-L7-Devの皆様 > > はじめまして、NTTコムウェア UltraMnokey-L7開発メンバーの > 木谷と申します。 > 以後、宜しくお願い致します。 > > 今回、sync機能を使用するプロトコルモジュールの追加に伴い、 > sync機能の見直しを考えております。 > > syncが必要と考えている情報は、以下のものです。 > ・Cookie　Persistence Hash 情報 > ・URL Persistence Active 情報 > ・SSL Session ID 情報 > ・QoSの重み値 > ・sorry flag > > 複数モジュールの情報の同期に使用することから、同期情報が > 入っているメモリをsyncで一括管理し、一定量ずつ定期的に > 送受信を行うようにしたいと考えております。 > > 是非皆様にもコメント等、色々と御教授頂けたらと思いますので、 > 宜しく御願い致します。 > > > > ****************************************************** > Yumi Kitani > mail ： kitani.yumi ＠ nttcom.co.jp > ****************************************************** >