おいぬま日報 » Perl

Tomcatのスレッド数をグラフ化するMunin plugin

oinume — Sun, 19 Dec 2010 04:25:05 +0000

会社で使おうと思っていたTomcatのスレッド数をグラフ化するMunin pluginがあるのですが、XML::Simpleに依存していて「Munin pluginのためにわざわざPerlモジュールインストールするのもなぁ」と思ったので、ついかっとなってXMLをパースするところを正規表現で書き直してみました。ついでにmaxThreadsも表示するようにしたり、微調整もしています。プラグインはgithubに上げてあります。

なんでXML::Simpleを使っていたかというとTomcatのstatus画面がXMLで出力されているからなのですが、頑張ればこのぐらいのXMLは正規表現でパースできるということが実践できて良かったです。

↓は実際のスレッド数のグラフ。

Tomcatハンドブック第2版

著者／訳者：Jason Brittain Ian F. Darwin

出版社：オライリージャパン( 2008-11-21 )

大型本 ( 560 ページ )

Perl開発環境としてのEmacsの設定

oinume — Sat, 21 Aug 2010 16:28:13 +0000

最近社内でvim勉強会があったりして「vimもいいなぁ」と思っていたのですが、やっぱりキーバインドに慣れなくってEmacsに戻ってきました。最近EmacsでPerl関連の設定を見なおしたので、メモがてら書いておきます。自分がPerlのコードを書くときに使っているelispは以下の5つです。

cperl-mode
flymake + set-perl5lib
anything + auto-complete + perl-completion
yasnippet

これらを一つ一つ紹介していきます。

cperl-mode

cperl-mode はこんな感じで設定しています。とりあえず色付けと適切なインデントがなされればいいかなという感じ。

(autoload 'cperl-mode "cperl-mode" "alternate mode for editing Perl programs" t)
(add-to-list 'auto-mode-alist '("\\.\\([pP][Llm]\\|al\\|t\\|cgi\\)\\'" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("perl" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("perl5" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("miniperl" . cperl-mode))
;;; cperl-mode is preferred to perl-mode
;;; "Brevity is the soul of wit" 
(defalias 'perl-mode 'cperl-mode)
 
(setq cperl-indent-level 4
      cperl-continued-statement-offset 4
      cperl-close-paren-offset -4
      cperl-label-offset -4
      cperl-comment-column 40
      cperl-highlight-variables-indiscriminately t
      cperl-indent-parens-as-block t
      cperl-tab-always-indent nil
      cperl-font-lock t)
(add-hook 'cperl-mode-hook
          '(lambda ()
             (progn
               (setq indent-tabs-mode nil)
               (setq tab-width nil)
 
               ; perl-completion
               (require 'auto-complete)
               (require 'perl-completion)
               (add-to-list 'ac-sources 'ac-source-perl-completion)
               (perl-completion-mode t)
              )))
 
; perl tidy
; sudo aptitude install perltidy
(defun perltidy-region ()
  "Run perltidy on the current region."
  (interactive)
  (save-excursion
    (shell-command-on-region (point) (mark) "perltidy -q" nil t)))
(defun perltidy-defun ()
  "Run perltidy on the current defun."
  (interactive)
  (save-excursion (mark-defun)
                  (perltidy-region)))
(global-set-key "\C-ct" 'perltidy-region)
(global-set-key "\C-c\C-t" 'perltidy-defun)

flymake + set-perl5lib

flymake はEmacs自体に含まれているソースコードチェッカーです。set-perl5lib はここからダウンロードできます。この設定を入れるとコードを書いているときに裏でsyntax checkが走って、エラーになっている箇所を赤くしてくれます。これのおかげでしょうもないtypoに簡単にきづけるので、だいぶコードを書くのが速くなりました。かなりおすすめの設定です。

なお、自分は C-c e でエラーが発生している箇所にジャンプしてエラーメッセージをミニバッファに表示するように設定しています。

;; flymake for perl
(defvar flymake-perl-err-line-patterns '(("\\(.*\\) at \\([^ \n]+\\) line \\([0-9]+\\)[,.\n]" 2 3 nil 1)))
(defconst flymake-allowed-perl-file-name-masks '(("\\.pl$" flymake-perl-init)
                                               ("\\.pm$" flymake-perl-init)
                                               ("\\.t$" flymake-perl-init)
                                               ))
 
(defun flymake-perl-init ()
  (let* ((temp-file (flymake-init-create-temp-buffer-copy
                     'flymake-create-temp-inplace))
         (local-file (file-relative-name
                      temp-file
                      (file-name-directory buffer-file-name))))
    (list "perl" (list "-wc" local-file))))
 
(defun flymake-perl-load ()
  (interactive)
  (set-perl5lib)
  (defadvice flymake-post-syntax-check (before flymake-force-check-was-interrupted)
    (setq flymake-check-was-interrupted t))
  (ad-activate 'flymake-post-syntax-check)
  (setq flymake-allowed-file-name-masks (append flymake-allowed-file-name-masks flymake-allowed-perl-file-name-masks))
  (setq flymake-err-line-patterns flymake-perl-err-line-patterns)
  (flymake-mode t))
 
(add-hook 'cperl-mode-hook '(lambda () (flymake-perl-load)))
 
(defun next-flymake-error ()
  (interactive)
  (flymake-goto-next-error)
  (let ((err (get-char-property (point) 'help-echo)))
    (when err
      (message err))))
(global-set-key "\C-ce" 'next-flymake-error)

auto-complete + perl-completion

auto-complete と perl-completion を組み合わせてPerlのモジュールや関数、変数を補完する設定をしています。設定する elisp は先ほどの cperl-mode のところに含まれているので割愛します。下記のような感じで補完候補が出てきます。

また、perl-completion にはデフォルトで C-c s するとカーソルのあるモジュールのドキュメントをanything インタフェースで開くことができます。

yasnippet

yasnippet は任意のキーワードを打ってTABを押すと、そのキーワードを登録しておいたテンプレート(snippet)で置換してくれるものです。うまく使えばかなりのタイプ量が減らせるのでコードを書くのが早くなります。自分は例えば

use strict;
use warnings;

というsnippetを “usestwa” というキーワードで登録しています。

yasnippetには予め用意されているものがあるのですが、自分はそれとは別にディレクトリを作成して(~/.emacs.d/mysnippets)、そこに自分で作ったsnippetを置いています。以下がyasnippetの設定です。

(require 'yasnippet)
 
(require 'dropdown-list)
(setq yas/text-popup-function #'yas/dropdown-list-popup-for-template)
 
;; コメントやリテラルではスニペットを展開しない
(setq yas/buffer-local-condition
      '(or (not (or (string= "font-lock-comment-face"
                             (get-char-property (point) 'face))
                    (string= "font-lock-string-face"
                             (get-char-property (point) 'face))))
           '(require-snippet-condition . force-in-comment)))
 
;; yasnippet 公式提供のものと、
;; 自分用カスタマイズスニペットをロード同名のスニペットが複数ある場合、
;; あとから読みこんだ自分用のものが優先される。
;; また、スニペットを変更、追加した場合、
;; このコマンドを実行することで、変更・追加が反映される。
(defun yas/load-all-directories ()
  (interactive)
  (yas/reload-all)
  (mapc 'yas/load-directory-1 my-snippet-directories))
;;; yasnippet展開中はflymakeを無効にする
(defvar flymake-is-active-flag nil)
(defadvice yas/expand-snippet
  (before inhibit-flymake-syntax-checking-while-expanding-snippet activate)
  (setq flymake-is-active-flag
        (or flymake-is-active-flag
            (assoc-default 'flymake-mode (buffer-local-variables))))
  (when flymake-is-active-flag
    (flymake-mode-off)))
(add-hook 'yas/after-exit-snippet-hook
          '(lambda ()
             (when flymake-is-active-flag
               (flymake-mode-on)
               (setq flymake-is-active-flag nil))))
 
(setq yas/root-directory (expand-file-name "~/.emacs.d/snippets"))
;; 自分用スニペットディレクトリ(リストで複数指定可)
(defvar my-snippet-directories
  (list (expand-file-name "~/.emacs.d/mysnippets")))
 
(yas/initialize)
(yas/load-directory "~/.emacs.d/snippets")
(yas/load-all-directories)

まとめ

以上の設定をすると

ソースの色付け
シンタックスチェック
シンボルの補完
モジュールのドキュメントを引く
snippetによるタイプ量の削減

ができるようになります。EclipseのようなIDEにはまだ及びませんが、これでだいぶコードを書くのが速くなるかと思います。

情報源

を参考にさせてもらいました。ありがとうございます。

Emacsテクニックバイブル　～作業効率をカイゼンする200の技～

著者／訳者：るびきち

出版社：技術評論社( 2010-08-03 )

単行本（ソフトカバー） ( 384 ページ )

コマンドラインオプションを解析するPerlモジュールGetopt::Compact

oinume — Sat, 10 Apr 2010 12:37:12 +0000

Perlでコマンドラインオプションを解析する場合、大体は標準添付されているGetopt::Longを使うと思いますが、自分は3年前ぐらいから Getopt::Compact というモジュールに出会い、それ以降大抵の場合はこれを使っています。このモジュールの良いところは

オプションの定義(-c, –config などの定義)とそのヘルプメッセージが一箇所で定義できる
-h, –helpオプションを最初から定義してくれてる(–manオプションも)
定義してないオプションが指定されると自動的にエラーにしてくれる
Getopt::Compact#usage でヘルプメッセージが簡単に取得できる

があると思っています。などと抽象的な話をしてもしょうがないので、具体的なコードを書いてみます。

#!/usr/bin/env perl
 
use strict;
use warnings;
use Getopt::Compact;
use Data::Dumper;
 
my $getopt = Getopt::Compact->new(
    name => 'getopt_compact.pl',
    modes => [ qw(verbose) ],
    args => 'FILE',
    version => '0.1',
    struct => [
        [ [ qw(f force) ], 'force overwrite of output file and compress links' ],
        [ [ qw(l level) ], 'compress level', '=i' ],
        [ [ qw(S suffix) ], 'use suffix on compressed files', '=s' ],
    ]
);
 
my $options = $getopt->opts;
my $file = shift @ARGV;
unless ($file) {
    print STDERR $getopt->usage;
    exit 1;
}
 
print "options -----\n";
print Dumper $options;

上の例では gzip のオプションのモノマネで

-f, –forceというフラグオプション
-l, –levelという数値のオプション
-S, –suffixという文字列のオプション
オプション以外に引数FILEを受け取る

という仕様としています。

でで、例えば

$ perl getopt_compact.pl --help

と実行すると

getopt_compact.pl v0.1
usage: getopt_compact.pl [options] FILE
options                                                          
-h, --help      This help message                                
-v, --verbose   Verbose mode                                     
-f, --force     Force overwrite of output file and compress links
-l, --level     Compress level                                   
-S, --suffix    Use suffix on compressed files                   
    --man       Display documentation

のようにヘルプが表示されます。また、–hoge のような存在しないオプションを指定すると

$ perl getopt_compact.pl --hoge
Unknown option: hoge
getopt_compact.pl v0.1
usage: getopt_compact.pl [options] FILE
options                                                          
-h, --help      This help message                                
-v, --verbose   Verbose mode                                     
-f, --force     Force overwrite of output file and compress links
-l, --level     Compress level                                   
-S, --suffix    Use suffix on compressed files                   
    --man       Display documentation

のようにエラーになりヘルプが表示されます。

という感じで、Getopt::Longより依存モジュールがあるものの便利に使わせてもらってます。ただ、PerlのGetopt系のモジュールは他にも色々あるのでもっと便利なのがありそうですが、こういうのもあるよという紹介でした。

モダンPerl入門 (CodeZine BOOKS)

著者／訳者：牧大輔

出版社：翔泳社( 2009-02-10 )

大型本 ( 344 ページ )

DBI->connectのHandleError

oinume — Wed, 10 Feb 2010 15:48:28 +0000

DBIのちょっとしたTIPSです。DBIには connect する時に

DBI->connect('dbi:mysql:database=hoge', 'root', 'whatever', { ... });

とオプションを渡すことができます。(たとえば RaiseError) 。このオプションのひとつに HandleError というものがあってデバッグにはなかなか便利なので紹介してみます。端的にいうと HandleError でサブルーチンを登録しておくと、エラーが発生したときにこのサブルーチンを使ってエラーを投げてくれるようになります。以下は具体例。

# MyDB.pm

package MyDB;
 
use strict;
use warnings;
use Carp ();
use DBI;
 
sub new {
    bless {}, shift;
}
 
sub connect {
    my ($self) = @_;
    $self->{dbh} = DBI->connect(
        'dbi:mysql:database=dbix_thin_test', 'root', 'root',
        { RaiseError => 1, HandleError => \&Carp::confess } # here
    );
}
 
sub select {
    my ($self, $sql) = @_;
    my $sth = $self->{dbh}->prepare($sql); # error!
    $sth->execute();
}
 
1;

# dbi_handle_error.pl

#!/usr/bin/env perl
 
use strict;
use warnings;
use FindBin qw($Bin);
use lib "$Bin";
use MyDB;
 
my $db = MyDB->new;
$db->connect();
$db->select("select * from not_exist");

と書いてわざと MyDB#select でエラーになるようにしておき、このスクリプトを実行します。
すると

$ perl ~/script/perl/dbi_handle_error.pl
DBD::mysql::st execute failed: Table 'dbix_thin_test.not_exist' doesn't existDBI::st=HASH(0x248a900) at /home/kazuhiro/script/perl/MyDB.pm line 23
        MyDB::select('MyDB=HASH(0x21b8df0)') called at /home/kazuhiro/script/perl/dbi_handle_error.pl line 11

のように DBI->connectの HandleError で渡した Carp::confess が呼ばれ、エラーになった時にスタックトレースが表示されます。HandleError を指定しない場合は

$ perl ~/script/perl/dbi_handle_error.pl
DBD::mysql::st execute failed: Table 'dbix_thin_test.not_exist' doesn't exist at /home/kazuhiro/script/perl/MyDB.pm line 23.
DBD::mysql::st execute failed: Table 'dbix_thin_test.not_exist' doesn't exist at /home/kazuhiro/script/perl/MyDB.pm line 23.

のようになってしまい、実際にエラーが発生している箇所と問題のクエリの関連性がわかりにくいですが、HandleErrorで Carp::confess を指定しておくとファイル名と行番号がわかるのでどこでエラーになっているかあたりがつけやすいと思います。(この例だとメソッドのネストが少ないのでそのありがたみがわからないですが…)

以上、生DBIでもこんなマニアックなオプションがあるんだよという紹介でした。ZIGOROuさんの生 DBI ユーザーのための DBI Cookbook (1)を見ててよく思うのですが、DBIってなかなか奥が深いです。

モダンPerl入門 (CodeZine BOOKS)

著者／訳者：牧大輔

出版社：翔泳社( 2009-02-10 )

大型本 ( 344 ページ )

DBIx::ThinをCPANから削除

oinume — Tue, 12 Jan 2010 17:18:02 +0000

表題の通りですが、思うところがあってDBIx::Thinを削除しました。きっかけは、CPAN Ratingsのレビューです(以下引用)。

DBIx-Thin (0.05) **

It strikes me as odd how almost most of Japanese authors (of course, except honourable and admirable authors) don’t write why they have written their modules and the intention of the modules.
So is the author of this module.
The module is yet another ORM module but unfocused one. What the heck is different from DBIx::Skinny? The explanation is nowhere to be found, but there is just an enumeration of methods. And yet could anyone else use the module?

言われてみればその通りで、PODにコンセプトも書いてなければDBIx::Skinnyと違うところも良くわからないと。その辺に関してはモジュールのPODに書いておきましたが、それでもDBIx::Skinnyとあんまり変わらないし、現時点で自分以外の誰かが使っているとも思えないので、変な混乱を招かないようにCPANからは削除しました。んでgithubでは開発を継続していきます。

DBIx::ThinというORMapperをリリースしました

oinume — Tue, 29 Dec 2009 02:21:14 +0000

今年のYAPC(9月)からすき間時間を使って作っていたDBIx::Thinという、DBIx::Skinnyインスパイアなモジュールを昨日やっとリリースしました。作った動機は単に自己満足の追求と車輪の再発明による個人のスキルアップですが、前職で3年前ぐらいに自作したORMのコードを忘れないうちに改良して世に出したいなぁとずっと思っていたのです。SkinnyのAdvent Calendarが日々更新されているのを読み、途中で何度も「これSkinny使えばいいんじゃね？」って思って挫折しかけましたが、Skinnyも細かいところでは自分のポリシーと合わない部分があったりしたのと、とりあえず作ってしまったので世に出してみます。

特徴としては

生SQL派にやさしい
Skinnyより書き方は冗長だと思うけど、コードを見て何をやっているかわかるようにした
依存モジュールが少ない(標準以外のものは3つ)
Schemaクラスを生成するジェネレータが標準添付(ただしまだMySQL以外のDBに対応していない)

かなと思います。SQLはなんだかんだ言ってもまだWebエンジニアの共通言語だと思うので、ORMでゴリゴリJOINのコードを書くより生SQLの方がわかりやすい、と思っているので、生SQLなモジュールを作りました。

「Skinnyより書き方は冗長」というのは、例えばSkinnyだと

my $iterator = Your::Model->search(
    'user',
    {id => 1},
    {order_by => 'id'}
);

と書きますが、2つ目の引数が何を表しているのかぱっと見わからないので、Thinの場合は

my $iterator = Your::Model->search(
    'user',
    where => {id => 1}, # これ
    order_by => 'id',
);

と書くようにしています。もちろんSkinnyも学習すれば全然わかると思うので、細かいどうでもいいことかもしれませんが…

あとSkinnyと違う点は、

SchemaクラスとレコードのRowクラスは分離されていますが、シンプルさを重視してあえて一緒のクラスにまとめているところ(Your::Model::UserみたいなクラスがSchema定義をしてさらにこれのインスタンスがRowオブジェクト)
Schemaクラスの書き方がSkinnyはinflateやutf8がルールベースで全テーブルに適用されますが、こっちは基本的にテーブルの各カラムごとに書くようにさせてます

ところぐらいでしょうか。

最後に、Skinnyのコードはすごく綺麗で色々な部分を参考にさせてもらいました。作者のnekokakさん、どうもありがとうございました。

PerlのDateTimeとTime::Pieceモジュールのベンチマーク

oinume — Sat, 05 Dec 2009 15:40:24 +0000

Perlで日付関連の処理をする代表的なモジュールにDateTimeというものがありますが、メモリ消費量が激しいのがずっと気になっていました。でで、Time::Pieceが5.10.1からPerlに標準添付になったという話を聞いて、乗り換えようかどうか検討しています。Perlメモ/Time::Pieceモジュール – Walrus, Digit.を見ると、DateTimeでできることは大体できるので、以下のユースケースでの速度面を測ってみます。

use 時のメモリ使用量
現在日時でオブジェクトを生成する
日付オブジェクトに対する日付の加算
日付オブジェクト同士の減算(A – B して何日経ったかみたいな)
日付オブジェクト同士の比較
日付オブジェクトを文字列にする

環境は以下で、ベンチマークのスクリプトは最後に載せてあります。

OS: Ubuntu 9.04 amd64
Perl: 5.10.0 x86_64-linux-gnu-thread-multi
DateTime 0.51
Time::Piece 1.15

use 時のメモリ使用量

こちらのgtop.plを使って測ります。

$ gtop.pl 'use DateTime'
10.2M : use DateTime

$ gtop.pl 'use Time::Piece'
2.5M : use Time::Piece

おおお、なんと4分の1！

現在日時でオブジェクトを生成する

$ ./benchmark_datetime.pl now
Benchmark: running now_datetime, now_time_piece for at least 3 CPU seconds...
now_datetime:  4 wallclock secs ( 3.03 usr +  0.00 sys =  3.03 CPU) @ 3149.83/s (n=9544)
now_time_piece:  2 wallclock secs ( 2.58 usr +  0.53 sys =  3.11 CPU) @ 52694.86/s (n=163881)
                  Rate   now_datetime now_time_piece
now_datetime    3150/s             --           -94%
now_time_piece 52695/s          1573%             --

15倍！

日付オブジェクトに対する日付の加算

$ ./benchmark_datetime.pl add
Benchmark: running add_datetime, add_time_piece for at least 3 CPU seconds...
add_datetime:  3 wallclock secs ( 3.05 usr +  0.00 sys =  3.05 CPU) @ 1853.44/s (n=5653)
add_time_piece:  3 wallclock secs ( 2.76 usr +  0.42 sys =  3.18 CPU) @ 54969.81/s (n=174804)
                  Rate   add_datetime add_time_piece
add_datetime    1853/s             --           -97%
add_time_piece 54970/s          2866%             --

Time::Pieceの圧倒的勝利。28倍！

日付オブジェクト同士の減算

$ ./benchmark_datetime.pl subtract
Benchmark: running subtract_datetime, subtract_time_piece for at least 3 CPU seconds...
subtract_datetime:  3 wallclock secs ( 3.00 usr +  0.00 sys =  3.00 CPU) @ 4065.00/s (n=12195)
subtract_time_piece:  4 wallclock secs ( 3.15 usr +  0.00 sys =  3.15 CPU) @ 132329.84/s (n=416839)
                        Rate   subtract_datetime subtract_time_piece
subtract_datetime     4065/s                  --                -97%
subtract_time_piece 132330/s               3155%                  --

引き算もTime::Pieceの方が圧倒的に速いですね。

日付オブジェクト同士の比較

$ ./benchmark_datetime.pl compare
Benchmark: running compare_datetime, compare_time_piece for at least 3 CPU seconds...
compare_datetime:  3 wallclock secs ( 3.04 usr +  0.00 sys =  3.04 CPU) @ 47709.21/s (n=145036)
compare_time_piece:  4 wallclock secs ( 3.09 usr + -0.01 sys =  3.08 CPU) @ 173623.70/s (n=534761)
                       Rate   compare_datetime compare_time_piece
compare_datetime    47709/s                 --               -73%
compare_time_piece 173624/s               264%                 --

日付オブジェクトを文字列にする

$ ./benchmark_datetime.pl stringify
Benchmark: running stringify_datetime, stringify_time_piece for at least 3 CPU seconds...
stringify_datetime:  3 wallclock secs ( 3.00 usr +  0.00 sys =  3.00 CPU) @ 44470.33/s (n=133411)
stringify_time_piece:  3 wallclock secs ( 2.45 usr +  0.66 sys =  3.11 CPU) @ 116681.35/s (n=362879)
                         Rate   stringify_datetime stringify_time_piece
stringify_datetime    44470/s                   --                 -62%
stringify_time_piece 116681/s                 162%                   --

まとめ

総じてDateTimeよりTime::Pieceの方が高い性能を叩き出しました。速度にシビアな状況ではTime::Pieceを使った方が良いと感じました。こういう罠もあるみたいなので気をつけなくてはいけないところもありますが… インタフェースはどちらも綺麗に出来ているので使い勝手としては同じぐらいかなと思います。それにしてももっと速くTime::Pieceを検証しておけばよかったと思う今日この頃です。

ベンチマークスクリプト(benchmark_datetime.pl)

#!/usr/bin/env perl
 
use strict;
use warnings;
use Benchmark qw(cmpthese timethese);
use DateTime;
use Time::Piece;
use Time::Seconds;
 
my $timezone = DateTime::TimeZone->new(name => 'local');
 
#----------------------#
# now
#----------------------#
sub now_datetime {
    my $now = DateTime->now(time_zone => $timezone);
}
 
sub now_time_piece {
    my $now = localtime;
}
 
#----------------------#
# add
#----------------------#
my $add_dt = DateTime->now(time_zone => $timezone);
sub add_datetime {
    $add_dt->add(days => 1);
}
 
my $add_tp = localtime;
sub add_time_piece {
    $add_tp += ONE_DAY;
}
 
#----------------------#
# subtract
#----------------------#
my $sub_dt1 = DateTime->now(time_zone => $timezone);
my $sub_dt2 = DateTime->new(
    year => 2008,
    month => 12,
    day => 1,
);
sub subtract_datetime {
    my $dur = $sub_dt1->subtract_datetime($sub_dt2);
}
 
my $sub_tp1 = localtime;
my $sub_tp2 = Time::Piece->strptime('2008-12-01', '%Y-%m-%d');
sub subtract_time_piece {
    my $sec = $sub_tp1 - $sub_tp2;
}
 
#----------------------#
# compare
#----------------------#
my $compare_dt1 = DateTime->now(time_zone => $timezone);
my $compare_dt2 = DateTime->now(time_zone => $timezone);
sub compare_datetime {
    my $result = DateTime->compare($compare_dt1, $compare_dt2) <= 0;
}
 
my $compare_tp1 = localtime;
my $compare_tp2 = localtime;
sub compare_time_piece {
    my $result = $compare_tp1 <= $compare_tp2;
}
 
#----------------------#
# stringify
#----------------------#
my $now_dt = DateTime->now(time_zone => $timezone);
sub stringify_datetime {
    $now_dt->strftime("%Y-%m-%d");
}
 
my $now_tp = localtime;
sub stringify_time_piece {
    $now_tp->strftime("%Y-%m-%d");
}
 
#----------------------#
# main
#----------------------#
my $mode = shift @ARGV || 'now';
my $count = shift @ARGV || -3;
 
if ($mode eq 'now') {
    cmpthese timethese $count, {
        'now_datetime' => \&now_datetime,
        'now_time_piece' => \&now_time_piece,
    };
} elsif ($mode eq 'add') {
    cmpthese timethese $count, {
        'add_datetime' => \&add_datetime,
        'add_time_piece' => \&add_time_piece,
    };
} elsif ($mode eq 'subtract') {
    cmpthese timethese $count, {
        'subtract_datetime' => \&subtract_datetime,
        'subtract_time_piece' => \&subtract_time_piece,
    };
} elsif ($mode eq 'compare') {
    cmpthese timethese $count, {
        'compare_datetime' => \&compare_datetime,
        'compare_time_piece' => \&compare_time_piece,
    };
} elsif ($mode eq 'stringify') {
    cmpthese timethese $count, {
        'stringify_datetime' => \&stringify_datetime,
        'stringify_time_piece' => \&stringify_time_piece,
    };
}

Now Loading...

Text::MicroTemplate 0.10で速度が速くなっている件

oinume — Sat, 21 Nov 2009 02:37:11 +0000

Now Text::MicroTemplate is even faster than HTML::Template::Pro – use GFx::WebLog;

Text::MicroTemplate 0.10で動作速度が改善されたとのことなので、自分のところでもベンチマークしてみました。

$ perl benchmark_templates.pl 1
Perl/5.10.0 (x86_64-linux-gnu-thread-multi)
HTML::Template/2.9
HTML::Template::Compiled/0.94
HTML::Template::Pro/0.92
Template/2.20
Text::MicroTemplate/0.10
Benchmark: running HT, HT::C, HT::Pro, MT, TT for at least 1 CPU seconds...
        HT:  1 wallclock secs ( 1.03 usr +  0.00 sys =  1.03 CPU) @ 1094.17/s (n=1127)
     HT::C:  1 wallclock secs ( 1.03 usr +  0.00 sys =  1.03 CPU) @ 11598.06/s (n=11946)
   HT::Pro:  2 wallclock secs ( 0.82 usr +  0.29 sys =  1.11 CPU) @ 17611.71/s (n=19549)
        MT:  1 wallclock secs ( 0.96 usr +  0.08 sys =  1.04 CPU) @ 15904.81/s (n=16541)
        TT:  1 wallclock secs ( 1.08 usr +  0.00 sys =  1.08 CPU) @ 7110.19/s (n=7679)
           Rate      HT      TT   HT::C      MT HT::Pro
HT       1094/s      --    -85%    -91%    -93%    -94%
TT       7110/s    550%      --    -39%    -55%    -60%
HT::C   11598/s    960%     63%      --    -27%    -34%
MT      15905/s   1354%    124%     37%      --    -10%
HT::Pro 17612/s   1510%    148%     52%     11%      --

何回かやったのですが、自分の環境ではまだHTML::Template::Proが速いみたい。でも僅差なのでまったく気にならないレベルですね。とにかくgfxさん++すぎる。

Text::MicroTemplateとHTML::Template::Proの比較

oinume — Sat, 21 Nov 2009 01:56:04 +0000

PerlでWebアプリを作る時のテンプレートエンジンをどれにしようか相変わらず模索中なのですが、以下の2つのエントリーで動作速度とメモリについて調べた結果、どうやらText::MicroTemplateとHTML::Template::Proのどちらかを選択するのが良いだろうと思っています。

Text::MicroTemplateの良い点

Perlのコードが書けるので自由度が高い
そこそこ速い
省メモリ
デフォルトでHTMLエスケープしてくれるのでセキュリティ的にもグッド
コードがシンプルなので拡張しやすい
loopやifで改行の制御が出来る(と ? )

HTML::Template::Proの良い点

文法がシンプル
爆速
そこそこ省メモリ
register_functionでテンプレート内から呼び出せる関数が登録できるので、拡張性はそれなりにある

Text::MicroTemplateのイマイチな点

自由度が高い分、色々できてしまう(Viewにロジックをガリガリ書いたりとか)
Includeがデフォルトでは出来ない(Text::MicroTemplate::Extended使えば似たようなことはできる)

HTML::Template::Proのイマイチな点

、などの制御を書く時の改行のコントロールが難しい
デフォルトではHTMLエスケープがかからないので、自前で自動エスケープのロジックを書くかテンプレート側で毎度エスケープしなくてはいけない

「、で改行のコントロールが難しい」というのは、例えば以下のテンプレートファイルがあって、それを実際に出力した時のHTMLに改行が入ってしまう、ということです。

テンプレートファイル

<html>
<head></head>
<body>
NAME=hoge>
hoge
</TMPL_IF>
</body>
</html>

出力されるHTML

<html>
<head></head>
<body>
#ここに改行
hoge
#ここにも改行
</body>
</html>

出力するのがHTMLであればそんなに問題はないのですが、メールの文面をテンプレートエンジンで動的に生成したい場合、改行が実直に反映されてしまうので、いつもどうしようか悩んでしまいます。この改行のためにHTMLの生成とメールの生成で別々のテンプレートエンジン使うのも微妙ですし。

もしかするとHTML::Template::Proの filter 機能でなんとかできるのかもしれませんが、まだそこまでは考えられてないです。というわけで相変わらずテンプレートエンジンどうしようか悩み中…

Now Loading...

Text::MicroTemplateのメモリ使用量をベンチマーク

oinume — Sun, 15 Nov 2009 13:58:31 +0000

Text::MicroTemplateの速度を簡単にベンチマークでText::MicroTemplateの動作速度を簡単にベンチマークしましたが、今回はメモリ使用量を他のテンプレートエンジンと比較してみました。環境はUbuntu 9.04 amd64, Perl 5.10.0 で、GTopを使って測っています。

useした時のメモリ使用量

独自に作ったスクリプト(use_memory_size.pl)でuse時のメモリ使用量を測ってみます。

$ ./use_memory_size.pl
 3.2M : use HTML::Template
11.7M : use HTML::Template::Compiled
 2.5M : use HTML::Template::Pro
 264k : use Text::MicroTemplate
 3.6M : use Template

HTML::Template::Compiledは多くのモジュールで構成されているので、メモリ使用量が多そうな感じです。一方、ソースコードがとてもコンパクトな Text::MicroTemplate は他のテンプレートエンジンと比べてメモリ使用量が一桁少ない。これはすごい。

use_memory_size.pl

#!/usr/bin/env perl
 
use strict;
use warnings;
 
for my $module (qw(HTML::Template
                   HTML::Template::Compiled
                   HTML::Template::Pro
                   Text::MicroTemplate
                   Template)) {
 
    system "gtop.pl 'use $module'";
}

(プロセスのメモリ使用量を調べるために必要なGTopモジュール(およびlibgtop2)をインストールして、下記スクリプトをgtop.plとしてどこかパスの通ってるところに保存しておいてください)
gtop.pl

#!/usr/bin/env perl
 
use strict;
use warnings;
use GTop;
 
unless (@ARGV) {
    print STDERR "Argument required.\n";
    exit 1;
}
 
my $gtop = GTop->new;
my $before = $gtop->proc_mem($$)->size;
eval $ARGV[0];
die $@ if $@;
my $after = $gtop->proc_mem($$)->size;
my $diff = GTop::size_string($after - $before);
print "$diff : $ARGV[0]\n";

newしてレンダリングさせた後のメモリ使用量

モジュールをuseした時のメモリ使用量だけでなく、newしてoutputした後のメモリ使用量も調べてみました。結果は以下になります。

$ ./new_memory_size.pl 
 3.2M : use HTML::Template;my $t = HTML::Template->new(filename => q{template_speed_file.ht});my $s = $t->output;
11.7M : use HTML::Template::Compiled;my $t = HTML::Template::Compiled->new(filename => q{template_speed_file.ht});my $s = $t->output;
 2.5M : use HTML::Template::Pro;my $t = HTML::Template::Pro->new(filename => q{template_speed_file.ht});my $s = $t->output;
 796k : use Text::MicroTemplate::File;my $t = Text::MicroTemplate::File->new;my $s = $t->render_file(q{template_speed_file.mt})->as_string;;
11.4M : use Template;my $t = Template->new;$t->process(q{template_speed_file.tt}, {}, \my $s);

相変わらずText::MicroTemplateは良好な成績ですね。あまりメモリを積んでいないマシンでもこれなら安心して使えそうな感じです。HTML::Template::Proも2.5MBと省メモリですね。スピードも爆速なので、テンプレートにゴリゴリPerlのコードを書く必要がない場合はこれが一番よいかもしれません。

new_memory_size.pl

#!/usr/bin/env perl
 
use strict;
use warnings;
 
# HTML::Template
my $ht = <<'...';
use HTML::Template;
my $t = HTML::Template->new(filename => q{template_speed_file.ht});
my $s = $t->output;
...
 
# HTML::Template::Compiled
my $htc = <<'...';
use HTML::Template::Compiled;
my $t = HTML::Template::Compiled->new(filename => q{template_speed_file.ht});
my $s = $t->output;
...
 
# HTML::Template::Pro
my $htp = <<'...';
use HTML::Template::Pro;
my $t = HTML::Template::Pro->new(filename => q{template_speed_file.ht});
my $s = $t->output;
...
 
# Text::MicroTemplate
my $mt = <<'...';
use Text::MicroTemplate::File;
my $t = Text::MicroTemplate::File->new;
my $s = $t->render_file(q{template_speed_file.mt})->as_string;;
...
 
# Template
my $tt = <<'...';
use Template;
my $t = Template->new;
$t->process(q{template_speed_file.tt}, {}, \my $s);
...
 
for my $code ($ht, $htc, $htp, $mt, $tt) {
    $code =~ s/\n//g;
    system qq{gtop.pl '$code'};
}

Now Loading...

Text::MicroTemplateの速度を簡単にベンチマーク

oinume — Sat, 14 Nov 2009 16:21:34 +0000

2009/11/15 追記：tokuhiromさんのコメントを受けて、Text::MicroTemplate以外のテンプレートファイルにHTMLエスケープの処理を追加してベンチマークを取り直しています。

Perlのテンプレートエンジンでどれを使おうか悩んでいるので、Text::MicroTemplateをはじめとする以下のテンプレートエンジンの速度を簡単にベンチマークしてみました。

Text::MicroTemplate
HTML::Template
HTML::Template::Pro
HTML::Template::Compiled (PODにはHTML::Templateの3-7倍速いと書かれている)
Template-Toolkit

下記の要因で単純に比較できない部分もあるので、これを鵜呑みにしないでなるべく自身のユースケースの延長でもベンチマークを取ることをお奨めします。あくまで参考値ということで。

そもそも持っている機能が全然違うので単純に比較できない
実際のテンプレートファイルはもっと複雑なはず
utf8 flagの処理入れる場合もある

ではとりあえず結果から。

キャッシュなし

$ perl template_speed_file.pl 3000 0
Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  5 wallclock secs ( 4.60 usr +  0.09 sys =  4.69 CPU) @ 639.66/s (n=3000)
HT::Compiled: 10 wallclock secs (10.56 usr +  0.10 sys = 10.66 CPU) @ 281.43/s (n=3000)
   HT::Pro:  1 wallclock secs ( 0.20 usr +  0.04 sys =  0.24 CPU) @ 12500.00/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  2 wallclock secs ( 2.39 usr +  0.07 sys =  2.46 CPU) @ 1219.51/s (n=3000)
        TT: 10 wallclock secs ( 9.65 usr +  0.17 sys =  9.82 CPU) @ 305.50/s (n=3000)
                Rate HT::Compiled          TT          HT          MT    HT::Pro
HT::Compiled   281/s           --         -8%        -56%        -77%       -98%
TT             305/s           9%          --        -52%        -75%       -98%
HT             640/s         127%        109%          --        -48%       -95%
MT            1220/s         333%        299%         91%          --       -90%
HT::Pro      12500/s        4342%       3992%       1854%        925%         --

キャッシュあり

コードを見てもらえばわかるのですが、「キャッシュあり」とは具体的には

テンプレートのインスタンスを作るのは最初の1回だけ(キャッシュなしの場合は毎回作っている)
テンプレートエンジンに対して、「キャッシュあり」とコンストラクタで指令

ということになります。

$ perl template_speed_file.pl 3000 1
Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  3 wallclock secs ( 2.69 usr +  0.00 sys =  2.69 CPU) @ 1115.24/s (n=3000)
HT::Compiled:  0 wallclock secs ( 0.28 usr +  0.00 sys =  0.28 CPU) @ 10714.29/s (n=3000)
            (warning: too few iterations for a reliable count)
   HT::Pro:  0 wallclock secs ( 0.13 usr +  0.02 sys =  0.15 CPU) @ 20000.00/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  1 wallclock secs ( 0.22 usr +  0.01 sys =  0.23 CPU) @ 13043.48/s (n=3000)
            (warning: too few iterations for a reliable count)
        TT:  1 wallclock secs ( 1.84 usr +  0.00 sys =  1.84 CPU) @ 1630.43/s (n=3000)
                Rate          HT          TT HT::Compiled          MT    HT::Pro
HT            1115/s          --        -32%         -90%        -91%       -94%
TT            1630/s         46%          --         -85%        -87%       -92%
HT::Compiled 10714/s        861%        557%           --        -18%       -46%
MT           13043/s       1070%        700%          22%          --       -35%
HT::Pro      20000/s       1693%       1127%          87%         53%         --

HTML::Template::Proが爆速！
Text::MicroTemplateは、キャッシュなしだとそこそこ、~~キャッシュありはかなり速い部類に入るようです。~~キャッシュありだとHTML::Template::Proには及ばないものの、かなり速いです。
HTML::Template::Compiledはキャッシュを無効にするとTTより遅いという結果ですが、キャッシュを有効にすると猛烈に速くなるようです。ソースが追えてないのですが、中でガチンコにキャッシュしてるのでしょうか。
たぶん一番使われているTTはよく「遅い」と言われていますが、キャッシュを有効にすると意外にもHTML::Templateより速くなりました。

というのがポイントだと思います。この結果だけで判断すると、HTML::Template::Proは神がかり的な速さなのですが、そもそもPerlのコードをテンプレートに記述できず自由度は低いので(*1)、使う場合にはそれなりに不便さを覚悟した方がよいと思います。「便利さ」という点だとText::MicroTemplateはテンプレート内にPerlのコードが書ける分かなり自由度が高い、かつ速度もいい感じでバランスが取れていると言えます。

*1) Perlのコードをテンプレートに書けてしまっていいのかどうかは使う人次第だと思いますが

以下にソースを載せておきます。テストに使ったマシンはUbuntu 9.04, perl 5.10.0, CPUが Athlon Dual Core Processor 5050e です。

template_speed_file.pl

#!/usr/bin/env perl
 
use strict;
use warnings;
use HTML::Template;
use HTML::Template::Compiled speed => 1;
use HTML::Template::Pro;
use Template;
use Text::MicroTemplate::File;
 
use Benchmark qw(timethese cmpthese);
 
my @LANGUAGES = (
    { language => 'Perl', ll => 1 },
    { language => 'Ruby', ll => 1 },
    { language => 'Python', ll => 1 },
    { language => 'PHP', ll => 1 },
    { language => 'Java' },
    { language => 'C' },
    { language => 'C++' },
    { language => 'C#' },
    { language => 'VB' },
    { language => 'VB.NET' },
    { language => 'ASP.NET' },
    { language => 'Delphi' },
    { language => 'Erlang' },
    { language => 'Scala', ll => 1 },
    { language => 'Go' },
);
my $count = shift @ARGV || 1000;
my $cache = shift @ARGV || 0;
 
my $mt = undef;
sub mt {
    my %args = (use_cache => $cache);
    if ($cache) {
        $mt ||= Text::MicroTemplate::File->new(%args);
    } else {
        $mt = Text::MicroTemplate::File->new(%args);
    }
 
    my $s = $mt->render_file(
        'template_speed_file.mt',
        {
            page_title => 'LL Programming languages',
            languages => \@LANGUAGES,
        }
    )->as_string;
}
 
my $ht = undef;
sub ht {
    my %args = (
        filename => 'template_speed_file.ht',
        case_sensitive => 1,
        die_on_bad_params => 0,
        cache => $cache,
    );
    if ($cache) {
        $ht ||= HTML::Template->new(%args);
    } else {
        $ht = HTML::Template->new(%args);
    }
    $ht->param(
        page_title => 'LL Programming languages',
        languages => \@LANGUAGES,
    );
    my $s = $ht->output;
}
 
my $htc = undef;
sub htc {
    my %args = (
        filename => 'template_speed_file.ht',
        case_sensitive => 1,
        die_on_bad_params => 0,
        cache => $cache,
    );
    if ($cache) {
        $htc ||= HTML::Template::Compiled->new(%args);
    } else {
        $htc = HTML::Template::Compiled->new(%args);
    }
    $htc->param(
        page_title => 'LL Programming languages',
        languages => \@LANGUAGES,
    );
    my $s = $htc->output;
}
 
my $htp = undef;
sub htp {
    my %args = (
        filename => 'template_speed_file.ht',
        case_sensitive => 1,
        die_on_bad_params => 0,
        cache => $cache,
    );
    if ($cache) {
        $htp ||= HTML::Template::Pro->new(%args);
    } else {
        $htp = HTML::Template::Pro->new(%args);
    }
    $htp->param(
        page_title => 'LL Programming languages',
        languages => \@LANGUAGES,
    );
    my $s = $htp->output;
}
 
my $tt = undef;
sub tt {
    if ($cache) {
        $tt ||= Template->new(
            CACHE_SIZE => $cache ? undef : 0,
        );
    } else {
        $tt = Template->new;
    }
    $tt->process(
        'template_speed_file.tt',
        {
            page_title => 'LL Programming languages',
            languages => \@LANGUAGES,
        },
        \my $out,
    ) or die $tt->error() . "\n";
}
 
# main
my $comp = timethese(
    $count,
    {
        'MT' => \&mt,
        'HT' => \&ht,
        'HT::Pro' => \&htp,
        'HT::Compiled' => \&htc,
        'TT' => \&tt,
    }
);
cmpthese $comp;

template_speed_file.mt – Text::MicroTemplate用のファイル

? my $p = $_[0];
<html>
<head><title>Programming languages</title></head>
<body>
<h1>= $p->{page_title} ?></h1>
<br />
<ul>
? for my $language (@{ $p->{languages} }) {
<li>= $language->{language} ?></li>
? }
</ul>
</body>
</html>

template_speed_file.ht – HTML::Template::*用のファイル

<html>
<head><title>Programming languages</title></head>
<body>
<h1>NAME=page_title ESCAPE=HTML></h1>
<br />
<ul>
NAME=languages>
<li>NAME=ll>*</TMPL_IF>NAME=language ESCAPE=HTML></li>
</TMPL_LOOP>
</ul>
</body>
</html>

template_speed_file.tt – Template::Toolkit用のファイル

<html>
<head><title>Programming languages</title></head>
<body>
<h1>[% page_title | html %]</h1>
<br />
<ul>
[% FOREACH language IN languages %]
<li>[% language.language | html %]</li>
[% END %]
</ul>
</body>
</html>

HTMLエスケープあり/なしのスピードについて

tokuhiromさんのコメントにあるように、Text::MicroTemplateは自動でHTMLエスケープがかかる一方、他のテンプレートエンジンでは手動でやる必要があるので、HTMLエスケープを入れて測り直してみました。ちなみに上に載せているベンチの結果は、HTMLエスケープを入れたものになっています。

特筆すべきなのは、HTML::Template::CompiledがキャッシュありかつHTMLエスケープありの場合、HTMLエスケープなしに比べてパフォーマンスがかなり劣化している点です。(その他はちょっとずつパフォーマンスが劣化していますね)。

キャッシュなしかつHTMLエスケープなし

$ perl template_speed_file.pl 3000 0
Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  4 wallclock secs ( 3.85 usr +  0.10 sys =  3.95 CPU) @ 759.49/s (n=3000)
HT::Compiled: 10 wallclock secs ( 9.99 usr +  0.09 sys = 10.08 CPU) @ 297.62/s (n=3000)
   HT::Pro:  1 wallclock secs ( 0.21 usr +  0.02 sys =  0.23 CPU) @ 13043.48/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  2 wallclock secs ( 2.35 usr +  0.05 sys =  2.40 CPU) @ 1250.00/s (n=3000)
        TT:  8 wallclock secs ( 7.83 usr +  0.15 sys =  7.98 CPU) @ 375.94/s (n=3000)
                Rate HT::Compiled          TT          HT          MT    HT::Pro
HT::Compiled   298/s           --        -21%        -61%        -76%       -98%
TT             376/s          26%          --        -51%        -70%       -97%
HT             759/s         155%        102%          --        -39%       -94%
MT            1250/s         320%        233%         65%          --       -90%
HT::Pro      13043/s        4283%       3370%       1617%        943%         --

キャッシュなしかつHTMLエスケープあり

Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  5 wallclock secs ( 4.60 usr +  0.09 sys =  4.69 CPU) @ 639.66/s (n=3000)
HT::Compiled: 10 wallclock secs (10.56 usr +  0.10 sys = 10.66 CPU) @ 281.43/s (n=3000)
   HT::Pro:  1 wallclock secs ( 0.20 usr +  0.04 sys =  0.24 CPU) @ 12500.00/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  2 wallclock secs ( 2.39 usr +  0.07 sys =  2.46 CPU) @ 1219.51/s (n=3000)
        TT: 10 wallclock secs ( 9.65 usr +  0.17 sys =  9.82 CPU) @ 305.50/s (n=3000)
                Rate HT::Compiled          TT          HT          MT    HT::Pro
HT::Compiled   281/s           --         -8%        -56%        -77%       -98%
TT             305/s           9%          --        -52%        -75%       -98%
HT             640/s         127%        109%          --        -48%       -95%
MT            1220/s         333%        299%         91%          --       -90%
HT::Pro      12500/s        4342%       3992%       1854%        925%         --

キャッシュありかつHTMLエスケープなし

$ perl template_speed_file.pl 3000 1
Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  3 wallclock secs ( 2.50 usr +  0.00 sys =  2.50 CPU) @ 1200.00/s (n=3000)
HT::Compiled:  0 wallclock secs ( 0.15 usr +  0.00 sys =  0.15 CPU) @ 20000.00/s (n=3000)
            (warning: too few iterations for a reliable count)
   HT::Pro:  0 wallclock secs ( 0.10 usr +  0.04 sys =  0.14 CPU) @ 21428.57/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  0 wallclock secs ( 0.21 usr +  0.00 sys =  0.21 CPU) @ 14285.71/s (n=3000)
            (warning: too few iterations for a reliable count)
        TT:  1 wallclock secs ( 1.19 usr +  0.01 sys =  1.20 CPU) @ 2500.00/s (n=3000)
                Rate          HT          TT          MT HT::Compiled    HT::Pro
HT            1200/s          --        -52%        -92%         -94%       -94%
TT            2500/s        108%          --        -82%         -87%       -88%
MT           14286/s       1090%        471%          --         -29%       -33%
HT::Compiled 20000/s       1567%        700%         40%           --        -7%
HT::Pro      21429/s       1686%        757%         50%           7%         --

キャッシュありかつHTMLエスケープあり

Benchmark: timing 3000 iterations of HT, HT::Compiled, HT::Pro, MT, TT...
        HT:  3 wallclock secs ( 2.69 usr +  0.00 sys =  2.69 CPU) @ 1115.24/s (n=3000)
HT::Compiled:  0 wallclock secs ( 0.28 usr +  0.00 sys =  0.28 CPU) @ 10714.29/s (n=3000)
            (warning: too few iterations for a reliable count)
   HT::Pro:  0 wallclock secs ( 0.13 usr +  0.02 sys =  0.15 CPU) @ 20000.00/s (n=3000)
            (warning: too few iterations for a reliable count)
        MT:  1 wallclock secs ( 0.22 usr +  0.01 sys =  0.23 CPU) @ 13043.48/s (n=3000)
            (warning: too few iterations for a reliable count)
        TT:  1 wallclock secs ( 1.84 usr +  0.00 sys =  1.84 CPU) @ 1630.43/s (n=3000)
                Rate          HT          TT HT::Compiled          MT    HT::Pro
HT            1115/s          --        -32%         -90%        -91%       -94%
TT            1630/s         46%          --         -85%        -87%       -92%
HT::Compiled 10714/s        861%        557%           --        -18%       -46%
MT           13043/s       1070%        700%          22%          --       -35%
HT::Pro      20000/s       1693%       1127%          87%         53%         --

Now Loading...

Perlで楽天ブックスジャンル検索APIを使う

oinume — Wed, 23 Sep 2009 14:27:14 +0000

PerlでAmazon Product Advertising APIのBrowseNodeLookupを行なうの楽天版です。Amazon Product Advertising APIはRESTしかないのですが、楽天ウェブサービスはRESTとJSONに対応しているので、今回はJSONを使ってみます。

(ファイル名はsample_books_genre_search.pl)

#!/usr/bin/env perl
 
use strict;
use warnings;
use Data::Dumper qw(Dumper);
use JSON::Syck qw(Load);
use LWP::UserAgent;
use URI;
 
my $uri = URI->new('http://api.rakuten.co.jp/rws/2.0/json');
$uri->query_form(
    developerId => 'Your Developer ID',
    operation => 'BooksGenreSearch',
    version => '2009-03-26',
    booksGenreId => shift || '000',
);
 
my $ua = LWP::UserAgent->new;
my $res = $ua->get($uri);
 
$Data::Dumper::Indent = 1;
if ($res->is_success) {
    print Dumper(Load($res->content)->{Body}), "\n";
} else {
    print $res->status_line, $res->as_string, "\n";
}

$ perl sample_books_genre_search.pl 000

と実行すると、以下のような結果が得られます。引数の”000″はルートのジャンルIDです。これを”001″のようにすると、”本”のジャンルの子ジャンルが取れます。

$VAR1 = {
  'BooksGenreSearch' => {
    'parent' => [],
    'current' => [],
    'child' => [
      {
        'genreName' => '本',
        'genreId' => '001',
        'genreLevel' => 1
      },
      {
        'genreName' => 'CD',
        'genreId' => '002',
        'genreLevel' => 1
      },
      {
        'genreName' => 'DVD',
        'genreId' => '003',
        'genreLevel' => 1
      },
(以下省略)
};

Amazonと楽天の両方のAPIを見ていて思ったのですが、Amazonのカテゴリを表すBrowseNodeは、例えば”本”とかそういうカテゴリだけじゃなくて、”岩波書店”みたいな出版社にも適用されています。例えば、”岩波書店”にはBrowseNodeIdとして”516508″が割り振られていて、子ノードには”岩波文庫”や”岩波現代文庫”があり、「出版社別」みたいな切り口でも商品を分類することが可能です。

一方で楽天の場合は、商品一つに対してジャンルという純粋な一つのカテゴリしか設定されないようなデータ構造になっています。サイトを作る上では、様々な切り口で商品を分類できた方が集客がしやすいので、個人的には楽天ウェブサービスにもBrowseNodeみたいな概念を取り入れてもらいたいなぁと思いました。(リクエストはしました)

というわけであまりまとまってないですが、こうやってECサイトのAPIが利用できると個人でもECサイトが持てるので夢が広がっていいなぁと感じています。といってもアフィリエイトだったら利益はたかが知れているので、よっぽど頑張らないといけないと思いますが…

PerlでAmazon Product Advertising APIのBrowseNodeLookupを行なう

oinume — Tue, 22 Sep 2009 18:24:10 +0000

AmazonのProduct Advertising APIで、あるカテゴリの下にあるカテゴリ(BrowseNode)を取得するPerlスクリプトを書いてみました。最初はNet::Amazonを使っていたのですが、オブジェクトを大量に生成するためかとてつもなく重いのと、返ってくるオブジェクトの構成がよくわからなかったので、自前で処理してみるとさくっとできました。

#!/usr/bin/env perl
 
use strict;
use warnings;
use Encode qw(encode);
use LWP::UserAgent;
use URI::Amazon::APA;
use XML::Simple;
use YAML qw(Dump);
 
unless (@ARGV) {
    print STDERR "usage: $0 browse_node_id\n";
    exit 255;
}
 
my $uri = URI::Amazon::APA->new('http://ecs.amazonaws.jp/onca/xml');
my $browse_node_id = shift;
$uri->query_form(
    Service     => 'AWSECommerceService',
    Operation   => 'BrowseNodeLookup',
    SearchIndex => 'Books',
    BrowseNodeId => $browse_node_id,
);
$uri->sign(
    key    => 'key',
    secret => 'secret_key'
);
 
 
my $ua = LWP::UserAgent->new;
my $res = $ua->get($uri);
my $content = XMLin($res->content);
my $children = $content->{BrowseNodes}->{BrowseNode}->{Children}->{BrowseNode};
if ($res->is_success) {
    print encode('utf-8', Dump($children)), "\n";
} else {
    print $res->status_line, $res->as_string, "\n";
}

$ perl sample_browse_node.pl 465610

とすると下みたいな感じで下の階層のカテゴリを表示します。ちなみに465610は本のBrowseNodeIdです。Net::Amazon–、URI::Amazon::APA++ということで。

---
- BrowseNodeId: 466284
  Name: 文学・評論
- BrowseNodeId: 466288
  Name: 思想・社会・ノンフィクション
- BrowseNodeId: 571582
  Name: 人文・思想
- BrowseNodeId: 571584
  Name: 社会・政治
- BrowseNodeId: 492152
  Name: ノンフィクション
- BrowseNodeId: 466286
  Name: 歴史・地理
- BrowseNodeId: 466282

YAPC::Asia 2009に行ってきました(9.10)

oinume — Thu, 17 Sep 2009 15:58:41 +0000

2009/9/10,11に開催されたYAPC::Asia 2009に参加しました。今年はフレームワークやORM系のセッションがとても豪華で全部聞きたいなと思っていたので、迷うことなく有給を取って参加。というわけで殴り書きですがメモと感想を徒然に書いてみます。

PSGI – Perl Server Gateway Interface

スライド

tokuhiromさんとmiyagawaさんのコラボレーション。PSGIは仕様でPlackは実装。HTTP::Engineには仕様とAPIと実装が全て入っていたのでこれを分離しましたよ、というお話。YAPCの1週間前ぐらいから開発し始めていてすごい勢いで実装されているらしいです。PlackはいわゆるReference Implementationですが、かなり速いという話でした。Reference Implementationという用語を聞いて、JavaのServlet APIをなんとなく思い出しました。

シックスアパートフレームワーク

shigetaさん
スライド

Six ApartではMTフレームワーク, ArcheTypeの2種類のフレームワークがある。
MTではMTオブジェクトがData::ObjectDriverを継承している。Data::ObjectDriverはSix ApartのCTOの人が作っているORマッパ。memcachedによるwrite-throughキャッシュが実装されてたり、shardingもサポートされている。たしか2年前ぐらいのYAPCでセッションやってたと思います。

驚きだったのは、TypepadではHTML::Templateを使っているということ。普通はTTとか最近だったらText::MicroTemplateのような高機能なものを使うと思うのですが、ななぜあえてHTML::Templateなんでしょうか。っていうのを質問すれば良かったと今になって後悔。

API Design

sartak – Shawn M Mooreさん。Mooseのコミッター。
スライド

Moose
Path::Dispatcher
HTTP::Engine
Dist::Zilla
IM::Engine

今日はこれらのプロジェクトが持つクールなAPIの話をします。大事なのはテストをたくさん書くこと！なぜならテストを書けば使いやすいAPIかどうかわかる！あとはMooseなどの話。HTTP::Engineは新しいサーバのInterfaceが出てきても一行書き換えれば対応可能なところが素晴らしい、と言っていました。
英語だったので話の内容の半分も理解できなかったのが無念…

Modern Catalyst

hidekさん。最近DeNAに転職した? らしい。スライド

Catalyst 5.8について
Mooseベースになった
M,V,Cの名前空間がdepreatedになった
NEXTが…
Catalyst::PluginなnamespaceのプラグインをCPANにあげるとmstにおこられるw

他のセッションでも「Catalyst 5.8使ってます」という話をちらほら聞いたのですが、Mooseベースになったら速度が遅くなったりしてないのかな、というのが気になっています。

ark – framework inspired by Catalyst

KAYACのtypesterさん。スライド

KAYACでは大量に自社サービスを作っている。
Catalystでもいいんだけど、もうちょっとライトなWAFがよかったのでHTTP::Engineをベースに作った。
CGIモードでも割とサクサク動くようになってる。
CGIの場合はクラスはlazy loadingするように工夫
あとdispatch tableのキャッシュもしている
テンプレートはText::MicroTemplate::Extendedというものを使うのが推奨されている。もともとはMojo::Templateをokuさんが切り出したもので、それを拡張している。
Ark::Models – CLIスクリプトからでもModelを使える仕組み。あとlazy loadingをやったり。
Ark::Form – HTML::Shakanベース
KAYACのArkで作られたサービスの一部はなんとソースコードが公開されている！
いなめなヶ崎
im.kayac.com

Ark、Catalystとほぼ互換っていうのがいいなぁというのと、日本のモバイル対応版が早くリリースされないかな、って思いました。モバイル対応はもう必須になりつつあるような世の中なので、そのあたりのベストプラクティスを積み上げていってほしいなぁと。

優しいモダンなWAFの作り方

dannさん。スライド

モダンなWAFとは？
- プラガブル – Plagger
- サーバ抽象化 – PythonのWSGI
- フルスタック – Rails
Angelos::PSGI::Engine
Plack::Requestを使ってる
HTTP::Routerを使ってる
シンプルなWAFなら2,3時間あれば作れちゃう！
次、WAFの拡張部分の作り方(プラグイン)
コアは小さく
拡張可能な箇所を限定(Controller, View, Middleware, Request, Response)
Hookポイントを明確にする
プラグインの種類は大きく分けると2種類
RequestやResponseのライフサイクルへのHook系
メソッドはやす系
適切なデフォルトセットの提供することが重要
そうしないとUnicode化するためのTIPSが乱立したり、Inflate/Deflateするための(ry
HTTP::EngineやPlack、HTTP::RouterなどのモジュールのおかげでWAF作りがかつてないほど簡単になっている！

Arkの話も聞いてて思ったのですが、Sinatraみたいなレベルであれば本当に2,3時間で作れそうな気がしました。これからフレームワーク戦国時代の幕開けですね。そして懇親会でも直接dannさんに言ったのですが、Angelosを早くリリースしてほしいです… (切実)

Booking.com & Perl

Cristina Nunesさん(from リスボン,ポルトガル)。スライド

Perl 5.8.8
Class::DBI
HTML::Mason
HTML::Template(forked version)
なぜPerl? –> 簡単で速い
なぜHTML::Template? –> 簡単
なぜClass::DBI? –> 聞き取れず(一番聞きたかったのに)
Apache + mod_perl
MySQL
memcached
git
Jabber
将来のゴール
- Perl upgrade
- Modules upgrade
- Apache + mod_perl upgrade (to 2.x)
- MySQL upgrade (to 5.1 or 5.4)
フロントエンドのWeb Server: 100台以上
MySQLサーバ: 100台以上
データセンターにあるサーバは700台以上
IT at Booking.com
- Perl developers
- Java developers
- Network engineers
- Sysadmins (社内SEみたいなものかな)
- Web designers
世界に25オフィスある
1900人の従業員
71000L hosts over 70 countries
4500+ distribution partners
24 languages available on website

Booking.comって初めて知ったのですが、ヨーロッパのホテルはかなり網羅されているという情報がIRCで流れてました。なんでいまだにClass::DBI使ってるんだろう、と思いましたが、mod_perlのバージョンも1.x系なので、やっぱりサーバの台数が多いとアップグレードも大変なのでしょうね。「Booking.comという会社は著名なPerl hackerを何人も抱えている会社なのです」という牧さんの補足がありました。

Key Value Store with O/R Mapper

yappoさん。スライド

Key Value StoreとO/R Mapperの合わせ技 –> Data::Model
Data::ModelはいわゆるO/R Mapper
- DBI, memcached protocol, Perl hash, Perl code, Gearman
- Q4Mにネイティブ対応
- 透過キャッシュ
- MixinによるSchemaクラスの拡張
- ちょっとなういイテレータ
なんで既製品では駄目だったのか？
- Class::DBI – DBICに移行する方向になってる。偉大なる先輩に感謝
- DBIx::Class – 過去に使っていたがあまりいい思い出がなかった
- Rose::DB, Jifty::DBI – 見る時間があまり取れず…
- DBIx::Moco – ドキュメント少ない。実際にサービスで投入されているものと公開されているモジュールの差異が激しい
- Data::ObjectDriver – Six Apart謹製。意外とテスト少ない＆document少ない。ただしコードは大分参考にさせてもらった
- DBIx::Skinny – 日本のPerl ORM専門家のもの。シンプルなスキーマに対して「生SQL書けます」はあまり魅力的じゃなかった。
結局調べているうちにORM作成のポイントがわかってきたので自分で作ることにした
ORMはSchema, Iterator, Row, SQL, DBの5つのものがあればよい
Data::Modelのデモ(詳しくはスライドを参照)
TokyoCabinetをストレージとして使う場合、データを小さくした方がキャッシュにのったり色々嬉しいので、データは圧縮して小さくするべし。
Perl標準のStorableはデータ効率が悪いことで有名 –> 代わりにMessagePackを使用(これがすごいらしい)
KVSがストレージならALTER TABLEが必要なくなる。FriendFeedの例のようにすれば、スキーマなくても大丈夫
MessagePackがとにかくすごいらしい

まずスライドがFiciaだったのが驚きでした。なるほど、そういう使い方できるんですねー。途中のData::Modelのチュートリアルでは、その高機能さ(透過キャッシュやMasterSlave、column_sugar)に驚きました。自分でもオレオレORM作ってるのですが、相当レベル違うなと感激しましたです。その他、MessagePackがすごい使えそう、というのがよくわかりました。圧縮のアルゴリズムがカリカリ過ぎです。

simple or mapper DBIx::Skinny

nekokakさん。スライド

なぜ自分でORMapperを作ったか？
DBIx::Classが微妙…
- 便利だけど発行されるSQLが微妙
- パフォーマンスが出なかったりする
- 生成されるオブジェクトがでかすぎるため重い
- カスタマイズしようにもソースがでかすぎる
- DBICで速度でない場合は生SQL書くことがあるが、Inflateとかしてくれない
生SQL書いてinflate/deflateしてくれるライトなものでいいんじゃないか、というところにたどりついた
DBIx::Skinnyのデモ
relationshipは特に何もしない
コアは小さく、がモットーなので、拡張したい人はラッパーを書けばいい
何人かの人に興味持ってるみたいなので、Skinnyみたいな方向性はありなのだなと思った。

ちょいと前にSkinnyのバグを見つけたのでメールでパッチ送ったりしていて、ちょうどYAPC当日にnekokakさんと直接お話させてもらう機会があったのですが、いやー非常に嬉しかったです。懇親会でもお話しさせてもらったのですが、やっぱり生SQL全然ありだよね、と思いました。もともと自分がSkinnyに興味を持ったのは、自分が3年前ぐらいに会社で作ったO/R Mapperと非常に設計思想が似ていて、「へー」と思ったのがきっかけです。(もちろんSkinnyの方がAPI的にも非常に洗練されているのですが…)

というわけで、自分もDBIx::Thinというのを作っているのですが、早く安定板をリリースしないと。とにかくエンジニアとしてはとても刺激になったセッションでした。

『Ficia』インフラとPerlにまつわるエトセトラ

hirose31さん＠えとらぼ。スライド

Linux 2.6, Apache2, mod_perl 2.0
mod_perl 2のメモリ関連のチューニング
推測するな計測するべし(ps, top)
fork(2) – Copy On Write
/proc/PID/smaps (kernel >= 2.6.14) – 共有領域: Shared_Clean + Shared_Dirty
いわゆる親プロセスと子プロセスの共有メモリ領域の話
id:naoyaさんの日記が詳しい
使うモジュールは親プロセスで起動時に(startup.plなどで)ロードする –> 子プロセス独自のメモリ領域にロードしないので節約になる
Apache起動直後は共有率99%。時間が経つと共有率が40%ぐらいになり、プロセスのメモリ消費量が多くなる
使用しているモジュールの一覧をどうやって取得するか？
Apache2::Status –> Loaded Modules で一覧を確認
あと親プロセスでモジュールをロードしておくと、コンパイル済みで即戦力になるのでオーバヘッドが少ないらしい
サイズがもりもり太っているモジュールを探す方法 – Apache2::Status + B::TerseSize
。Memory Usageで一覧を確認
nagiosで少しでもswapしたらメールを飛ばすようにしている
以降、httpd.confの話
StartServers != {Min,Max}SpareServers
忙しい時はMaxに。ヒマになったらStartServersの数に戻る –> forkするのがむだ？だったら最初から全プロセス起動しておいた方がいい
/etc/init.d/httpd stop
stopしたのに新規リクエストが来ちゃう(ロードバランサーのヘルスチェック後とか)
start – 起動時からフルでプロセスを起動するので、start直後にリクエストが来ると負荷が高くなってしまう。一定時間おいてからロードバランサーに入れる必要がある。
ロードバランサーのヘルスチェックのURLを動的なものにしておき、フラグファイルがあったら200を返すようにするとか。
あとはmatrixの話

mod_perlのチューニングのような話は、最近はみんなFastCGIに移行しているのかあまり聞かないので、非常にためになりました。あと、StartServersで最初から一気にプロセス立ち上げておく技は昔考えたことあったのですが、LBのヘルスチェックとか面倒だなぁと思って挫折した経験があります。なるほど、ヘルスチェックのURLを動的にしてフラグファイルで管理っていうのは全然ありだなと思いました。というかRubyのpassengerとかはそんな感じの実装になってますね。

一日を通しての感想

おそらく初めて丸一日ぶっ通しでセッションを聴いたのですが、最後の方はやはり集中力がもたなくていいセッションでもあまりちゃんと聴けなかったのが残念です。ただ、エンジニアとしてのモチベーションは上がりまくりで、懇親会中も「早く家帰ってコーディングしたい」と実は思ってました。あと酔った勢いでDBIx::Skinnyのポスグレ対応とかしたのですが、バグとかテストを sfujiwara さんに面倒見てもらったようで、非常に恐縮でした…

個人的に非常に参考になったのは、Ark、Data::Model、DBIx::Skinny、Ficiaのインフラでした。WAF, ORMapper, インフラの話が聴けて大満足です。

YAPC::Asia 2009に行ってきました(9.11)

oinume — Fri, 11 Sep 2009 13:21:17 +0000

すごい今更ですが、記憶が残っているうちに9.11のYAPC::Asiaのレポートをば。2日目も色々セッションに参加したのですが、特に記憶に残っている最初の2つだけ。

DeNA loves Perl

notoさん。スライド

DeNAはエンジニアは100人ぐらいで半分ぐらいはモバゲー
今回のYAPCでも3人がセッションで発表している。(hidek, zigorou, matsuda)
最初のbiddersはJava+Oracleだった
モバオクを川崎さんが作る時に初めてPerlをつかった
Perlは読みやすい、実行速度も速い
最近はmyDNSのDNS RRの代わりにLVSを使うようになった
memcachedも使っている
MySQLのshardingもしている。モバゲーでは90個ぐらいに分割されている
mobamail
モバイルのメール配信 – キャリアの都合で接続がdenyされることがある。大量に送り続けるとdenyされる
キャリアのMXレコードは異様に少ない
- docomo.ne.jp – 4IP
- ezweb.ne.jp – 1IP
- softbank.ne.jp – 1IP
キャリアのメールサーバが少ないから、送信側で送信先を分散できない
mobamail – Perlで実装したモバイルメール向けの配信サーバ。配信するだけなのでMTAじゃない(SMTP受ける方は実装してない)
コネクションを貼るところでIO::Selectを使っている
キャリアの制限の範囲内でなんとか最速で配信できるようにする。キャリアごとに細かい設定ができるように。
SIELLA Engine – より速い。さらに自分たちで設定しなくても楽。最近はこっちを使っている(ズコー)
(話は変わって)モバゲーのオープン化について
OpenSocial + Game API 法人に解放
10/5 にフォーラム。来年1月以降に一般公開
DeNAのエンジニアのポリシー – ビジネスの成功にコミットすること
お金で解決しない。技術で「安く、早く」
ビジネスの成功を重視しているので、きれいな技術が二の次になっているのは否めない
100人近くPerlエンジニアがいるのにCPANコミットがない
- 他社の特許侵害のリスク(一部上場しているので目をつけられてしまう)
- やりたい人がいたら推奨しようとしているが…
DeNAのPerlでの開発方針
- 「一筆書き文化」：再利用せいや汎用性の設計に時間をかけるくらいならそういうことは考えずに書く方が速い
- サービス単位の独自性・機動性重視＝モジュールの共有なし
- 割り切りの思想、逆転の発想、これでサービスを速くリリースしてきた面も
今後の展望
- 大きな開発チームでのポリシー
- more test code
- MobaSiFの次のバージョン
DeNAで一緒にコードを書きましょう!
- as DeNA software engineer / architect
- as developer of moba-ga town
- as CPAN author

携帯向けのメール配信でSIELLA Engineを使っているのが驚きでした。ああいうモバイル向けのパッケージ製品って他にもKlabのアクセルメールとか良さそうなのいっぱいあるし、やっぱり餅は餅屋にって感じなのでしょうか。

モバゲーのAPIがオープン化されるということは、PC向けにFlashでゲームも作れるのかな？というのが気になりました。現状モバゲーのPCサイトってモバイル版のはりぼてみたいなものなので、これを機にPCサイトも盛り上がるといいのかなぁと。

endeworksでのWeb Appの作り方

33rpmさん(船木太郎さん)。スライド

牧さんが代表の会社です。
特別なことはやっていない
開発サーバは用意していない(個人のMac上で開発)
Test::FITesque が最近の流行り（読み方よくわからない）
ディプロイ – git pullするだけ。ディプロイツールといったものは使用していない
Apache+FCGI – daemontoolsでFCGIのプロセスを管理
Catalystを使用
Mooseを使用 – Catalyst 5.8をプロダクション環境で使用
APIモジュール
CatalystのModelを使用しない
CatalystのModelは当たり前だけどCatalyst依存
ModelはWebという枠組みの外、たとえばCLIやWorkerからも呼び出したいことが多い
MyApp::API::* という名前空間
- 中身はORM+アプリケーションロジック
- キャッシングのロジックもここ
DIコンテナは？ – アプリケーション全体で共有されるインスタンスはRegistryというモジュールに格納
Registry – メモリ上のKVSに保存するだけのsingleton object
Formの作成はHTML::FormFuを使用
- 生成されるHTMLに不満
- HTML::FormFuのValidatorはとてもよくできているので、レンダリングはさせないでValidatorだけ使うというのが最近の流行
pixis(フレームワーク)の説明(githubで公開されている)
- WebサービスやSNSでありがちなメッセージ管理などのソーシャル機能をまとめたフレームワーク
- Catalyst 5.8依存
- 依存モジュールが多い