日々の破片

_ masuidrive問題

masuidriveさんのところに問題が出ている。

早くもmoroさんが別プロセスキャッシュ生成君という案を出している。

twitterだと、僕が見た範囲では最速配信さんが（一言で言えば）Rails捨て案かな。

おもしろそうな問題なのだが、Feedの例が逆に邪魔をして、問題を還元しにくくなっているように思える。というか、僕は何が論点なのか最初読んだ時点ではわからなかった。あまり生にかけないからかも知れないけど。

というか、Railsを捨ててキューを利用する（MOMとまでは行かないのだろう）フレームワークを自作するにあたってのコメントを求むということなのだろうか？

中島さんのところのマルチスレッド・プログラミングの落とし穴、その２を読むと、論点は、CUDを別プロセスにどうやってするか、というところになっているのかな（更新即反映の要不要というのもあるようだけど）。

以下、雑多に考えたこと。

キューの実装には２種類ある。大雑把だけど。１つは揮発性のキューでメモリにためこむ。SystemVのキューとかがそうだ。マシンが落ちると消える。おそらくこれが許されるかどうかは情報の重み次第だけど、消えないほうが良いのだろうなぁ。とすると、不揮発性のキューを使わざるを得ない。そのためには、そこでDISK I/Oが発生せざるを得ない。このDISKをどこに配置するかというのも論点となる。中央DBサーバーが存在するとして、そこへ書き込むのか（通信後の書き込みとなる）、それとも個々のWebサーバーへ書き込むのか（場合によっては最速で済む）、ローカルRDBを使うのか、フラットファイルを利用するのか（後書き、先読みになるので、あまり向いているわけでもない）、マシンが落ちた場合、そのマシンに貯めたものはあとから拾えるとしても、順序がある時点で狂うことになる（1,2,3と送った場合、2と3だけ更新されて、3時間後に1がやっと入るとか。入れば受信時のタイムスタンプでソートできるだろうから順序は維持できるとは思うけど、ユーザーによっては不思議に思って1を再送して2十登録したりとかするかもーー負荷倍増計画となって、生き残ったWebサーバーに、さらに負荷が集中するから望ましいことではない、もちろんフロントエンドが1台ならその時点では良いけど）。

ローカルで良いのなら（マシンが落ちないという無茶な前提）、リクエストをシリアライズして1リクエスト1フラットファイルに書いて、かつメモリ上に覚えておけば良い。投げて結果が戻ったらファイルは削除。つまり読むのはあくまでもマシンが死んだときだけとする。もっとも書いている最中に死んだ場合にコミットされるのか、されないのならファイルに書くだけ無駄ではないかとかいろいろあるけど。

insertは遅いがupdateは速いというのもあるな、と突然、別方面に考えが飛ぶ。問題はインデックスの更新にあるからだ。無茶だとは思うが、あらかじめユーザーごとの更新を見越して空きをたくさん開けておいてupdateしていくようにするという手法は取れないだろうか。

ケータイからの更新（写真添付メールによる）を主にして、更新したよ通知をメールで返すとかしたらどうかとかすると、いくらでも（限度はあるにしても）間隔を開けられるな、とか。（mixiの場合、ケータイ更新を利用するユーザーが多くなれば多くなるほどWebの処理が軽くなるだろうなぁとか思う）

ディレイさせた更新の通知はCometが有利だとは思うけど（Ajaxの空読みだって負荷になる）、（ここを見えないJavaAppletでサーバーからの通知を受けて、それによってJavaScriptへイベントを通知し、そこでAjaxで取りにいくという方法はどうだろうかとか）、同期的に更新してその結果を返す処理でも間を開ける方法はいくらかはあるとは思うけど。

更新DBと読み込み専用DBの分離とか。

（Webサーバーでの処理優先順位）

特定ブラウザのみ高速という方法で、IEに合わせてXMLアイランド使ってしまうとか（作ったXMLを直接IEに食わせる）、その他のブラウザは普通にビューを使うとか。

あまりにとりとめがないから、TBするのやめた。

追記：プロセル→プロセス（tmtmsさんの指摘）