スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Fasterfoxのリンクプリフェッチ機能 

FirefoxアドインにFasterfoxというものがある。やることはFirefoxのコネクション数のチューニングや表示ページにあるリンクのプリフェッチなどである。以前から存在するアドインであるためある程度こなれて来ているはずであると思い試してみた。
狙いは現在利用しているTweak Network Settingsがやってくれる同時コネクション数の変更やPipeline/Persistence Connectionの利用の有無設定に加えて、表示ページにあるリンクのプリフェッチ機能を利用することだ。リンクのプリフェッチによりブラウジングがより円滑かつ短時間で行えるはずだ。

Tweak Network Settingと機能がバッティングするため、まずはこれを削除してからインストールしてみた。まぁ、動くは動くのだけどプリフェッチの同時接続数や接続ごとの待ち時間などを設定できないように見える。つまりは表示したページから同一サーバへのリンクが多数存在する場合には、そのサーバに対して絨毯爆撃を仕掛けるということのようだ。
Fasterfoxは同時接続コネクション数の点で一般的な設定値や最大値がRFCを越えるとかサーバに過大な負荷をかけるとして最速インタフェース研究会などで批判されている。私としてはリンクプリフェッチによって絨毯爆撃を行うことの方が問題だと感じる。

ブラウザからの同時コネクションが少し位多くても単一ページに含まれる画像やフラッシュファイルなどを円滑に返すことのできるようサーバはチューニングされていることが多いはずだ。なぜならこうした要求は少数の動的コンテンツ(動的なHTMLファイルなど)と多数の静的ファイルという構成になるためだ。
しかしながらリンクプリフェッチの同時実行数が増加することはサーバに対して大きな負荷を与える。同時複数のリンクプリフェッチ実行は同時複数の動的コンテンツ生成をサーバに要求することになるからだ。例えばblogのエントリ一覧画面などでリンクを絨毯爆撃すると、サーバサイドではリンクされている多数のエントリデータを生成するため同時に多数のデータベースアクセスが発生するはずだ。

一般に動的コンテンツを返す処理は、画像などの静的コンテンツを返す処理よりもサーバの負荷が大きく時間がかかる。このためブラウザはリンクプリフェッチを同時には極少数のみ行うべきだ。リンクプリフェッチが同時に一つづつしか行われなければ、また更にリンクごとに待ち時間を開けるようになっていればサーバに過大な負荷をかけずにすむだろう。

Fasterfoxでは同時接続コネクション数を設定できるが、リンクプリフェッチの同時実行数は設定できないようだ。設定できる同時接続コネクション数が、リンクプリフェッチと表示ページのためのコンテンツ取得のために使用するコネクションの合計に対して適用されるのであれば絨毯爆撃をせずにプリフェッチできるかもしれない。
実際のところがどうなのか、もう少し詳しく試してみないことにはこれ以上のことは分からない。

P.S.
上記の通り書いたが、Fasterfoxのプリフェッチは望まないログアウトなど意図しない動作を防ぐため、特定の拡張子のみに対して行われるとのこと。(Fasterfox FAQ) よって絨毯爆撃による動的コンテンツ要求は非常に限定されたものとなるはず。また、現在はまだプリフェッチの同時並行数や要求間隔についての設定は見つけられないでいる。

スポンサーサイト

フリクションライン 

消せる蛍光マーカーで気になるものを発見。
PILOTのフリクションラインがそれ。
今までにも消せる蛍光マーカーは合ったんだそうで、そういえば自分も以前消すためのペンで消せるマーカーを使っていたことを思い出した。以前のものはマーカーの色数が限られており、色も発色が良くなかった。また、消すためのペンでなぞる事で消す、ということからも分かるように、インクの化学変化を用いているらしく消したところを再度マーキングするとうまく書けなかった。
今回のフリクションラインは、発色も良く色数も揃っており、消去/マーキングの繰り返しでも問題ない模様。温度上昇で消えるインクを使っているとの事で、マーカーの頭に付いているゴムでこする事で消えてくれる。実際に試したところ、きれいに消えてくれた。
Webにあるような「何度でも書き消し」が可能かどうかまでは試していないが、ちょっと試した感触からはうまくいきそう。インクが染み込むタイプの紙や、書いてから数ヶ月経った後での消去、特殊な紙での消去がうまくいくかは試していないので分からないが結構いい感じではなかろうか。
ITmedia Biz.gooニュースでも記事として取り上げられていた。
「効率アップ、クオリティアップのためのデジタル仕事術」を謳っているITmedia Biz.がマーカーを紹介するのはどうかと思うが。

Windowsプロファイルとブラウザキャッシュ 

以前「マイドキュメントやデスクトップの使用は危険だ」で特にドメインログオンの際などユーザプロファイルパスを指定している場合のプロファイルの扱いに問題があることを書いた。プロファイルにはディレクトリ「マイドキュメント」やデスクトップが含まれるが、その他にアプリケーションソフト用データディレクトリも含まれる。M$がプログラム開発者に対してどのようなガイドラインを示しているのか知らないが、主要なアプリケーションのある程度はディレクトリ

C:\Document and Settings\USERNAME\Application Data\APPLICATION_NAME\

にデータを保存するように作られている。ログインの際に指定されたプロファイルディレクトリ(しばしばネットワーク越しにアクセスすることになる)からダウンロードし、ログインしている間はここに読み書きを行い、ログオフの際に指定されたプロファイルディレクトリへアップロードする。

ログオフの際のアップロードは工夫されていて、ファイルが更新されているかどうか確認して、更新されていなければアップロードしないで済ませるらしい。(ファイルの日付やサイズだけでチェックしているのだろうか?) しかし、こうしたファイルが大量にあった場合にはログオフに長い時間がかかるようになる。(ログオフした後にプロファイルキャッシュは削除されないので、ログオンの際にも同様の工夫が利用されているのではないだろうか。)
私の環境ではログオン/ログオフに時間がかかっており調べてみたところ、ディレクトリApplication DataにはFirefoxキャッシュディレクトリが存在しており、3420ファイル、500MBytesが保存されていた。これだけのファイルを更新確認していれば時間がかかるのも当たり前だ。アップロードされているプロファイルと、ダウンロードしたプロファイルキャッシュの両方に沢山のキャッシュファイルが保存されているためディスク領域も無駄に使用していることになる。
Windowsの安定性の低さから同期を取れないというリスクが大きいことと、ネットワーク通信のコストが低く高速であることなどから、キャッシュするような作りではなく直接アクセスするようにするべきだ。

さて、Windowsに文句を言ってすっきりしたところでFirefoxのプロファイル(各種設定ファイル)をプロファイルディレクトリからホームディレクトリへ移動してしまうことにした。
(0)Firefoxの終了
Firefoxプロセスを全て終了する。
(1)Firefoxのプロファイルのコピー、プロファイルのバックアップ

C:\Document and Settings\USERNAME\Application Data\Mozilla\Firefox\Profiles\

にあるランダムな文字列のディレクトリがFirefoxプロファイル。これをディレクトリごとホームディレクトリ内の設定保存用ディレクトリなど適切な場所へコピーする。同時にバックアップ用にもコピーして、作業の際に災害を起こしてしまっても困らないようにしておく。
(2)Firefoxにプロファイル登録
コマンドラインなどから

"C:\Program Files\Mozilla Firefox\firefox" -p

と実行してFirefoxプロファイルマネージャを起動。後で使用するかもしれない場合には上記コマンドラインはショートカットとして作成しておいても良いだろう。[新しいプロファイルを作成]→[次へ]→[フォルダを選択]として、先ほどコピーした新しいプロファイルディレクトリを指定してやり[完了]
(3)新しいプロファイルで起動確認
新しいプロファイルの名前は変なものになっていると思うが後で名前を変更することにして、新しいプロファイルを選択してFirefoxを起動し、とにかくきちんと動くことを確認する。
アドオンは引き継がれていますが、正常に動作しません。一旦アドオンを無効化→Firefoxを再起動→アドオンを有効化→Firefox再起動、としてみて下さい。多分、大抵のアドオンはこれで動くんじゃないかと思います。
(4)古いプロファイルを削除
新しいプロファイルディレクトリでうまく動くことを確認できたら、Firefoxプロファイルマネージャにて古いプロファイルを削除する。同時に新しいプロファイルディレクトリで毎回起動するようチェックを付けてFirefoxを起動してやる。これでOK。
キャッシュをプロファイルから外へ出してしまうまでずっとログオン/ログオフに長い時間がかかる状態が続いていたが、作業後はログオン/ログオフにかかる時間が短縮された。Windowsプロファイルの軽量化(Windowsユーザのユーザプロファイルパスを指定している場合)により、ログイン/ログオフの時間短縮とディスク領域の節約を実現できる。

すっきり。

Firefoxのキャッシュディレクトリだけを変更するには次のようにして変更できる。
(1)まずは適当に操作して現在のFirefoxキャッシュファイルをクリアする。そうしないと古いキャッシュファイルが削除されないままいつまでも保存されることになる。
ちなみに私のFirefoxキャッシュディレクトリは1年以上も前に場所を変更していたのだが、気付かずにプロファイルディレクトリ内にずっと古いキャッシュを残したままだった。
(2)FirefoxにてURLに"about:config"と指定して表示すると設定項目が表示される。項目

"browser.cache.disk.parent_directory"

に希望のキャッシュ用ディレクトリを指定する。(ここで指定したディレクトリは存在していないといけないはず、必要に応じてディレクトリ作成しておくこと。)
(3)Firefoxを再起動。(再起動は不要かもしれない。どうだろう?)

ionice 

うるめねっと技研にて、ioniceを知った。I/Oスケジューラに対してプロセスの優先度を指定するというもの。裏で数GBytesのgzip圧縮を流しながら、Firefoxを起動したいと思ったときにFirefoxの起動を優先させることができるようになる。(大きなバイナリのアプリケーション起動は、CPUというよりはディスクI/Oがネックになっていると思う。まぁ、ioniceを実行する時間でFirefoxが起動したりgzip圧縮が終わっていたりしそうだけどね)
早速手元のFedoraCore5を見たところインストールされている模様。試したところ、実行はroot権限が必要な感じ。ふが日記に書かれているように、realtime classだけroot限定にしてくれれば一般ユーザで実行させても良いと思うのだけど。ちょいと不便。それはそれとして、

ionice -c 3 rm -rf tmp/沢山

なんてやればいいわけ。idle classを指定して大量ファイルの削除をさせてアプリケーション起動をさせてみたら実際ちゃんと後回しにしてやってくれている模様。
どうやらI/Oスケジューラでの優先度低下は、niceで変更すると一緒に変更してもらえるらしい。するってぇと何かい? 色々調べたのはあんまり意味ないじゃん。あれこれ考えずにnice/reniceしておけば大体問題なく実現できるってぇことだよな。
ディスクアクセスは大量に行うが優先度を下げて良く、かつCPUの優先度を下げたくない(ioniceが役立つ)場面はどんなのがあるんだろう? 何かあるのか? 大量のディスクアクセスを行いながら、割込みがあったら短時間で答えを返してやらないといけない、とか? しかもその処理のためにディスクアクセスが必要な場合には優先度が低い。どんな処理だ?
というか、Linux Kernel 2.6のI/O elevator CFQによって、かなりI/Oスケジューラが改善された、という結論で良さそうだ。それはそれで良いことだ。後は一般ユーザ向けにioniceを改善してもらえばそれで良いはずだ。

実際に試した所、niceでプロセスの優先度を下げた際には効果が見られなかった。niceによるプロセス優先度減少がioniceによるディスクI/O優先度減少も伴うというのは(少なくとも私の環境では)ないようだ。
しかしながらrootでioniceを実行した際には十分な効果が見られた。優先度を-c3(アイドル時のみ実行)として大量ファイルのコピー(cp -vrf SRCDIR DSTDIR)を行った所、他のディスクアクセス要求(ls -alF など)があるたびにファイルコピーが中断されているのを見ることができた。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。