高負荷、大量アクセスなサイトで Lighttpd を使う場合の注意点
今回、Amazon Search が落ちていた原因は、Lighttpd プロセスが FastCGI プロセスと socket 通信不能になるバグ？が原因です。実は、ちょくちょくこの現象が発生しています。具体的には、 2006-02-01 20:29:03: (server.c.1033) [note] sockets disabled, out-of-fds 2006-02-01 20:29:33: (server.c.998) [note] sockets enabled again 2006-02-01 20:29:33: (server.c.1033) [note] sockets disabled, out-of-fds 2006-02-01 20:30:22: (server.c.946) connection closed - write-request-timeout: 71
Perl 界で今 HOT な MVC フレームワーク Catalyst のインストール方法
現在もっとも注目されていて評価もかなり高い MVC フレームワークとして Ruby on Rails ってのがあります。Ruby on Rails って方は、「【レポート】Lightweight Language Day and Night - フレームワーク対決 (MYCOM PC)」にスマートにまとめられていますが、 Ruby on Railsの特徴はいくつもあるが、必要になるファイルが自動生成されるという点が興味深いところだ。railsコマンドを実行すると必要になるファイルが自動的に生成される。標準的な利用であれば、設定ファイルを書くだけでウェブアプリケーションとして動作させることも可能だ。 Ruby on RailsにはDRY(Don't Repeat Yourself)というポリシーがあり、できるだけ同じことはしないようになっている。DRYを実現する方法として、規約重視、言語重視
Amazon Search の backend を SpeedyCGI 化
「Google Similar の backend を FastCGI 化」で予告したとおり、FastCGI のを導入していろいろ実験してみたのですが、utf8 な文字列の正規表現で予期せず Segmentation Fault が発生して使い物にならなかったので、SpeedyCGI を代替案として採用してみました。 速度的には、FastCGI ＞ SpeedyCGI なわけですが、導入のし易さは圧倒的に SpeedyCGI の方が上ですね。ほぼ CGI 互換で、#!/usr/bin/perl 部分を書き換える程度で済みます。 ちゃんと speedy バックエンドのプロセス数を制限する MaxBackends なんてオプションも指定できるので、mod_perl との使い分けは適材適所といった感じ。既に SpeedyCGI は別のところで使っていたので、導入の手間もありませんでした。 Fas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
