Firefox の「about:config」設定の若干の意味--反省をこめて

　私の書いた前回の記事にたいして「海外の記事を鵜呑みにするな」「一つ一つの設定の意味を明らかにせよ」と厳しいコメントをたくさんいただきました。

　このようなタイトルでブログを書いている以上当然のお叱りと受け止めただただ反省しております。

　にわか勉強で恐縮ですが、とりあえず Config の設定の意味を私なりに理解できる限りでレポートします。間違っていたら許してください。

　参考にしたのは「MozillaZine Knowledge Base」

â‘ network.http.pipelining
　「pipelining」は1回の接続で複数のリクエストを送る技術。通常は複数のリクエストがあった場合、一つずつ順番にサーバとのやり取りが発生しますが、「pipelining」によってサーバからの反応を待つことなく、連続してリクエストすることができます。HTTP/1.1 で初めて可能になりました。とくに遅い接続環境では大きな効果を発揮するとか。この図が私にはわかりやすかったですね。

　問題は、すべてのサーバーがこれをサポートしているわけではないこと。いくつかのサーバーはパイプライン化されたリクエストを受けると異常な行動をする可能性があるということですので、皆さんが再三指摘されたとおり、気をつけなければならないと思います。
　「true」なら pipelining を使うし、「false」なら使わないという意味。

network.http.pipelining.maxrequests
　最大リクエスト数の設定。デフォルトは「４」で、最小「１」から「8」までを設定できます。値が大きくなるほど、一度に送れるリクエスト数が増えます。
　前回の記事ではこれを「32」などとし、とんでもない無知をさらしました。元記事はちゃんと「8」になっていることさえ見落としていたことが情けないです。

â‘¡network.http.proxy.pipelining
　同様にプロキシサーバを使っている場合に、pipelining を可能にするかどうかを設定します。「true」ならばする、「false」ならばしないということです。

â‘¢network.dns.disableIPv6
　Mozillaではすでに対応済みの IPv6 ですが、OS や DNSサーバを含めてまだまだ IPv4 からの移行は進んでいませんね。
　IPv6 に対応した DNS サーバにおいて、IPv6 address がリクエストされたとき IPv4 address を返すといったバグが存在するそうです。Mozilla はこの誤りをリカバーできるそうですが、どうしても時間がかかってしまいます。よって設定を「true」とすることによって、こうしたミスを除いてしまいます。

â‘£Content.Interrupt.Parsing
　ユーザーのマウスを動かしたりキーボードをたたいたりという行為に反応するためにページの解析作業（Parsing）が中断されうるかどうか、を設定します。
　「true」なら、解析作業が中断されることがあるという設定です。「false」なら中断されることなく解析作業が完了します。

⑤Content.notify.interval
　Mozilla では1ページすべてダウンロードしてからユーザーに表示するというより、定期的にダウンロードされたものをそのつどレンダリングして表示しています。
　そのたびにダウンロード済みのデータに新しいデータを繋ぎ合わせる作業（接合作業）が発生しますが、これが頻繁に起こると大変な時間のロスになります。そこでインターバルを設けて、この作業のペースを設定します。
　デフォルトは 120,000microseconds（1 second = 1,000,000 microseconds）。この値を大きくすれば当然ロスが少なくなり、パフォーマンスは上がります。特に遅い接続環境では、100,000を下回るとパフォーマンスはきわめて悪くなるので薦められないということです。

â‘¥Content.max.tokenizing.time
　「content.notify.ontimer」と「content.interrupt.parsing」が「true」にセットされている場合のみ有効。
　接合作業と接合作業の最大間隔時間を設定します。デフォルトは「content.notify.interval」の3倍。この値を小さくするとページを読み込む時間の使い方により敏感になります。「content.notify.interval」の整数倍が好ましいとされています。

⑦Content.notify.ontimer
　接合作業が頻繁に起こらないようにタイマーを設定します。「true」ならば「content.notify.interval」で設定されたインターバル以上のインターバルで接合作業を行わない。「false」ならば、新しいデータがレシーブされるたびに接合作業します。

⑧Content.Notify.Backoffcount
　タイマーベースの接合作業の最大回数を設定します。「-1」ならタイマーベースの接合作業に制限を設けません（デフォルト）。「0」ならタイマーベースの接合作業を行ないません。

⑨Content.Switch.Threshold
　「content.notify.ontimer」と「content.interrupt.parsing」が「true」にセットされているとき有効。
　ページを読み込むとき、マウスを動かすといったユーザーの行為があるときは頻繁に読み込みを中断するモードに入るが、そうでないときは読み込みに専念するモードに戻る。数値は後者のモードの総時間を設定します。デフォルトは 750,000microseconds。値を大きくするとページを読み込む時間の使い方により敏感になります。

â‘©Nglayout.initialpaint.delay
　Mozilla applications はダウンロードした部分から徐々にレンダリングを行いますが、最初の表示に関しては有用な情報がある程度そろうまで待つようです。ここではその待ち時間を設定します。
　デフォルトは 250microseconds。値が小さいほど取り掛かるのは早くなりますが、レンダリングが完了する時間はむしろ遅くなるでしょう。

⑪User.Interface.Submenu.Delay
　メニューからサブメニューを開くときの時間差を設定します。「0」にすると時間差が「0」になり、レスポンスがよくなったように感じます。

â‘«PLUGIN EXPOSE FULL PATH
　アドレス欄で「about:plugins」と打ち込むと、インストール済みのplugin の一覧が表示されますが、これをフルパスに。速度とはあまり関係ないような。

⑬Browser.cache.memory.capacity
　キャッシュメモリの最大量を設定します。値を大きくするとキャッシュメモリから呼び出される割合が高くなり、体感速度はアップします。
　ただし上限があり、firefox 2.0 では、256 MB の物理メモリーに対して「10240KB」、512 MB の物理メモリにたいして「14336KB」、1 GB の物理メモリに対して「18432KB」以内で設定しなければならないようです。

　以上の内容に即して、前回の記事で修正しなければならないところは修正します。

　今回のレポートは 13 項目に関してだけでしたが、これらを含めて Firefox 2.0 のConfig の設定項目は 300 以上に上ります。

　これらの設定項目の意味を一つ一つ調べあげ、値を調節しながらパフォーマンスの向上を実験することが本来のオリジナル記事の条件なのかもしれませんね。そういうことを皆さんに指摘していただいたことはずいぶん参考になったような気がします。