nDiki : CGI プログラム

2006年2月18日 (土)

Perl CGI プログラムのテストには WWW::Mechanize::CGI

CGI プログラムを書いていて、いつも困るのがリグレッションテスト

パッケージのビルド時に実行するテストスーツ (make check / make test 用テストプログラム群) に含めておきたいが、さすがにその場で Web サーバの下へセットアップするわけにもいかない。 ミニ Web サーバを同梱してテストスーツ内で起動する方法はちょっとおおがかかりだし、ポート番号の選択やらサーバの停止の問題もあって、かなり面倒。

結局、テストスーツの中で環境変数や標準入力など CGI リクエスト環境をセットアップして、CGI プログラムを実行するという王道(?)かつ泥臭いテストを書くことになったりする。

何かいいものはないかと探していたところ、WWW::Mechanize::CGI というものをみつけた。

LWP::UserAgent を継承した WWW::Mechanize モジュールは Web ブラウジングを容易にする有名どころのモジュールである。

WWW::Mechanize::CGI モジュールはさらにこれを拡張したモジュールで、HTTP リクエストを、仮想的に CGI プログラムやサブルーチンへの呼出しにしてくれる。 これを用いるとあたかも Web サーバ上の CGI プログラムにリクエストしレスポンスを受けとっているかのように、テストプログラムを書くことができる。

素晴しい。

さっそく WiKicker のテストを書き換えてみた:

 use Test::More tests => 2;
 use WiKicker::WikICGI::Controller;
 use WWW::Mechanize::CGI;
 use File::Temp qw(tempdir);
 use File::Spec;
 my $www_dir = tempdir(CLEANUP => 1);
 my $mech = WWW::Mechanize::CGI->new;
 $mech->cgi(sub {
              $ENV{PATH_INFO} = '' if $ENV{PATH_INFO} eq '/';
              WiKicker::WikiCGI::Controller->new->run});
 $mech->env($mech->env,
            SCRIPT_FILENAME => File::Spec
                                 ->catfile($www_dir . '/wiki'),
            SCRIPT_NAME => '/wiki');
 my $response = $mech->get('http://localhost/wiki');
 ok($response->is_success);
 like($response->content,
      qr|<title>WikiForum\[WiKicker\]: FrontPage</title>|);

WWW::Mechanize::CGI オブジェクトを new した後、cgi メソッドで CGI サブルーチンを指定するか、cgi_application メソッドで外部 CGI プログラムを指定する。 ここでは直接、CGI サブルーチン (WiKicker::WikiCGI::Controller->new->run を実行)を指定した。

なおここで WWW::Mechanize::CGI が使っている HTTP::Request::AsCGI 0.5 における PATH_INFO の扱いが Apache などとは違って、空でも必ず '/' が入るようになっている。 これだと WiKicker では困るので、サブルーチンのところで修正している。

後は必要ならば WWW::Mechanize::CGI::env で、追加の環境変数設定を行っておく。

セットアップが済めば通常の WWW::Mechanize と同様に get 等でリクエストを行いレスポンスを受けとることができるようになる。

いい。しばらく試してみて不具合がなさそうなら、定番のテストスタイルにしたい。

ちなみに Test::Harness 用の Test::WWW::Mechanize にあわせて、Test::WWW::Mechanize::CGI というものもある。 これらを用いるとさらにテストを書くのが楽になるが、依存するモジュールも多いので無理に使わないほうがいいかもしれない。

スポンサード リンク
[ 2月18日全て ]

2006年3月3日 (金)

サーバ高負荷状態につき DiKicker 機能修正とサーバ設定変更

www.naney.org をホスティングしているサーバが重いと思ったら、同じサーバ上のあるユーザの CGI プログラムが5プロセス無限ループしてるっぽい……。 load average 20前後。

あおりを受けて、nDiki が大変なことになっている。

nDikiSpeedyCGI を使っているのだが、バックエンドの speedy_backend が捌ききれず、フロントエンドの speedy が大量に待ちに入ってしまっている。

MaxBackends を調整しても駄目(下手にバックエンドプロセス数を増やしても、結局処理が追いつかない)。

ということで急遽対策。

高負荷時にはてなブックマークへのアクセスを停止

load average が高い時には、はてなブックマーク上の検索結果を表示させるために行なっているはてなブックマークへのアクセスを休止するように変更。 24時間に設定してあるキャッシュの有効期限が切れていても、高負荷の時にはアクセスにいかないようにする。

これで DiKicker の処理時間を短縮。相手側サーバへの負担も軽減。

Google Desktop からのアクセスを一時的に拒否

おかげ様でここ最近 nDikiRSS へのアクセス数が増えてきている。 ありがたい事である。

しかしながら DiKickerRSS レスポンスは、あまり賢くなく毎回データベースから最新記事情報を抽出して生成しているため、それほど処理が速くない。

なのでアクセス頻度を高くしている RSS リーダがどこかで同時に起動しているとちょっとしんどい。 特にここ最近 Google Desktop からのアクセス数が増えている感じ。

さすがに今日はサーバの負荷が高く処理が追いつかなくてどうしようもないので、一時的に Google Desktop を拒否することに。

.htaccess に設定を追加。

 BrowserMatch "Google Desktop" denybrowser
 deny from env=denybrowser

近日中に、RSS 処理を改善してすぐに解除する予定。

robots.txt に Crawl-delay: を追加

効果があるかどうかは不明だが、Crawl-delay: に対応するというクローラ (Slurp、msnbot) 向け設定を追加。

 User-agent: Slurp
 Crawl-delay: 20

 User-agent: msnbot
 Crawl-delay: 20

アクセス数としては Googlebot と Slurp がダントツ。 しかし Google は無下にする訳にもいかないしなぁ。

[ 3月3日全て ]

2006年4月30日 (日)

www.naney.org サーバ断続的にダウン

www.naney.org の過去記事を確認しつつ作業をしていたら、9:00 前に急にアクセスできなくなった。 ping も通らない。 9:20 ぐらいに 1度復帰したが、また10:00 前にダウン。

それから何度も落ちては復帰を繰り返すようになってしまっている。 SSH で接続している途中にも突然刺ささるし、傍から見ていても原因が良くわからない。

昨日 WiKickerアップデートしたから「もしかしてうちが原因?」とちょっと心配もしたりするのだが、無限ループに入ったりメモリを使い尽すようなコードが追加してはいないはずだしなぁ(ローカルでのテストではそのような現象は見られない)。

落ちる直前まで見ていてもそれほど load average が高いわけでもないようだしなぁ。

とまぁ、しばらく様子を見ているうちに NaneyOrgWikinDiki が Internal Server Error。 止められた。 正確には SpeedyCGI のフロントエンド speedy コマンドの実行権限を管理者に落とされた。

  • (大半はロボットによるものなのだけれども) NaneyOrgWikinDiki のどちらか(あるいは両方)に常にアクセスがあってスクリプトが動いている
  • top すると他のユーザの CGI プログラムは 'perl' か 'perl 5.00503' と表示されるのに対し、これらは speedy、speedy_backend と表示されるため、管理者の目を引きやすい

ということもあって疑われたと推測。

一応こちらでも SpeedyCGI を使わないで直接 Perl で実行するように変更してみたり、Memcached を起動するのをやめてみたりなど設定を変更してみたりするのだけれど、関係なく落ちる落ちる。

管理者がシステムの設定を変えていないで発生するようになったのなら、ハードウェア障害が起きているんじゃないかと想像してしまうのだが、実際どうなんだろうか。

結局夜 23:00 過ぎだかに落ちたあとは復帰する様子がないので(管理者が落ちたかな?)、今日はあきらめ。

[ 4月30日全て ]

2006年5月28日 (日)

WiKicker 0.31 リリース - s キー問題を修正

2006年5月22日以来、約1週間ぶりのリリース。

[ 5月28日全て ]

2006年6月1日 (木)

Hyper Estraier で社内 Web コンテンツ検索

昨日の自分のノート PCHyper Estraier の試用を踏まえて、社内のサーバに Hyper Estraier を設置する。

インストール

いまだ Red Hat Linux 8.0 であるサーバに、昨日と同様に Hyper Estraier 1.2.7 を /usr/local/hyperestraier-1.2.7 以下にインストール

この環境では ./configure 時に iconv が見つからないため、最初に libiconv 1.9.2 を /usr/local/hyperestraier-1.2.7 に入れ、続けて QDBM、Hyper Estraier の順にインストール

estwaver + estmaster でクローリング + 文書登録も問題なく完了。

search_ui がうまく動かない。

検索をしようと http://ホスト:1978/node/ノード名/search_ui にアクセスするも、検索フォームを含め何も表示されない。あれ? 他の管理ページは問題なく表示されるのに search_ui だけ駄目。

GNU Wget だときちんと HTML を GET できるのだけれど、FirefoxInternet Explorer からだと駄目である。

いろいろビルドしなおしてみたけれどやっぱり駄目なので、今回は結局 estmaster をやめて CGI プログラム版の UI を使うことにした。 こちらだとクローリング中は検索ができなくなってしまうけれど、夜中に cron で回すから別にかまわないか。

インデックスの方針

以下のような感じでクロールし、登録することにした。

  • 社内メイン Wiki、自分の社内 Blog、公開 Web サイトのトップページをクロールの種文書とする。
  • それと社内メイン Wiki の更新情報ページも種文書とする。
  • 社内のサーバ、および公開 Web サイトのみクロールするように allowrx、denyrx を設定。
  • Wiki の編集ページ等をクロールしないように denyrx を設定。
  • 1日1回深夜に cron でインデックスを更新。
  • revisit は3日に設定。
    • いくつかの種文書は -revcont 付きで estwaver を実行しても毎回巡回して欲しいのだけれど、それはいまのところできないようだ。

特定の WikiBlog 内のみを検索したい時は、検索インタフェースの方で URL を指定絞り込めば良いので、それほど規模も大きくないし全部ひとまとめにインデックス化することにした。

後は使いながら微調整していくこととしよう。

[ 6月1日全て ]

2006年6月11日 (日)

WiKicker 0.34 リリース - 添付機能のコードを追加

2006年6月8日以来、3日ぶりのリリース。

zakwa 氏からの要望により、WikiPage のコピー直後に編集画面に移れる edit now オプションを追加。

また大きな改良として「添付機能」を追加した。 まだ最初のコードなのでエラー処理等が甘いが、それなりに動いているのでコミット。 まだ権限設定がないので、公開サーバでは使用しない方が良い。

添付ファイルのダウンロードを WiKicker 本体の CGI プログラムから行わせるか、独立の CGI プログラムにするか迷ったが、結局別物にした。

  • WiKickerURI 体系の中に、末尾にダウンロードファイル名を持ってこれる形式を作成できなかった。

というのが大きな理由。

設定方法

WiKicker のページにまだ設定方法を書いていないので、こちらへ。

attachment CGI プログラムを設置

例えば attachment というファイル名で以下のような Perl CGI プログラムを作り、Web サーバから実行できるように設定を行う。

 #!/usr/bin/perl
 use strict;
 use warniings;
 use WiKicker::WikiCGI::AttachmentController;
 WiKicker::WikiCGI::AttachmentController
   ->new(properties_file => '対応する wiki の設定ファイル名')->run;
Wiki のプロパティに設定を追加

次に Wiki の設定ファイルに以下を追加。

 param.NormalPage.attachment: enable
 param.NormalPage.attachment.uri: attachment

param.NormalPage.attachment.uri には上で作った CGI プログラムURI (相対/絶対)を指定する。

これで各ページに attachment (添付)というリンクが表示され、添付機能が使えるようになる。

WikiPage での参照の仕方
 # リンクを作成
 [[attachment:ファイル名]]
 [[attachment:ページ名/ファイル名]] <- 別のページの添付ファイル

 # 画像をインライン表示
 [[image:attachment:ファイル名]]
 [[image:attachment:ページ名/ファイル名]]
[ 6月11日全て ]

2006年7月15日 (土)

一般ユーザで Apache 2.0 を起動する最小限の httpd.conf

Perl CGI プログラムのテストの自動化には

などがある。 Apache を使うのがより実際の環境に近いテストができるのだが、通常動いている Apache を使って make test でテストできるようにするとすると「どこに配置するか」などの問題がでてくる。

となればいっその事、自分(一般ユーザ)で専用に Apache を起動した方が良さそうだ。 httpd.conf を用意するのが面倒だが、highperformance.conf 等をみる限り実はそれほど必須の設定は多くないようである。

httpd.conf を書く

ということで Debian GNU/Linux sidApache (2.0.55-4) で必要な設定は何か試してみた。少なくとも以下の設定は書いておく必要があるようだ。

 # httpd.conf for Debian GNU/Linux Apache 2.0.55-4
 Listen       9100
 ServerRoot   .
 DocumentRoot /home/naney/htdocs
 ErrorLog     error_log
 TypesConfig  /etc/mime.types
 PidFile      apache2.pid

これを httpd.conf として保存して、

 /usr/sbin/apache2ctl -f httpd.conf

で起動すればアクセスできるようになる。

 /usr/sbin/apache2ctl -f httpd.conf -k stop

で停止。

ServerRoot は起動時の -d オプションでも指定できるのだが、httpd.conf に書いておかないとうまく起動してくれなかった (-X を一緒に指定してデバッグモードにする場合は ServerRoot 無しに -d 指定だけでも動く)。

CGI プログラムを動くようにする。

CGI プログラムを動くようにするとすると例えば次のような感じ。

 # httpd.conf for Debian GNU/Linux Apache 2.0.55-4
 Listen       9100
 ServerRoot .
 DocumentRoot /home/naney/htdocs
 ErrorLog     error_log
 TypesConfig  /etc/mime.types
 PidFile      apache2.pid

 LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so
 Options +ExecCGI
 AddHandler cgi-script .cgi

make test で動くようにするには……

ディストリビューション独自のパッケージングなどに対応するように、多少泥臭く環境検出する必要があるが、なんとか make test から呼べそうだな。

最近は WWW::Mechanize::CGIお気に入りなのだが、2つ以上の CGI プログラムにまたがるようなアプリケーションのテストには向かなさそうなので、今度この方法でも試してみたい。

[ 7月15日全て ]

2006年7月22日 (土)

Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合

入社してから社内情報共有の一環として

といろいろ手をつけてきた。 次に狙っているのは SBS である。

Wiki社内 Blog に書くほどではないけれどメモ程度にブックマークしておきたい URL を、気軽に晒せるようにするのが目的。

はてなブックマークのような公開サービスは

  • タグ・コメント・傾向などが外に出るのはよろしくない
  • あるいは、それを気にして活用されない
  • そもそも社内リソースについてはブックマークできない

という点から、今回は利用できない。

ということで社内に SBS を設置したい考えている。

最初は Scuttle にしてみようと思ったのだが、PHP ベースであるのと MySQL を使うというところで気遅れしている。 いや SQLite でもいけそうらしいということで、実は Debian でちょっと試そうとしたのだが、テーブル作成の SQLMySQL 用で、これを修正するのが面倒なので断念。

次に Perl + SQLite で動く Rubric を試してみることにした。

Rubric 0.140

Rubric は CPAN にあがっているので CPAN.pm から install Rubric でインストールできる。 モジュールをインストールしたら、セットアップ。

  1. CGI プログラムを動かすディレクトリを決める (以下 $RUBRIC)
  2. Rubric tarball の bin/rubric.cgi を $RUBRIC/ にコピーし、必要なら #! を修正する。
  3. Rubric tarball の templates ディレクトリを $RUBRIC/ にコピーする。
  4. Rubric tarball の style/rubric.css を $RUBRIC/ にコピーする。
  5. Rubric tarball の etc/rubric.yml を $RUBRIC/ にコピーして環境に合わせて編集する。
  6. データベースを初期化する。0.140 には makedb.pl が同梱されていないので、0.13_01 の bin/makedb.pl を参考に perl -MRubric::DBI::Setup -e 'Rubric::DBI::Setup->setup_tables' で初期化する。ちなみに 0.140 付属の rubric コマンドで rubric db -s してみたが、これはうまく動かなかった。
  7. 必要に応じて .htaccess を作成・編集し rubric.cgi を CGI プログラムとして実行できるようにする。またその他アクセスされたくないファイルを deny するようにしておく。

これで OK。

rubric.cgi にアクセスしページが表示されればひとまず成功。 メニューの「register」から、ユーザ登録する。 確認用のメールが届くはずだが、面倒くさいのでこれを待たずに

 rubric user -a ユーザ名

でアクティベートする。

Rubric の HTML フォームからのブックマーキングは成功し、うまく動いているようである。 ただし、日本語の処理はどうもよくない。 title や description が化ける。 惜しい。

基本的には UTF-8 ベースでうまくいきそうなのだが、どこかで化けるようだ。 ちょっと手を入れれば直るかなと思ったが、化けるところと化けないところとがあるので逆に直す場所が多そうなので今日はやめておくことにした。

とりあえず Rubric はおいておいて、他のものも試してみることにするか。

[ 7月22日全て ]

2006年9月19日 (火)

Firefox 時間帯別ホームページ切り換え

昨日、ホームページからフレッシュリーダーを外した。 といはいえ、アンテナを張っておくという意味でそれなりに巡回しておく必要あり。

ビジネスアワーの中のちょっとした隙間時間でチェックしていくようにしたいので、平日の昼間は Web ブラウザホームページフレッシュリーダーにしておきたい。

曜日・時間でホームページを自動切り換えするような Firefox 拡張機能がないか探したけれど残念ながらみつからない。

ということで、曜日・時間をみてリダイレクト先を切り換えてリダイレクトさせるだけの簡単な CGI プログラムを作成してローカルホストの Web サーバに置き、Firefoxホームページに設定。 別にレスポンスにも不満はないので、これでいくことにする。

しかし、しばらくは RSS 巡回禁断症状が出そうだ。

[ 9月19日全て ]

2006年12月4日 (月)

SpeedyCGI 以下で WiKicker がうまく動かない?

WiKicker ベースのシステムが稼働しているホストが FreeBSD 5.2.1-RELEASE から FreeBSD 6.1-RELEASE に更新されるのにともない、再インストール作業を行った。

動作確認をしたところ CGI プログラムは動くものの Perl モジュール中の DATA セクションが読めていないようなエラー表示がされた。

もしやと思い SpeedyCGI を外したら正常動作。

SpeedyCGI 下で動くことを考えて、DATA セクションを1度しか読まないようにコーディングしてあるはずなのだが、はて。

他の作業もあり細かいチェックができなかったのでもしかしたら違うところでの問題かもしれないが、ちょっと厄介。

[ 12月4日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 1.076854s / load averages: 0.67, 0.68, 0.61
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker