ランダムマッチングのcgiをApacheBenchで速度を調べたところ、
Request per second がだいたい 2/sec
要するに一回の取得に0.5secぐらいかかっている。お、遅い！ なんて遅いんだ！
これはやばい。さすがに月480円は伊達じゃない。
ということで、index.htmlに対して行うと
Request per second がだいたい 975.04/sec
さすがに十分早い。
ということは、遅い原因は、Apacheかperlかmariadbかのいづれか。
試しに、mariadbなしのCGIで調べると、
やはり Request per second だいたい2/sec
レコードが2件しかないのにmariadbが遅いってことはないだろ。
犯人は、perlかapacheに絞られるが、index.htmlが遅くない以上、犯人はperlになる。
通常のcgiはコンパイルやプロセス起動がHTTPアクセスの度に発生するので、このへんが格安VPSの劇遅いCPU環境で負荷になっているのではないだろうか。
参考ブログでも以下の言及があった。（10年前の記事ｗ）
不必要なライブラリを極力ロードしないように気を付けているadiaryですら、 cgi実行時間の約９割がPerlのコンパイル時間です。
とうことで、このへんの負荷を低減するために、CGIプロセスが常駐するfastcgi環境を構築してみる。
yum install fastcgid
モジュールはこれであっさり入った。
locate "mod_fcgid.so"
ダイナミックリンクライブラリのインストール場所を確認する。
拡張子fcgiがfcgidで動くようにapacheの設定を変更。
httpdをrestartする
1文だけ表示するcgiを作って、通常とfastcgiで比較する
通常cgi
Request per second がだいたい 2.3/sec
fcgid
Request per second がだいたい 23.53/sec
おー！十倍速くなった！ （それでも遅いんだけど。480円だし）
ただし、fcgiの中で、mysqlにアクセスするとうまく動いてない。
まだ調査中。
動いた。mysqlのハンドラをグローバル変数にしてて、その関係で動かなかった模様。
引数で渡したら動いた。
ただ、アクセス数を増やすとfailedの割合が増えるのでちょっととほほって感じ
調べると、CGIのレスポンスの長さが変わったらfailedとみなす仕様らしい。
なんじゃそりゃ。
ランダムレコード取得だから、当然毎回長さは変わる。
SQLを動かした結果を表示せずにCGI終了させてみると、abのfailedは0になった。
別にCGIがこけているわけではない模様。
ab -n 50 -c 50でたたいても 24 Time per secondは出ていたので、めでたしめでたし。
#!/usr/bin/perl
use FCGI;
use CGI;
use strict;
use warnings;
my $request = FCGI::Request();
while ($request->Accept() >= 0) {
our $cgi = CGI->new;
print CGI::header(-charset=>"utf-8");
print "FASTCGI";
}
exit;