------------------------------------------------
題：      効率的なNetNewsの配送とTop1000
時間:          13:20-13:50
発表者：  近藤　雄公 kondou@isc.org
記録者：  小野　一志、浦  宗陽

ターゲット：配送サーバー
　　　　　　INN2.3以降
　　　　　　diablo Cycloneは対象外

現状(2000/12/中)
    220GB/day（2年前 25GB/day、7.5ヶ月で倍増）
　　125万article/day（26,7ヶ月で倍増）

　　記事：
      量95％がalt
　　　数60％がalt

今後
    2001/5には　300GB/day
    leafへの配送には 30Mbps程度の帯域が必要（2001年4月くらい）

効率的な配送
　  配送量の割にサーバーの負担が軽い
  　帯域を無駄に浪費しない

  (1)サーバの負担を軽くする
    ・配送用とリーダー用は分ける
　  ・配送用サーバーにはoverviewは不要
    ・storage methodはCNFS
    ・ディスクを分ける
    ・inndのオプション -u はつけない
    ・newsfeedsのエントリ名はラベルとして使用し短くする
　    pathホスト名が長くなるとログ処理が負担になる
    ・historyはstripeされたディスクにする
　    IO待ちが長くなる
    ・history cacheは大き目に
    　ただし大きくしすぎるとメモリ不足になる
    ・cleanfeedは使わない（配送に徹する）
　  ・filterによるCPU負荷が上がる
    ・innfeedは複数プロセスにする
　    1プロセスでは100記事/秒が限界
　  ・プロセスを分ける場合は記事の大きさで分ける
    ・no back-logはtrueにする
    ・innxmitやihave/sendmeはやめる
　    即時配送しないとディスクIOが激しくなる
    ・配送が遅れがちなpeerへの対処

  (2)ネットワーク負荷軽減
    ・記事の重複
　　  複数のサーバーからほぼ同時に同じ記事が送られる
　  ・precommit cache

    負荷の軽減
　    相手がdiablo   2.0以降にしてもらう
　　　    　INN　　　2.3以降にしてもらう
            Cyclone  ???
      バージョンアップしてもらえない->同時接続数をへらす

  　受け取り側
　　  NNTPの431を解釈できること
　　　  diablo 2.0以前は無視する　no resend id をtrueにする

    activeにない
　    INNでwanttrashがture

    fullfeedならば wanttrash treu
    そうでない場合は必要なもののみ

    記事が大きすぎる場合
　    記事の大きさで制限をかける
　　    diabloはできない

    fullfeedの場合はfilterをはずしてもらう
    はずしてもらえない場合
    　記事の大きさで制限する->かなり効く


Top1000？
　・pathヘッダからサーバーのランキングしたもの
  ・いつのまにかサーバーの凄さを示す指標となってしまった
  ・peerの検討対象になっていたりする
  ・http://www.top1000.org

Top1000への潜入術
  ・流量より記事数を増やす
  ・peerを増やす
  ・トランジットになる
  ・記事は分散して受ける
  ・innfeedで配送する
  ・まずpeerをふやす
　・メンテを忘れずに

  Tips
    tfeed.maxwell.syr.edu/usepaths.html

質問
Q.ごみを撒き散らしている罪悪感？
A.お客様のため

Q.NNTPcacheなどがでているが
A.末端では意味があるが、配送ではスケールするか？

--------