Kouhei TANUMA
tanum****@nttco*****
2009年 1月 15日 (木) 11:41:31 JST
UltraMonkey-L7
Fork皆様
田沼です。
お疲れ様です。
私は 案2 かなぁと思います。
> [案2] hash化対応sslidモジュール一本化
> 但し、レプリケーション対応は基本的に行なわず、ニーズ確認した上で
> 入れ込む。（ニーズがなければ未対応のままとする）
まず今回の実装での変更点についてまとめておきます。
1. シーケンシャルからハッシュに変更
2. レプリケーションできない
3. timeout がきかない(たぶん)
4. maxlist の上限まできた場合、一番古く作成したものが削除される(たぶん)
(既存は一番古く使われていないものが削除される、つまり
SSL-ID が一致した場合にリストの一番後ろに回している感じ)
次にこのモジュールの存在意義について。
このモジュールは Session ID を使ってクライアントとリアルサーバの
セッションを維持する機能を持っていますが、その目的は SSL のハンド
シェイクの負荷を軽減させてスループットを上げることだと思っています。
つまり、カートに商品をいれて…といった Web アプリケーション用の
セッション維持モジュールではないと思っています。
理由はブラウザが定期的に Session ID を変えるので、維持できる時間が
短いからです。
そう考えると、上記変更点の 2, 3, 4 はそれほど大きな影響を及ぼすもの
でもないと思います。いかがでしょうか。
なので、私は 案2 で、次点で 案4 でしょうか。
On Wed, 14 Jan 2009 11:43:02 +0900
Hideaki Kondo <kondo****@oss*****> wrote:
>
> 竹林さん、各位
>
> 近藤です。
> お疲れ様です。
>
> 標記の件について、少し確認したいと思っていたところ
> でしたので、レスさせていただきます。
>
> On Wed, 14 Jan 2009 11:08:44 +0900
> Shinya TAKEBAYASHI <makot****@kanon*****> wrote:
>
> > たけばやしです．
> > 今日は一段と冷えますね．
> >
> >
> > sslid モジュールの hash 化をしてみましたが，期間中に replication に
> > 対応できませんでした．
>
> ★
> 今回レプリケーション対応できない場合、既存のレプリケーション
> 対応版sslidモジュール（シーケンシャルサーチ）は残したままで、
> 今回のhash化対応sslidモジュールを追加するということでしょうか。
> それとも、既存版は無くして今回のsslidモジュールで一本化する
> という考えでしょうか。
>
> 私の意見としては、hash化版にレプリケーション対応が完了し、
> 性能や品質面の上でもシーケンシャルサーチ版を捨てても問題ない
> と判断できてから、一本化した方が良いと考えますので、念のため
> 確認させてもらっております。
>
> > チケットはオープンのままにしておきますので，今回のリリースでは
> > まだ replication に対応できない，という整理でお願い致します．
>
> ★
> レプリケーション対応できない場合、上述のように今回のリリース版
> ではどのように対処するかを整理し、関係者間でコンセンサスを得ておく
> 必要があると思います。
> 以下のように、何パターンか対応案を提示いただき、関係者で決める
> べきかと考えます。
>
> [案1] hash化対応sslidモジュール一本化
> 但し、レプリケーション対応は早期（次期リリース等）に入れ込む
>
> [案2] hash化対応sslidモジュール一本化
> 但し、レプリケーション対応は基本的に行なわず、ニーズ確認した上で
> 入れ込む。（ニーズがなければ未対応のままとする）
>
> [案3] 既存レプリケーション対応シーケンシャルサーチ版sslidモジュールと
> 非レプリケーション対応hash化版sslidモジュールの二本立て
> 但し、後者は早期に（次期リリース等）にレプリケーション対応を行う。
> 同時に一本化可能であれば一本化する。
>
> [案4] 既存レプリケーション対応シーケンシャルサーチ版sslidモジュールと
> 非レプリケーション対応hash化版sslidモジュールの二本立て
> 但し、後者のレプリケーション対応と一本化は、ニーズ確認した上で
> 入れ込む。ニーズがなければ未対応のままとする）
>
> 以上よろしくお願い致します。