given-when を dispatcher としてつかう場合の注意事項 せっかく given-when 構文をつかえるのだから、以下のように Dispatcher を書けばいいのではないか、という話があったので実際つかってみていたのだが、このような書き方は非常に低速であることがわかった(too slow)。 use 5.010; sub dispatch { my ($class, $c) = @_; given ([$c->request->method, $c->request->path_info]) { when (['GET', '/']) { return call("Root", 'index'); } ... } } 以下のようなベンチマークスクリプトをうごかすと 25倍遅い。 use strict; use warnings; use Benchmark qw/:al
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
最近ドコモ回線があまりにも詰まったり繋がらなかったりすることが多くてどうにも我慢できなくなったことと、たまたまmineoがキャンペーンをやっていてコストダウンできそうなので勢いでmineoに乗り換えた。後悔は全くしていない。 数ヶ月前まではドコモ回線がつながりにくいこと以外はOCNは特に不満もなく、Musicカウントフリーオプションの存在もあり3年ほど使っていた。ただ、最近は新規契約を停止していてirumoという改悪されたMVNOに軸足を移す流れがあるのと、その影響でOCNモバイルONE自体がもう改善されないリビングデッド状態になっていたので、緩く乗り換え先を探していた。 mineoにしようと思ったのは 1.5Mbpsなら使い放題のオプションがある ドコモ以外の回線も選べる という点で、実際乗り換えてみてよかったと思った。それ以外にも通話系のオプションが充実してたり、ギガを永遠に貯められる
Benchmark.pm の cmpthese は手軽に速度の比較ができるのでとても便利。でも、そもそも何のパフォーマンスを比較しているのか？ ソースコードを読めばわかるけど、 perl プロセスのCPU使用時間 あるいは、上記＋子プロセスのCPU使用時間 を測定している。換言すると、プロセス間通信のオーバーヘッドやサーバ側での処理時間はベンチマーク結果に反映されない。つまり、サーバのベンチマーク（あるいはプロセス間通信やI/O待ちを含むベンチマーク）を比較したい場合には、cmpthese を使うべきではない。 ＃サーバと通信するクライアントモジュールのベンチマークがほしい、といった場合はOK どうしても Benchmark.pm を使いたいなら、 use Benchmark qw(:hireswallclock); my $r = timethese(...); for my $v (v
ベンチマークを取る際に、それぞれの手法ごとに初期化や終了処理が必要なんだけど、それら処理を除いた、コアの部分の数値を比較したいことって結構ある。そういう場合は、以下のように書けばいい。ということを理解したのでメモ。 #! /usr/bin/perl use strict; use warnings; use Benchmark (); my %bench; Benchmark::enablecache(); for (my $i = 0; $i < 100; $i++) { # ここでいろいろ初期化 push_bench('a', sub { for (1..100000) {} }); # ここでいろいろ終了処理 } for (my $i = 0; $i < 100; $i++) { # ここでいろいろ初期化 push_bench('b', sub { for (1..200000) {
サーバ1台あるいは、サービス全体で、いったいどのくらいのパフォーマンスがあるのかについて計測することは、とても重要なことです。 僕が管理しているサービスは、最初にサービスをはじめるときはある程度の規模感を想像しながらまとまめてサーバなどを調達しましたが、サービスを開始してすこしたってきたところで今後の投資計画をたてたいため、月ごとのトラフィックを予測して、いつごろにどのくらいのサーバなどが必要か情報を調査して計画を立てることになりました。もちろん、最初からちゃんとベンチマークを行って計測してサーバを調達したほうがいいのですが、小さい会社では最初はサービスの開発に注力したいため、なかなかそういった時間をとれないのもまた事実です。 ということで、現状のサービスのパフォーマンスを測定するために必要な CentOS 上で動作するコンソールベースのオープンソースなベンチマークツールについて調べてみま
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
(追記：この用途ではList::Util::firstを使うのは誤りで，List::MoreUtils::anyが意図されたコードです。効率についての結論は変わりません) List::Util::first{expr}は組み込みのgrep{expr}に似ているが，exprが最初に真になった段階でその値を返すので，grep{expr}よりも効率がいいと説明されることが多い。しかし，実際にベンチマークを取ってみると，多くの場合grep{expr}より遅い。最初の要素が真になるというfirst{expr}にとって最適な条件でさえ，要素数が40を越えたあたりでようやくgrep{expr}とほぼ同程度の速度になる。したがって，List::Util::first{expr}が効果的なケースはそれほど多くないと思われる。 また，もし単なる文字列の検索でよく，その検索をプログラム中で繰り返すならば，gre
全文検索エンジン性能評価 (2006/08/19) 概要 弊社が開発致しました圧縮インデックス方式全文検索エンジン「Sedue」（Sedue 24やGenome Sedueで利用されているエンジンSedue コア）とオープンソースな全文検索エンジン(HyperEstraier, Lucene, Senna)との性能比較を行いました。検索サーバーにはマシン1台のみを使用しました。 更新履歴 2006/09/13 インデクシングの作成方法に関して分かりにくい表現を訂正 使用環境 ベンチマークを取るに際しまして以下のようなスペックのマシンを使用致しました。 CPU: AMD Athlon(tm) 64 Processor 3000+ Memory: 2GB OS: Linux pfidev1 2.6.16-1.2111_FC4 #1 Sat May 20 20:00:28 EDT 2006 x8
App::Benchmark::WAF tokuhirom/yappo/kazuho/hidekさんあたりが軽量なWAFの開発をなんか熱病に浮かされたかのようにしはじめたので、こりゃ負けてられないとApp::Benchmark::WAFを書きましたよ。 Apache::Testを使って、apacheから実際にHTTPリクエストサイクルを通って、CGIモードとmodperl（メモリに一度載せたらそれを再利用）する状態でベンチを取れるようにした。"make test"とすれば全てのフレームワークに対してab -c 100 -n 1000して計測する。 現在実装している中で、俺のMacBook上での計測値は以下の通り： # [cgi-app (cgi)]: 28.01 [#/sec] (mean) # [cgi-object (cgi)]: 34.92 [#/sec] (mean) # [cgi
仕事で Benchmark モジュールを使う機会があったので、使い方＆結果情報の読み取り方をまとめてみました。基本的には perldoc 読めばオールオッケーでしょ？と思っていたのですが、docs では結果情報の読み方についてはあんまり触れられていなかった為、ガッツリ補足してみました。 基本 とある２種類のコードの実行速度を比較計測するには以下のようなソースを記述します： bench.pl #!/usr/bin/perl use strict; use warnings; use Benchmark qw(timethese cmpthese); sub hogeLoop1 { my $str; for my $i (1 .. 10000){ $str .= $i } } sub hogeLoop2 { my $str; for my $i (1 .. 20000){ $str .= $i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
