ああもう7月じゃないですか。なんかもうばたばたと6月は終わっちゃいましたよ。スケジュールがぐちゃぐちゃになっちゃったなー。そういやいつのまにか俺もムスコもage++になってしまいましたよ。

で、おととい（6/29か）の朝から病院に行って、造影剤を使ったレントゲン撮影をしてきた訳ですよ。で、結局原因らしき影は見つからなかったわけですよ。腎臓には石があるらしいけど腎臓にある段階では別に痛くなくて、そこから出てきて尿管に詰まっているやつが痛みの原因のはずなんだけど、それらしいものは見つからない。

っつーか、実際問題検査を受けているときには痛くなかったからなー。あのとき痛かった原因はすでに流れてしまったのか、それとも尿管の痛くないどこかにレントゲンに移らない物質（そういう種類のものもあるらしい）として存在するのか。

ともかく医者的には「特に見つからないから、しばらく様子を見ましょう。三ヶ月後にもう一回検査にきてね。あるいは痛むようなら来てね」ってことでした。それ以外は特に注意はなし。せいぜい水をたくさん飲みましょう、くらいか。

まあ1回経験してしまえば、同じ痛みが襲ってきたところで耐えられるだろうけど、本当にまったく何一つ治療らしきことはしないんだなー。車の運転中とか混んでいる電車の中とか、痛みに耐えるのが難しいシチュエーションで起こらないことを祈りながら、ふつうに生活するしかないか。

なんか最近うちのサイト（というかサーバー）がげろ遅くてアクセスするのがいやになってきた。

もともとうちのサイトは、自分で思いついたネタ（ソフト）を手軽に実装＆改変することができるようなフレームワーク上に構築しているんで、ほとんどのページが動的に生成されている。

それでもそれなりの負荷に抑えるような設計にはしてあるんだけど、最近のアクセス数の増大（なんか知らんが先月は1日10万ヒットくらいになってたよ。たぶんYahoo!が検索エンジンを変えた結果、末端ページにYahoo!経由で来る人が増加したからだろうなー）と、最近思いつきで行った機能増強（Estraierとの連携関連はかなりリソースを食う）のせいで、一気にパフォーマンスが限界に来たっぽい。

もう1台サーバーを増やして分散させるってのが、今時の解決策なんだろうけど、さすがに趣味で2台もサーバーは持つのはきつい。AirH"も128k契約のままだし、夏WINでauもフラットに乗り換えるつもりだから（そうしたらAirH"は32kに戻す）、あまりにもネットワークエンゲル係数が高くなりすぎてしまうよ。しかもサーバーは気軽に解約できないからなー。

というわけで、がんばっていろいろ最適化して（Webの見た目の）パフォーマンスを向上させてみた。

まず最初にいじってみたのはMySQL周り。テーブル構造（とかインデックス周り）はいじるところがなさそうだったんで、MySQLのサーバーパラメーターを適当にいじってみる。MySQLサーバの最適化（http://dev.mysql.com/doc/mysql/ja/Optimising_the_Server.html）を眺めながらいろいろいじってみたけど、よくわからん。

基本的にはよく使いそうな項目を中心に、MySQLの使用メモリ量を増やしてやればいいんだろうけど、うちの場合MySQLが半分、その他が半分くらいでリソースを使っているんで、MySQLにメモリを与えすぎると他のプロセスの方が重くなりすぎる。というかそのせいで昨日何度かサーバーを落としてしまった。512M中200MくらいをMySQLに与えるのはやりすぎだったらしい。

結局key_buffer_sizeとjoin_buffer_sizeとsort_buffer_sizeに30Mくらい割り振り、それ以外もちょぼちょぼと増やして100Mちょっと割り振ってみたけど、なんかあんまり早くなっていないっぽいなー。でかいテーブル同士を日付で絞ってjoinしてcountするquery（＝blogmapのランキング集計）を高速化するにはどのあたりをいじればいいんだろう。ひとまずこれ以上いじっても改善される気がしないんで、MySQLサーバーパラメータいじりは中断。

続いてソフトウェアの対応。うちのサイトで使っているフレームワークの負荷低減の肝は、データオブジェクトレベルとHTMLパーツレベルで柔軟にキャッシング（および動的破棄）できるところで、逆に言うとそれよりも大きなレベルでのキャッシング（ページ単位とか）はやらないことによって、適当にコードをいじってもちゃんと追随できるようにしていた（そうしておかないと、よくキャッシュ間の不整合が起きておかしくなるんで、手軽に思いつきでいじりにくくなる）。

けど、もう現在このサーバーで動かしているアプリケーションに関しては、既存のコードを拡張していくくらいならば、データだけ互換にしてスクラッチで組み直した方が幸せそうな気がしてきたんで、遊べる度を低める結果になってもかまわないや。ってことで、より大きなレベルでキャッシングすることにした。

まずページレベルのキャッシュとして、アクセス数の多いblogmapのトップページとRSS、mylogのトップページとRSSを静的生成に変更。もともとPHPで動的生成されているものだから、それをWebからキックして動かすのではなくローカルでcron動作させて、

ob_start();
//従来のページ生成コード
file_put_contents('index.html', ob_get_contents()); //なんてPHP4にはまだないよ
ob_end_clean();

なんて感じでindex.htmlとrss.rdfとして保存すればおしまい。ついでにindex.html.gzとrss.rdf.gzファイルも用意して、

<Files index.html>
ForceType text/html
Options MultiViews
</Files>
<Files rss.rdf>
ForceType application/xml
Options MultiViews
</Files>

とかするとコンテントネゴシエーションも働いてくれるかな。まあRSSの方はAccept-Encoding: gzipなリクエストを投げてくれるものは少ないかもしれないけど。ああそういえば前にどこかでRSSのContent-Typeは何が妥当かという話を見かけた気がする。結論はapplication/xmlじゃなかったはずだよなー。あとで調べて直しておくか。

で、トップページとRSSは静的データとして返すようにしたけれども、それでもあんまり負荷が低くならない。まあトップページとかはもともとかなり最適化されていたんで、高負荷の原因としてはさほど大きくはなかったからな。どちらかというと、あまり最適化されていない割には、最近検索エンジン経由のアクセスが増えている末端ページも最適化しないとまずいか。

そこで、Apacheにperfomance_logを出力させてしばらく様子をみる。

LogFormat "%T\t%v\t\"%r\"" performance

なんて感じでページごとの実行時間をTSVで出力させて、ダウンロードしてExcelで読んでソートしたりとか。で、遅そうなページに関しては、そのページのフレームワークのベンチマーク機能をONにして、関数（というかプラグイン）レベルでの実行時間も同様に測定。

やっぱり重いのはblogmapの末端ページだなー。Amazon Web Serviceが重いのは（おそらくネットワークレイヤーの話なんで）ソフトウェア的に改善できるあてはないんで放置。それ以外で重いのは、Estraierの関連ドキュメント検索か。これはもともとEstraierのインデックス更新が日次処理なんで、ものすごく長めにキャッシングしてもいいはずだ。あと、リンク元表示もどうせこっちでクローリングしているんだから長めにキャッシングしていても大丈夫なはず。BBS/TrackBack以外はめちゃめちゃ長く（数時間）キャッシングしてしまえ。

というわけで、そのあたりを中心に、今まであまりやっていなかったHTMLパーツレベルでのキャッシングを追加。うちのフレームワークでは、

function someHtmlParts() {
$cache = new Cache('cache_namespace');  //キャッシュオブジェクト
$cachekey = 'cache_name';   //名前
$cacheoption = array(   //オプション
'available' => 60,   //基本的に60秒間有効
'files' => array('/tmp/related_file')    //更新されたらキャッシュを破棄
);
$html = $cache->Load($cachekey, $cacheoption);
if ($html) {
echo $html;
return;
}
ob_start();
//以下HTMLパーツを出力する従来のロジック
$html = ob_get_contents();
$cache->Save($cachekey, $html);
ob_end_flush();
}

という感じ。ちなみにキャッシュの強制破棄は、

$cache->Remove($cachekey);

とか

touch('/tmp/related_file');

って感じね。

さらにHTMLパーツを複数まとめてのキャッシングを増やしたり、データオブジェクトレベルでのキャッシュ有効期間を長めに変更したりしてみたんで、一度アクセスがあった末端ページについては、読み込みがかなり早くなったことでしょう。

ちなみにApache（1.3）の設定は、

Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
StartServers 10
MinSpareServers 10
MaxSpareServers 50
MaxClients 50
RLimitCPU 50

なんて感じにしているんだけど、こんなもんでどうでしょうかね？　もっとSpareServersを増やした方がいいのかなー。あと、Apache 2に移行するべきかどうかも迷う（PHP5の正式版がリリースされたら、それと同時にApache 2に移行しようかと思っているんだけど）。

• AreaEditor - http://www.iburiworks.com/jp/products/areaeditor/features.html

extedit（http://mylog.ishinao.net/id/1177）をご利用のみなさん、AreaEditorに乗り換えましょう。exteditの欠点（ブラウザがロックされる）が解消された完璧なIE外部エディタ連携ソフトですよ。Sleipnirとかから秀丸を開いて、タブを移動しながらテキストを書いて保存とか、ちゃんとできるようになりますよ。

内部的な動きを想像してみると、まずトリガーとしてはexteditと同じくIEから呼び出された際に、呼び出し元IE（Window）オブジェクト（external.menuArguments）をもらって、そこから該当のtextareaオブジェクトを得ているんでしょう。

で、textareaオブジェクトのインスタンスを得たあとは、データディレクトリにtextareaの内容をテキストファイルとして出力し、それを指定されたエディタで開き、ひとまずIEから呼び出されたスレッドは終了してしまう。これでブラウザのロックは解消される。

以降は、先ほど生成したテキストファイルの更新を監視（確かそういうAPIがあったよな）。ファイルが更新されたら、テキストファイルの内容を読んで、textareaオブジェクトの内容を更新する。って感じじゃないかな。

というか、exteditの欠点を解消すべく、そういうものを自分でも作ってみようかと思ったんだけど、

• 他の言語で、IEのコンテキストメニューハンドラから呼び出されたときに、external.menuArgumentsオブジェクトを得る方法がよくわからん
• コンテキストメニューから呼び出されたスレッドでは、external.menuArgumentsとかその中身のオブジェクトとかは有効だろうけど、そのスレッドが終了したあとにも、そこで取得したインスタンスは有効なんだろうか？

とかがよくわからなくて放置していたんだよなー。

最近tDiary系に来襲しているエロREFERER SPAMの一覧。

www.xxx-rape.org www.webcamss.com/hot-girls/ www.webcamss.com/teen-sex/ dog-sex.animal-sex.name www.webcamss.com/gay-boys/ www.webcamss.com/gay-men/ dog-sex-mpegs.beastiality-animal-sex-stories.com www.animal-porn.ws www.beastialitystories.info www.bestiality-stories.org www.free-incest-stories-site.com free-beastiality.org public-nudity.name free-rape-stories-videos.com beastiality.animal-sex.name sexy-naked-girls-porn.com animalsex.animal-sex.name www.latina-sex.ws www.free-beastiality.org www.free-hentai-cartoon-porn.com pokemon-porn.anime-porn-sex-xxx.com horse-sex.animal-sex.name pokemon-hentai.anime-porn-sex-xxx.com www.anime-porn-sex-xxx.com www.indian-sex-porn-movies-stories.com www.interracial-sex.ws zoo-sex.animal-sex.name

まだあるかもしれないけど、blogmapの上位にまで入ってきたのは今のところ以上。

• http://hobby6.2ch.net/test/read.cgi/phs/1088961042/4-5

4 ：非通知さん ：04/07/05 05:15 ID:YUXPFFYL
いいことを教えてやろう。
こんなスレを立ててくれたんだからな。
スペイン語で数字の「５」のことを「Cinco」って言うんだ。
OK、あぁ、わかってる。
お前のことだからとりあえずチンコを連想しただろ？
読み方をカタカナで表すとシンコって感じなんだが、
まぁ、今はそんなことどうだっていいんだ。
いいか、よく聞け。
これからは２ゲットの時代じゃなく、５に Cinco って書くことが流行る。
そう、５に合わせてただ Cinco とだけ書くんだ。
読み方のわからない厨房はチンコを連想するだろ？
まさにそれが狙いなんだ。
頭のいいお前には「５」ってことがわかるが、厨房には「チンコ」だ。
わかるか？それがお前と厨房の差なんだ。
これからはそうやって５をゲットすることでお前のすごさを見せ付けてほしい。
↓さぁ！
5 ：非通知さん ：04/07/05 05:53 ID:Ci/Lu+5s
ＭＡＮＣＯ

個人的な情報管理ツールが欲しい。PIMというと、目先のスケジュールをばたばたこなすための補助ツールっぽい響きがするんで、ちょっとイメージが違う。PKM - Personal Knowledge Managementなんて表現はどうだろう。記憶力が弱りがちなお年頃の僕たち私たちのための、“自分が知っているはずの”知識を管理するための補助ツール。

というネタをこの間の「自分の見たWebページを全文検索する（http://mylog.ishinao.net/id/1242）」を書きながら思いつき、それからいろいろこねくり回している。

まつもとさんがばりばり作っているMorgがどんな感じになるのがが早く見てみたい。Emacsベースのフロントエンドというところが、Emacs系になじめない私にはちょっとつらそうだけど、Estraier＋QDBMでデータ管理するんだったら、自前で別フロントエンドを作るのも可能かなー。というかWindowsでも動くんだろうか。

あとすでに動いているものとしては、GoogleのGmailがどの程度かしこい情報管理ツールとして使えるのかが気になる。どなたかinviteしていただけませんか。kitajさんにinviteしていただけました。ありがとうございました。

• bk1はてな - http://bk1.hatena.ne.jp/
• smashmedia: ｂｋ１はてな - http://takeshi.sub.jp/blog/archives/000323.html

はてなの人力検索はいまいち使う気にはなれないんだけど、本というジャンルに絞った人力検索ならば結構よさそうな気がする。本とか映画とかCDとか、そのあたりに関する曖昧な疑問って、検索エンジンとかで調べるのが結構難しかったりするからな。

とか思いつつも、最初に開いてみた質問「田中康夫の「ぼくだけの東京ドライブ」 （角川文庫　1990年）が読みたいのですがどこにも売ってません。どうやったら読めるでしょうか？:http://bk1.hatena.ne.jp/1089180520」に、

検索したら、AMAZONで普通に売っていますよ。

アマゾンで注文すれば確実です（中公文庫版もありますね）。

という回答が2連発でついていてちょっと笑った。

でも、確かに上記書籍をbk1で探しても見つからないし、しかも（そのことを確認するために久しぶりに使った）bk1の検索機能はいまいち使いにくくて反応が遅いからなー。せっかくこういう面白そうなサービスを立ち上げても、そこで得られた潜在顧客がAmazonに流れていってしまいそうだ。bk1は基礎体力の向上の方ももうちょっとがんばれ。

• blogmapメールニュース - http://bm.ishinao.net/bm_news/

ただいま実験中。bm_news-subscribe@ishinao.netあたりにメールを出したりすると、1日に2回ほどメールが届くようになるかもしれません。メールを止めたい場合はbm_news-unsubscribe@ishinao.netあたりに。

今のところ、7/18時の2回、URL・ASIN（本、CD/DVD、ソフトウェア、PC/電気製品）のトップ10を流してますが、回数・時間・内容・件数等、要望があったらコメントください。

• http://www8.big.or.jp/~vid/Diary/20040711.html#p06

なんかサーバー限界に近いらしい……

• http://d.hatena.ne.jp/adramine/20040712#p5

blogmapの負荷が高いためにメールニュースで流してみるということらしい。

別にそういうわけじゃないですよ。サーバー負荷はさらにMySQLのチューニング（ようやくこつがつかめた）をして、さらにアクセスが一周して全体的にキャッシュが効くようになったら、それなりに落ち着いているし。ただ、もうサーバーサイドでCPUをぶん回すような遊び（PageRankの計算とか）をする余力はなくなっちゃったけど。

メールニュースは負荷対策のために作ったのではなく、最近メール系（SMTP/POP/IMAP）の可能性をいろいろ試してみようかと思っているんで、単にそういう実験の一環なだけですよ。TrackBackみたいなものもHTTPじゃなくてSMTPでも受け付けるようにすると、自動的にサーバー間で非同期処理になってよさそうだよね、とか。あと今度新しいCDMA 1X WIN機を買おうかとか思っているんで、そのときにblogmapのメール版があると便利かなーと思ったってのもある。