HTTP のキャッシュで ETag ってヘッダが使われているのは知っていた。そんで画像を扱う案件がやってきたので、使ってみることにした。貧弱サーバっぽいので帯域を絞りたいのよね。
というわけで参考にさせてもらったのはここのページ。
drry @- PHP で Apache 風 ETag の生成
自分はファイルのサイズと最終更新日時のみを利用。実際、サーバは一台しかいないので i-node 番号がサーバによって異なるってのは気にしなくてもいいんだろうけど、外しておいた。
そんな感じで実装してみて、どうやら上手く行っている様子。サーバから投げた ETag がブラウザからの If-None-Match に入っている。
そういや、最初は Cake の MediaView で params に modified とか chache とか設定しないと動かなかった気がするけど、今になって消してみても大丈夫。気のせい？まぁ、いいか。
とりあえず今回は実際のファイルを利用したけど、DB の内容を基にするってのもいいかも。自分の会社だと Cake なので、割と created とか modified でデータを操作した日付を入れているので、そっちをベースに ETag を吐くとか。各サーバで作成したキャッシュファイルの日付とか見てたら、i-node を取り入れるのと同じ。
で、これでどれだけ軽くなるかは分からないが、上手く行くことを祈る。

久々に記事を書く･･･。
さて、地震などあったりして激動の一週間だったが、自分は納品してもらう HTML の日程が後ろ倒しになり、あまりやることのない一週間でした。おかげで三連休は家で埋め込み作業。あ、管理画面も作らなきゃなぁ。
ってなわけで、地震翌日に家に持って帰ってきた OpenVZ の開発環境に入り、最新のコードを持ってこようとしたのだが、svn up、うん、効くはずないよな。完全に異なるネットワークだ。踏み台サーバはある。だがリポジトリとして踏み台越しのサーバはどう定義するんだ？
ちょっと調べたら出てきた。Subversion の設定ファイル ~/.subversion/config で接続スキーマを定義すれば解決できるらしい。ポートフォワードしてスキーマにポートを定義って説明をしている人が多いっぽいけど、自分は都度 SSH を二段で発行させることにした。

[tunnels]
ssh_humihumi = ssh -A user@humidai.example.net ssh

humidai.example.net に ssh して ssh するってことです。rsync でもよくやるんだよね。-e ‘ssh -A user@humidai.example.net ssh’ とか。あ、rsync は –rsync-path に ssh コマンドを入れるってのもやるな。
で、後は svn co svn+ssh_humihumi://user@intra.server/path/to/repo って感じ。
ポートフォワードとどっちがいいかって？ポートフォワードの方が svn コマンド発行時のコストが低いけど、恐らく接続しっぱなしにすると思うので常にコストがかかる、って感じかな。まー、よっぽどリソースが限られている場合以外は気にしなくていいと思う。

“　「サーバサイドJavaScript」では、文字どおり、サーバサイドのアプリケーションの実装言語として、JavaScriptを使用します。JavaScriptをサーバサイドで使うことにより、クライアントサイドと同じ言語で開発でき、開発効率が上がることが期待されます。”

サーバサイドJavaScriptの本命「node.js」の基礎知識（1/3）- ＠IT
ってなわけで、仕事の合間で会社の開発マシンに環境を構築、HelloWorld.js を実行してみた。うーん、まさに「Hello World」。
っていうのを記事にするはずだったんだ。そう、nodejs の紹介なら、それで良かった。
でも、納得できなかったんだ。「シングルスレッドベースの非同期処理」が効率的だってことが。
まぁ、難しい話は学者さんに任せるとして、素人目線で話すと、単純にシステムが処理できる量は搭載されているリソースの量に比例するはずなんですよ。そして、実行したい処理の複雑さに反比例する。はず。
ってことは、シングルスレッドにしようがマルチスレッドにしようが、非同期処理にしようが同期処理にしようが、実行したい処理を減らせば処理できる量は増えるでしょ、ってこと。最終的に CPU に流れる処理量をどうコンパクトに収められるかってこと。
って考えると、問題は処理方式ではなく、トランザクションごとの処理量ではないのか。
ってことで、手元の Apache のモジュールを全 OFF して全 ON と比較してみた。
やったのは ab コマンドで静的ファイルを100000回100並列でリクエストし、その際の処理速度と、その間の CPU 使用率、直後の Apache のプロセス数と占有メモリ量 (vsz を積算) です。
やってみると、モジュールなしの場合、処理時間は 60%、CPU 使用率はユーザの比率が下がりシステムの比率が上がる、テスト直後のプロセス数はほぼ同じなのに対して、占有メモリは1割程度。
結局、Apache は大量のパッチを当てて高機能になり、重くなりがちなんだけど、重い原因は Apache のせいじゃないはずなんだ。重い原因はシステム構築者が手を抜いているから。まぁ、それぐらいシステムリソースのデフレが進んだってのもあるだろうけど。
みんな、もう一度 Apache のチューニングについて考え直すのも必要なんじゃないかと思うのです。