トップ «前の日(07-01) 最新 次の日(07-03)» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2002-07-02

_ しばらくはあっちで更新してます。

しばらくはあっちで更新してます。あっちのほうが更新が楽なんで。そのうち、こっちとあっちをどう使い分けるか決めていこう。

Tags: web管理

2003-07-02

_ C760から更新 (13:50)

AirH"(AH-N401C)も無事購入できたんで、試しにC760+AirH"を使ってここを更新。さすがVGAだけあって、画面的には全然普通に更新できるな。キーボードの癖も一日でだいぶなれた。というか、慣れ過ぎてほかのPCのキーボードを打つ方に影響が出つつある。コーディングも結構普通にできるし、サーバーメンテなんかも問題なくできそう。AirH"の接続が思ったよりもちょっとよくないけど、いつでも細くつながっている状態ならば、のんびり構えていればそれなりに対応できる。ただこのマシンをまじめにいじるとなると、時間がいくらあっても足りなそうだな。昨日も3時に起きて朝までいじってしまった。仕事が忙しくなる前にセットアップ地獄から抜け出せるといいけど、このマシンみたいに正解のないいじり倒しマシンではなかなかそんな悟りは開けないだろうなー。ああ、眠い。


2004-07-02

_ Webパフォーマンス向上作戦 (13:51)

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

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

それでもそれなりの負荷に抑えるような設計にはしてあるんだけど、最近のアクセス数の増大(なんか知らんが先月は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にしましょう (13:51)

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とかその中身のオブジェクトとかは有効だろうけど、そのスレッドが終了したあとにも、そこで取得したインスタンスは有効なんだろうか?

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


2005-07-02


2006-07-02

_ bookmarkletの受付口が動いていませんでした

1470.netリニューアル版のbookmarklet受付口でエラーが出て、bookmarklet経由の登録がうまく動いていませんでした。

というのは、PHP5でもそろそろ実用で使えるアクセラレータがあるかと探してみたところ、peclに入っているAPCが一応PHP 5.1系に対応していると書かれていたので試しに入れたところ、一見ちゃんと動いているように見えたので、そのまま本番環境に導入してしまいました。が、先ほど試してみたところ、上記ページでAPCなしでは発生しないエラーが発生しているのに気づいたというわけです。

ちなみにエラーが発生したコードは、instanceofで変数の内容を振り分けて処理を切り替えている部分で、APCなしでは正しく継承元クラスのオブジェクトと認識できるのに対し、APCありだとその部分で正しい判断ができていないようでした。検証コードレベルを書けるレベルまで追ってませんけど。


2007-07-02

_ ガット張り替え

RDS002TOURとRQS11HGの両方をポリプラズマ1.28/面圧58pに張り替え。しばらく使っていなかったRQS11HGだけど、ヘッド寄りに3×3gの錘を追加して復活させる予定。

最近はフォアハンド、ボレー、スマッシュはだいぶまともになってきたけれども、バックハンドとサーブがまだまだ安定していないんで、当面はその二つが課題。

バックハンドは、基本両手打ち、浅いボールをたたくときだけ片手打ちという変則スタイルを練習中。もともとは全部両手打ちにするつもりだったんだけど、浅い球だけはフットワーク+膝を使って両手打ちの打点に入るよりも、足をさぼって片手打ちの打点で打つ方が確率も高いし、球の威力もあるんで。

サーブはフラット気味のファーストはだいぶ安定してきたけれども、セカンドがまだ試行錯誤中。スピンサーブはトスが難しくて安定にはほど遠い状態。スライスサーブはいいときはいいんだけど、入らない日はいつまでたっても修正が効かず、どうにも日によってばらつきが大きすぎる。結局実戦ではへなちょこサーブしかセカンドは打てていないんだけど、そろそろセカンドもまともに振り切るサーブを安定して打てるようになりたいところ。

といった感じで、相変わらずテニスは続けているんでした。週5くらいのペースでテニスをやっているんで、自転車に乗る暇が全然ない。あっちも心拍系強化のためにやっておきたいんだけど、テニスもハードコートが多いと足のダメージが大きいんで、自転車と両立させるのは結構難しいんだよな。あと圧倒的に時間が足りていないし。