From nakai.norihisa ＠ yes.nttcom.ne.jp  Thu Aug  9 16:53:14 2007
From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa)
Date: Thu, 09 Aug 2007 16:53:14 +0900
Subject: [Ultramonkey-l7-develop 44]
	=?iso-2022-jp?b?aW9tdXgbJEIkTiVHITwlPzk9QiQkSyREJCQkRhsoQg==?=
Message-ID: <46BAC7EA.7060809@yes.nttcom.ne.jp>

TO:竹林様、UltraMonkey-L7開発者の皆様

お世話になっております。
NTTComwareの中居と申します。

前回、ヘッダ分割のくだんは説明させていただきました。
今回はL7vsdでの一番重要な部分であろうと思われるimoux構造について説明させ
ていただきます。

今回UltraMonkeyの速度アップを念頭に以下の部分に注目しました。

1)iomux-listがリスト構造になっているため線形検索になっている
	→epollへの変更によりリスト検索は無くなる。また、GHashによりfdでの検索を
可能へと変更にする。

2)iomuxがclientからの接続でmalloc,freeを繰り返すためメモリ確保のコスト、
　及びメモリ位置が飛び飛びになるためCPUのキャッシュタグから外れる可能性
が高い。
	→CPUのキャッシュは経験則的なものでしかないが、連続的であったほうがパ
フォーマンスが良い(特にCore2Duo系は2ndキャッシュのタグサイズが24byte単
位?なので連続しているほうが利用効率が良くなる傾向)。また、malloc/freeの
コストは大きいため(STLのvector<typename T>などでもpush_back( typename T
)するときはある程度の個数を一気に確保してmalloc/freeのコストを低減している。
	そこで、最大接続数x2 + α(configやlsockなどのiomux)をstaticに確保し、払
い出しを管理する方式とする。

3)iomuxに状態(status)を導入した。
	→現状ではGListの状態などを判断して駆動を行うが、複数回のepoll_wait()で
のrecv()及びwrite()、epoll_wait()をまたいだrecv()
/write()に対応するため(これは前回の話題にも出たように、一つのfdへの処理
の集中をなくすためです)、iomuxの状態で遷移する状態マシンとするため。
それぞれにフラグを持たせても良かったのですが、iomuxの状態は一意に決まる
ものであるため、状態マシンとしました。

パフォーマンス的に気になる部分はほかにserviceのconn_listがありますが、
(コネクションが作成/消滅ごとにlistのシーケンシャルサーチを行っている)
iomuxに関してパフォーマンス的な(特にコネクション数が多くなったときの)
改善項目は上記のようになります。

select -> epollへの変更は以前お話させていただいたように、
(それ自体では)現状であまり処理コストが変わらないように見えますので、
上記のようにL7vs-0.6.0でのボトルネックになるであろう部分のリストアップと
それに伴う、改善策を提示させていただきました。

どうぞ、よろしくお願いいたします。