“「後の祭り」を招き寄せるシステム、後者を「いつでも祭り中」を可能にするシステム”
Second Lifeが閑散としてニコニコ動画が人気なワケ–カギはユーザー間の同期性:ニュース – CNET Japan
確かにねぇ。アーキテクチャの関係上、SecondLife は少人数向けのサービスしか対応できないと。そしてニコニコ動画の革新的な部分は時間の「疑似同期」であると。
時間の疑似同期ってすごい言葉だなぁ。言ってみりゃ、仮想的なタイムマシンてことでしょ。過去に起こった事象に対してアクションを起こせる。すごいなぁ。ニコニコ動画って前に投稿した自分のコメントを訂正することってできるのかな。それができるとしたら、過去の自分を訂正できるってことでしょ、それこそタイムマシンだよね。でも、それってファースト インパクトじゃないから面白くないよね。タイムマシンて面白くないものなのかな。
ところで SecondLife って三次元ですよね。これに仮想的な時間軸を実装したら四次元になるのではないかと。どうやって実装するのかは本物のタイムマシンを作るぐらい難しそうだけど。
【特集】期待度大のバージョンアップ – PostgreSQL 8.3の改良点を徹底分析 | エンタープライズ | マイコミジャーナル
石井達夫さんが書いた記事。
PostgreSQL 8.3 が間もなくリリースの様子。HOT とか ENUM 型のサポートとか、MySQL からの乗換えが期待できる機能が実装されている。全文検索が実装されるけど、日本語で使用するには面倒ね。チューニングは複雑になりそう。調整する部分がたくさんありますわ。
インデックス アドバイザのフレームワークが追加されるらしいが、うーむ。DB 管理者がアドバイザを実装するのか？たぶん誰かが実装したものを持ってくるんだろうな・・・。
SaaSとASPはもう区別がつかない状態、団体名も変更へ～ASPIC － ＠IT
確かに、って感じ。カスタマイズ性とか API の提供って付加的サービスでしかないと思うし。
スラッシュドット ジャパン | 545バイトのテトリスプログラム
これを読んで、JavaScript もやるなぁ、とか書こうと思って読んでいたのですが、最後の方のこのコメントに感銘を受けて別の方向に切り替えます。
マークアップ言語の目的は文書に構造的な意味づけをすることにあります。文書がどのように表示されるか、本来はマークアップ言語とは関係ない話です。
しかし世の多くの人はHTMLをデザインやレイアウトのためのツールだと考え、そのように使っています。これはwebページ作成史のなかでは大変不幸な出来事でした。とはいえ最近は企業も個人も、HTMLを表示用ツールとして使用した場合、あまりにメンテナンスしていくのが大変なので別の方向を探りつつあるようです。
webブラウザはそれぞれの仕様でHTMLを読み込んで表示しているだけです。HTML側にはどのように表示すべしという目的なんてありません。表示目的でHTMLを使用したらえらい苦労が待ってる、ということに気づくのは、HTML学習者が一度は通る関所のようです。
そうですよね、HTML ってマークアップ言語であってビジュアルをどうこうする言語じゃないんですよね。ビジュアルをしっかりしたいなら他の方法を模索するべきだ。でも、そのちょっと前のコメント、
HTML＋ブラウザは、View層を担当していると考えられる
ってのも同意します。だけど MVC モデルのビューってのはプログラム言語であってはならないとも思います。MVC モデルの純粋にプログラムな部分はコントローラのみであるのが美しい。モデルは DB につっこんで、ビューはブラウザにまかせる。こんなプログラマになりたい・・・、かも。
英政府による史上最大の個人情報紛失–被害2500万人で歳入関税庁長官が辞任:ニュース – CNET Japan
すごいっすねぇ、2500 万人ですよ。東京都ふたつ分です。にしても東京都って日本の人口の 1 割がいるんですね。
東京都区市町村別人口の予測（統計表） 平成１９年３月公表
ちなみに 23 区の人口密度からひとり当たりの面積を計算すると約 75 m
Google の上のほうに出てくるサイトから情報を集めてみた。うちではこんな感じで。
SearchEngine biglobe.ne.jp q=
SearchEngine cache.yahoofs.jp w=
SearchEngine excite.co.jp search=
SearchEngine goo.ne.jp MT=
SearchEngine google.co.jp q=
SearchEngine infoseek.co.jp qt=
SearchEngine msn.co.jp q=
SearchEngine search.biglobe.ne.jp q=
SearchEngine search.msn.co.jp q=
SearchEngine search.nifty.com Text=
SearchEngine search.yahoo.co.jp p=
SearchEngine yahoo.co.jp p=
SearchEngine yahoo.co.jp q=
Apache の MPM、prefork と worker について検証してみました。MPM ってのは Multi-Processing Module の略で、大量のリクエストを円滑に処理するためにどうするか、ってのを実装している部分です。Apache では、このようなソフトウェアの中核とも言える部分をモジュールとして交換可能にしているのです。すごいですね。詳しくは Apache のドキュメントを読んでください。
マルチプロセッシングモジュール (MPM) – Apache HTTP サーバ
で、prefork と worker の違いは、子プロセスの起動方式がプロセスかスレッドかっていう点ですね。prefork は アクセス数＝プロセス数 なのに対して、worker は アクセス数＝スレッド数 になる。ただ、大量のスレッドを 1 つのプロセス内で実行すると弊害があるようので、worker はいくつかの子プロセスを起動し、その中に数十のスレッドを担当させる。詳しくは Apache の
ドキュメントを・・・。
一般的に知られた MPM は prefork だと思います。アクセス数がプロセス数として見えるのでイメージしやすく、サーバとしての安定性も高いので、広く使われています。昔の Apache はこの実装しかなかったと思うので、古くから使っている人は気づかずに採用している人も多いのでは？最新版の Apache 2.2.6 でも Linux にインストールする場合のデフォルトは prefork です。
prefork はプロセス ベースの制御なのでプロセスの特徴がそのまま出ます。子プロセスの起動に時間がかかる、子プロセスごとに独立したコンテキストを持つ、など。起動が遅いのは、昔から言われる CGI は遅いって話と同じなので説明しません。コンテキストってのはプロセスが触れるメモリの範囲みたいなもので、各プロセスはメモリ上で干渉することなく稼動することができます。逆に言うとプロセスごとにメモリを占有していくので、大量にアクセスが来てプロセスが大量に起動するとメモリ不足に陥ります。悪くするとスワップを利用することになり、レスポンスが非常に悪くなります。
最近のマシンは性能が良くなっているので、Web でちょこちょこするだけで CPU が悲鳴を上げることはありません。なのでたくさんリクエストを受け入れられるようにするためにはメモリを効率的に使用する必要があります。プロセスが大量に起動する prefork MPM だと良くないんですよね。
というわけでスレッド ベースで処理をこなす worker ってのが出てきます。スレッドってのはプロセスの中にあります。コンテキストは独立しているものの、ある程度はプロセスの中で共有しています。ここが少し微妙で、Apache のモジュールがスレッドに対応していないと、予期しないエラーを発生する可能性があるので注意が必要です。でも共有できるところは共有してしまうのでメモリの消費を抑えることができます。
ちなみにスレッドにしたからって CPU の処理効率は変わりません。
じゃあ、worker にしたら prefork と比べてどれだけ効率的なんだよ、と思ったので検証してみました。Apache は 2.2.6、OS は Gentoo Linux です。worker、prefork 共にデフォルトでした。worker は子プロセスごとに 25 のスレッドが立ち上がります。apache2ctl -k start で起動し、ab で http://localhost/ に対して 1000 クライアントで 10000 アクセスをかけてみました。そして直後の子プロセスが占有している物理メモリを計算して比較しました。
結果は歴然です。prefork だと 約 200 プロセスで物理メモリの消費は約 350 MB なのに対して、worker では約 15 プロセスすなわち約 375 スレッドが立ち上がっているけど、約 40 MB しか物理メモリを消費しませんでした。すごい差ですね。ここまでとは思いませんでした。まぁ、PHP とかを動かしたら話は変わるだろうけど。
メモリ以外にも体感的な違いがありました。大量アクセスをかけてる最中に ab がアクセスを待って停止することがあったのですが、worker よりも prefork の方が長く感じました。詳しいことは知らないけどー。
結果を続きの方に入れときます。
neko をやってみた。
まずは neko のソースをダウンロード。
http://nekovm.org/
解凍してディレクトリに移動。あれ？configure がない。ないんだ、変なの。てことで make。make の最中に見つけられないライブラリへのパスを聞かれるので、それに答えるとコンパイルが完了。あとは make install。あれー、mod_neko.so がないなぁ。あー、mod_neko2.ndll か。なんだ、ndll って。まぁいいか。
とりあえず Hello World ですよね。
http://blog.asial.co.jp/251
このブログでは hello neko world ! だったけど、僕は Hello World!! です。ここは技術者としてのコダワリがでますよねー。実行は neko hello でも neko hello.n でも OK。確か Java もそうだっけ。
これやって neko に慣れよう。
Linux のカーネルに、こんな素晴らしいオプションがあるのを初めて知った。
Chroot jail restrictions
chroot 内での権限をさらに剥奪するものだ。/proc 内は自分のプロセスが関係するものしか見れなくするとか、mount の禁止とか、mknod の禁止もできる。こりゃいいや。今まで怖くて /proc を chroot 内にマウントしていなかったが、これで権限を調整すれば安心してマウントできる。デバイスファイルも置ける。
Apache のプロセス数について実験してみた。うちの Apache は thread です。なので prefork はどうなるか知らないけど、とりあえず。
まずは ThreadsPerChild をいじってみた。ThreadsPerChild は子プロセスごとのスレッド数を調整する値で、小さい値なら prefork に近づき、大きい値ならスレッドの強みを引き出すと考えられる。が、しかし、ThreadsPerChild の値を大きくしていくと 20 あたりを境に性能が落ちていくではないですか。こりゃおかしい。実は ThreadsPerChild だけではなく、MinSpareThreads もいじっていたためと思われます。MinSpareThreads だけじゃなく、MaxSpareThread、MaｘClients もデフォルトをベースに等倍していました。
MinSpareThread が大きくなると、大量の暇スレッドを用意するために子プロセスが乱立して、メモリ大食い＆プロセス起動のオーバヘッドが出てきます。なので ThreadsPerChild を大きくするついでに MinSpareChild を大きくしたため、無駄に子プロセスを発生させてしまった可能性があります。”可能性” って言うのは、リソース状況の取得をサボっていたためです。あー、これじゃ意味ねーわー。なんだかなー。でも、とりあえず vmstat で I/O wait は発生していないようだったです。
で、なぜ MinSpareThreads が大きすぎると弊害が出るかという話。例えばMinSpareThreads が 50 で ThreadPerChild が 25 だったらどうなるか。30 アクセスが来ると 2 個目の子プロセスが立ち上がります。そこでそれぞれ 15 リクエストを処理し、アイドルは合計 30 スレッドあります。てことは MinSpareThreads よりも小さいので、もういっこ子プロセスを立ち上げます。というわけでアクティブは 30 スレッド、アイドルは 60 です。これで設定を満たします。次に 50 アクセス来ると、さらに子プロセスを立ち上げる必要があり、プロセス数 4 のアクティブ 50、アイドル 50 です。
書いてて思ったけど、ここまで書く必要なかったかな～。結局、MinSpareThreads を増やすとプロセス起動のオーバヘッド＋メモリを喰うってことで問題があります。でも、それだけで性能に違いが出るのかなー。そこは疑問です。
本文の方に実験結果を入れときます。