Windowsを入れ直す


 ごちゃごちゃやってるうちにWindowsが微妙におかしな挙動を示すようになってきた。
 つーかレジストリが致命的におかしくなってる雰囲気。HDDのエラーチェックもしてみたが、特に問題は出ていないようだ。レジストリとなるとさっぱり分からんぞ。
 ということで、CDからの修復インストールを試みたが、却って悪化した。うむ。仕方ないので入れ直しだな。

 うちのHDDは単一パーティションなので、再インストールの時にクイックフォーマットは使わない。
 で、そうするとWindowsのインストーラは、\Windows以下を削除して入れ直そうとする。はず。普通はそこに大事なデータは何も入ってないだろうから、気にすることはないよな。マイドキュメントの実体が移動したりするが、まあそれでも新PCに移行するのと同じ手間だな。

 つーことで入れ直す。めんどくせえ。

 そして、何とか環境が落ち着いてきたので、blog更新。
 ATOKが見付からないのは地味に困るなあ。やっぱり変換精度がどうも…。

 あと、SSH2の為にPuTTYごった煮版を使ってたけど、やっぱりTeraTermの方が馴染むなあ、と思って検索してみたら、今はオープンソースの後継版(原作者公認)があるようで。SSH2対応版TTSSHも同梱らしく。
 ということで、そっちに移行する。

 SSH2な秘密鍵はPuTTYで作ったのだが、拡張子がppkとかなってて、TeraTermでそのまま使えるかどうか怪しい。ファイルの中身をちょろっと見てみると、何かいかにも互換性が無さそうだった。ふむ。どうすんべ。
 何となくputtygen.exeを起動すると、「既存の秘密鍵の読込」とかいう項目があったので、まず読み込む。
 で、メニューバーを見ると「変換」→「OpenSSH形式へエクスポート」なる物が。これだな。生成しよう。オーケーオーケー、接続成功。
 つーか、TeraTerm側に付属の鍵生成ツールは激しく貧弱だし、puttygen.exeで生成してエクスポートする方が便利なんじゃ、と思った。というより普通はリモートシェルでUnix使えるだろうからssh-keygenで…、は駄目だな。リモートで秘密鍵とか(笑)。

 まあ、大体の環境は戻った。
 Webアプリに走る人の気持ちが少し分かった気もした。でもうちのAthlon64 3500+だと結構重いんだよな。C2Dな環境でiGoogleとか触ったら軽かったけど、それでもまだ重い。ネットワークのレイテンシはビジネス用途なら隠蔽可能だろうけど(ゲームですら隠蔽出来てるんだし)、単純にローカル処理が重い印象。
 とはいえ、時間の問題かもなあ。Webアプリで済むんなら、お高いWindowsである必要ってほとんど無くなるんだろうか。とは言っても、アプリの蓄積が半端じゃないよなあ。俺はゲームやりたいから当分逃げられないだろうし。

 そーいやWordPressの記事エディタって自動保存までしてくれるのな。書き掛けて速攻捨てたはずのエントリが下書きで残ってたりするんで何かと思ってたが。Ajax面白いな。ババーン。チャーチャラララーチャラララー。昔のコナミは良かったな畜生。七面だっけ、超あり得ない速度で落下する敵要塞っぽいの。自機周囲にいきなり湧いてぐるぐる回って止まって突っ込んでくる敵が好きでさー。四面のボスの攻撃が嫌いでさー。あとどこだったか忘れたけど、ボス絡みで突然死バグもあったよな。そろそろボケが長いな。
 まあ、自動保存してくれるなら何も気にならないんで、さらばAreaEditor。
 でもさー。textareaの仕様がそもそもタコなのはどうにかならんのかね。ESCでリセットとか余計なお世話だっつーの。


Sitemap protocolに対応してみる


 何か最近は検索エンジン用にサイトマップ情報をXMLで提供するプロトコルがあるらしい。
 詳細はsitemaps.orgにあるらしいんで、見てみる。さりげに日本語版もあるな。

 で、興味のある部分だけをざっと読む。
 設置場所はどこでもいいのかと思ったが、設置場所と同等以下のパスしか拾わないらしい。要は、サイトマップファイルはツリーのルートに置いておけ、と。まあ自然だよな。セキュリティ的にも実装的にも。
 検索エンジンへの通知は、robots.txtに書くか、検索エンジン側で規定したURLにpingを送るか、検索エンジンがそれぞれ勝手に作ったI/Fにどうにかするか、の三通りあるらしい。ふむ。robots.txtが楽だな。

 つーか、WordPressだとGoogle XML Sitemapsプラグインを入れれば一発なんで、そうする。検索エンジンへの通知も勝手にやってくれるようだ。
 でもまあ、robots.txtも書いておこうか。

 …日本語版のプロトコル説明が変なことになってるな。
 具体的には、以下の一行をrobots.txtに追加してください、となっている。

サイトマップ: <sitemap_location>

 そこ翻訳しちゃ駄目だと思うんだ(笑)。
 で、英語版を確認してみる。

Sitemap: <sitemap_location>

 んじゃそれで。
 うちの場合だと、

Sitemap: http://mk.miko.jp/blog/sitemap.xml

な訳だが、blog以外のとこに何かコンテンツを置こうと思った場合、複数Sitemapとかrobots.txtに書けるのかなあ。
 ということで、良く見てみる。ふむ。複数のサイトマップを置く場合、サイトマップインデックスファイルとやらを作らないといけないようだ。めんどくせえなおい。
 まあ、今のところmk.miko.jpはblog専用だから要らないな。こういうのは必要も無い時に急いで入れても損だ。普及が進めばツールの整備も進むもんだし。

 そうそう、WWWCなどの更新チェッカーを使ってる場合、RSSフィードをチェック対象にするか、このsitemap.xmlを更新対象にするのがいいんじゃなかろうかとか。後者ならHEADで取れそうな気もするし。
 ただ、コメントの変更を検知するにはコメントRSSフィードをチェック対象にしないと駄目な予感。二ヶ所チェックか、それともコメントはトップページのサイドバーを視認することでチェックするか、かなあ。うーん。WWWCのMetaタグに対応するプラグインとか無いすかね。


suEXECを諦める


 つーか、eAcceleratorを入れたお陰でプラグインを増やしても重くならないので、それならwp-cacheを入れる意味もあるんじゃないのか、と思ったのだ。
 んで、結果から言うと、全く変わらなかったんで外した。一番効いたのはeAcceleratorで、次がMySQLクエリキャッシュで、その他は今のところ効果なし。入り口が0.2secならもう十分じゃないかって気もするけど。シングルエントリだと0.08sec切ってるし。うちじゃもうブラウザのレンダリングの方が遙かに重いし。

 そんなことをしているうちに、新鯖でもそろそろsuEXECを導入したくなる。chmod o+rwxとか気持ち悪いし。
 が、portsからどう入れるんかなー、とか思ってるうちに何か面倒な気分になってきた。インストールオプションもどこに保持されてるんだったっけ。/var/db/ports/*/optionsか。これ削除しちゃって、portupgrade -f apacheとかでいいのかなあ。
 いいようです。勢いでsuEXEC入れるか。

 と思ったところで、よくよく考えてみる。
 普通はPHPはモジュールで実行している訳です。
 普通はApacheの子プロセスはroot権限じゃない訳です。
 えーと。まさかPHPモジュールに入ったところで親に依頼してsetuidするとかいう器用な真似は…。無いよなあ。

 一応調べてみる。PHPでsuEXECするならCGIとして走らせろ、ということらしい。
 オーケーオーケー。諦めよう。
 うう、嫌だなあ。

 平文でCGIやらPHPやらのスクリプトにパスワードを突っ込んだ場合、suEXECでないApacheだと、同じ鯖でCGIの類を自作出来るユーザーには中身だだ漏れになる。慣れた人なら10分掛からずにo+r権限のディレクトリやファイルをブラウジングしまくれるページを設置出来るはず。でも、ここまではsuEXECな鯖ならば防げる訳だ。パーミッションが適切なら。
 ただ、suEXECな共用鯖でも、PHPがCGIでなくモジュールとして動いていると駄目な訳で、PHPでこの手のツールが出回ったら結構な面倒がありそうだよな。
 つーか、大胆な穴だよなあ。いやまあ、放置されてる訳ではないんだろうけど、対策が進んでないというか。うーむ。

 まあ、共用鯖上のファイルに平文で格納されるようなパスワードは、完全にその場限りの捨てパスワードにしとかないとやばい、と。
 と言っても、みこ鯖は共用じゃないからほとんど心配は無いのだが。


eAcceleratorを入れてみた


 舌の根も乾かぬうちにPHPをチューニングするのだった。
 つーかコードキャッシュを入れよう。そうしよう。

 世間的には、APC、XCache、eAcceleratorの三つのどれかが無難らしい。つーか何でPHPのエンジン絡みってこんなに多いんだ。本家が微妙だったりするのか?(笑)
 ともかく、評判を検索してみる。

 ふーむ。XCacheはセグメント例外で落ちたりするらしい?
 んでもって、APCもFreeBSDではセグメント例外で落ちたりするらしい?
 eAcceleratorはとりあえずそういう話は無いっぽいのかな。んじゃそれで。

 で、portinstall eacceleratorして、インストールログの最後に「/usr/local/etc/php.iniに一行追加してね」とか「/tmp/eacceleratorを作ってchownしてchmodしてね」とかあるんで、そうする。そしてapachectl graceful

 お、blogトップページのレンダリングが0.27secから0.15secまで減ったぞ。わーい。
 正直ここまで来ると、他の要因の方が大きくなってくるんで、僅かな体感にしか影響しないようだ。管理画面の切り替えとかが気持ち軽くなったのは一応分かるけど。
 つーことで、安定してたらこのまま使うけど、何かあったらすぐに外そう。


WordPressをチューニングする


 ふと思い出したが、MTの頃にものすごく投稿が億劫になっていたのは、管理画面に入る時に五秒くらい待たされていたからだと思う。再構築なんかもっとひどかったから、ちょっと書き直すのだって一仕事だった。同じMTでも新鯖ならだいぶマシそうな気もするけど。
 コードはMTの方がWPより圧倒的に綺麗らしいんだけどなあ。そもそもPerlとPHP自体が略。
 結局のところ、時間食わない物が一番有り難いってのはあるかもしれない。

 とまあ、そんなことを色々と考えていた訳ではなく、単にチューニングで遊びたくなったので適当に調べた。

 まずはwp-cacheプラグインを入れてみたが、0.3secくらいだったレンダリング時間が0.33secくらいに上がったので、何となく外す。高負荷になれば強いタイプかもしれないが、まあ、うちには関係無いでしょう。

 次にMySQLだが、query_cache_size=20Mとかにするといいらしいな。日本だと32Mの方が流行ってるのかな。まさかUTF-8だと漢字一文字3バイトだからとかか。まーいいや何でも。
 つーことで、/etc/rc.confにmysql_flagsを色々と書き加えたが、何か起動しねえ。ログもどこにあるやら。面倒だから/etc/my.cnf書き換えるか。くそう。
 んで、/usr/local/etc/rc.d/mysql-server restartと。
 ふむふむ、レンダリング時間は0.27secくらいまで減ったな。微妙だな(笑)。まーいいや微妙でも。でも今後のメンテが面倒になるようなら外すかも。

 次はPHPかな。
 プリコンパイル状態でメモリにキャッシュするツールがある、と考えればいいのかなあ。効果はありそうだが、設定の書き換えがかなりあるようで、メンテが面倒になりそうな気がしたので見なかったことに。
 TRASYS Wikiとかも軽くなるかもしれないけど、既に軽いしなあ。

 まあ、現状で全く不自由していないし、これ以上は大して速くならないんじゃないかって気もしてきたので、この辺にしとくか。