おそらくはそれさえも平凡な日々: サーバーマシンのコア数に応じてworker数を調整する方法
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ 便乗ポスト。最近は、上記内の「シェルスクリプトでラップする方法」で運用していることが多いです。その場合のone more tips. appサーバーごとにマシンスペックが違う場合がたまにあって、その場合マシンごとに worker数を調整したいけど、deployの都合上サーバー起動スクリプトは同じやつを使いた いってことがあります。 そこでおすすめなのが、CPUコア数に応じてworker数を計算する方法です。 シェルスクリプトの場合、 % cat app.sh #/bin/sh NCPU=`getconf _NPROCESSORS_ONLN` WORKERS=$(expr $NCPU \* 5) exec plackup -E production -s Starlet --max-workers=$WORKERS と
Which should I use: Starman or Starlet?
A discussion came up on #plack IRC channel earlier, and we realize that there’s no good (official) documentation available to address the differences between the two popular Plack HTTP servers, Starman and Starlet. Besides the similarity in their names, they are actually similar in what they do: they do serve HTTP requests, and the process model is pre-forked (i.e. fork off a number of HTTP worker
Gazelle: new Simple and Fast Plack Handler for Performance Freaks - blog.nomadscafe.jp
Gazelle という新しいPlack::Handler(Server)をリリースしました https://metacpan.org/release/Gazelle 前のISUCONの結果報告で「Chobi」として紹介していたものを名前を変更しました。 GazelleはnginxやApacheでreverse proxyを行うことを前提に書かれたPlack::Handlerです。nginxの後ろにunix domain socketを利用して配置した場合、”Hello World”のベンチマークで、Starmanの3倍、Starletの1.7倍程度高速に動作します。 一番左はnginxで静的ファイルを配信した場合のQPSです ベンチマークの詳細はこちら↓です https://github.com/kazeburo/Gazelle/wiki/Benchmark 特徴など Gazelleは以下
The Tale of Plack - YAPC::Asia Tokyo 2010
http://yapcasia.org/2010/talks/63D5EA98-BC8C-11DF-8791-B9FC0F276C45 皆さん、お疲れさまです。ちょっと夏は暑いんで脱いじゃいましたけれど、さっきフェライト会議室の前に居たら、が酒臭くて、僕もついつい飲んでしまいまして。（笑）２本しか飲んでいないんで。（笑） 今日は何の話をしようかなと思って、今回ゲストという形で呼んでいただいて、スタッフの皆様、特に牧さん、それから櫛井さんはじめ、あとボランティアの皆さんに、最初に感謝の言葉を言いたいと思います。ありがとうございました。（拍手） ちょっとだけ自己紹介をしますと、今サンフランシスコに住んでいまして、今週の水曜日に帰ってきまして、来週また帰っちゃうんですけれども、もう４年前に引っ越して、ずっと住んでいるんですが、まだビザで働いているんですけれど、今グリーンカードを取ろうとしていて、
おそらくはそれさえも平凡な日々: Plack::Middlewareで$envの中身を見るテストを書く方法
Plack::Middlewareの中で $env->{'psgix.hoge'} 的な何かを突っ込むことはあるん じゃないかと思うが、そのテストをどう書くかという話。 Plack::Testだとレスポンスは見られるが、$envはもう見られない。 結論を言ってしまうと、$envをシリアライズして、response bodyに突っ込んでしまう $appを作るのが乱暴かつお手軽かと思う。 以下サンプルコード。 package Plack::Middleware::Hoge; use strict; use warnings; use parent 'Plack::Middleware'; sub call { my ($self, $env) = @_; $env->{'psgix.hoge'} = 'fuga'; $self->app->($env); } このMiddlewareをテストす
Plackで実装したメールサーバ"Haineko"のその後/Shibuya.pl #1
Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon のLTで発表したスライド
Plack::Middleware::Session::Simple has been released - Hateburo: kazeburo hatenablog
English document is available on metacpan! Plack::Middleware::Session::Simpleをリリースしました。Plack::Middleware::Session(Store::Cache & State::Cookie)と互換性を保ちながら、効率よく動作することを狙っています。 必要なときに必要なだけ Set-Cookie ヘッダを発行する 必要なときだけストレージにアクセスする 弊社のようなハイトラフィックなサービスを運営している場合には、できるだけリソースをケチりたいので、そういう思想なものが必要となった。互換性があるので負荷が低いところで使っても問題が起きないと思う。 使い方 Plack::Middleware::Sessionで以下のように設定していたなら、 my $cache = Cache::Memory::Si
Plack::Request::WithEncodingがなぜ便利なのか | おそらくはそれさえも平凡な日々
Plack::Request::WithEncoding というモジュールをリリースしました 上記の記事にも書いているのですが、Plack::Request::WithEncodigが便利なのは、単に車輪の再発明がされまくっているのが無駄感あるってのもあるんですけど、 個人的には$env->{'plack.request.withencoding.*'}に共通の格納位置を獲得したってのが大きいと思ってます。 例えば、リクエストの文字コード判別ってのは結構だるいのですが、アプリケーションの前段のPlack::Middlewareで、リクエストのエンコーディングの判別をして $env->{'plack.request.withencoding.encoding'}に格納しておくみたいなことをすることにより、よしなに文字列をdecodeしたりすることが出来るようになります。 まーそんなことを考え
PATH_INFO and Router::Simple - tokuhirom's blog
Dear Miyagawa san, Plack::Builder's mount function makes empty string PATH_INFO on following case. use v5.14.0; use Plack::Builder; use Plack::Util; use Test::More; use Plack::Test; use Plack; note "Plack: $Plack::VERSION"; my $app = builder { mount '/app/' => sub { my $env = shift; [200, [], [$env->{PATH_INFO}]]; }; }; test_psgi app => $app, client => sub { my $cb = shift; { my $req = HTTP::Reque
Plack::Middlewareの書き方 - ゆううきブログ
前回，Plack::Middleware書いたので，Plack::Middlewareの書き方をメモしておく． Plack::Middlewareモジュールに最低限必要なのは基本的に2つしかない． Plack::Middlewareを継承することcallメソッドを実装しておくだけ． callメソッドの返り値はPSGI形式のレスポンスである． リクエストがとんでくると，builderブロック内でenableした順番にそれぞれのcallが発行される． package Plack::Middleware::MyMy; use strict; use warnings; use parent 'Plack::Middleware'; sub call { my ($self, $env) = @_; return $self->app->($env); # 次にenableしたMiddleware
#10 2012年に作ったものを振り返りつつProcletマジ便利 - KAYAC engineers' blog
2012年も残すところあと20日ほどとなりましたが皆様いかがお過ごしでしょうか。@fujiwara です。 このエントリは tech.kayac.com Advent Calendar 2012 10日目の記事です。 テーマが「私の中のマイイノベーション 2012」ということで、まずこの1年に作ったものを自分の blog エントリから振り返ってみますと… Perl から Fluentd にログ出力 - Fluent::Logger リリース 今年一番話題になったミドルウェアといえば fluentd でしょうか。その fluentd に Perl からログを出力するためのモジュールです Parallel::Benchmark というモジュールを書きました 並列にプロセスを起動して負荷を掛けるベンチマークを簡単に作るためのフレームワークです。弊社の主にソーシャルゲーム案件で、リリース前の負荷テ
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ - blog.nomadscafe.jp
PSGI/Plack/PSGIアプリケーションを動かす時に一番使われているのは plackup でしょう。 $ cat app.psgi use Plack::Builder; use MyApp; my $app = MyApp->psgi_app; builder { enable 'ServerStatus::Lite', => ..; $app; }; $ plackup -E production -s Starlet --max-workers 30 --port 5000 -a app.psgi plackup コマンドの -s にハンドラ名を指定して起動します。本番環境では -E や $ENV{PLACK_ENV} を指定してStackTraceやLintといった開発に便利なPlack::Middlewareが追加されないようにする必要がありますね。 Starmanの場合は
Monoceros雑感 - kazuhoのメモ置き場
Monoceros は @kazeburo さんが開発してる Plack 用ウェブサーバ。prefork型だけど、待機中の接続をイベントドリブンのマネージャで管理することで、同時接続10,000本とか行ける（ソケットの受け渡しは SCM_RIGHTS とか使う）。 で、雑感 大好き！！！ Starletより遅い問題は、以下のようにすれば解決できると思う listen するソケットに TCP_DEFER_ACCEPT つけて、accept(2) は worker でのみ実行する worker は HTTP レスポンス送信後に read(2) してみて、後続のリクエストが来てない場合にのみ、マネージャプロセスにソケットを返還する (追記) 「返還」ではなく、マネージャプロセスが管理しているソケットのいずれかにデータがきている場合のみ、そのソケットとworkerのソケットを「交換」する、とすれば
Plack/PSGIアプリケーションのメモリリークをDevel::Leak::Objectでチェック - blog.nomadscafe.jp
dannさんが以前Catalystでやってたのを参考に、Plack/PSGIアプリケーションのメモリリークを Devel::Leak::Object で調べる方法 plackup を -MDevel::Leak::Object 付けて起動 $ plackup -MDevel::Leak::Object=GLOBAL_bless -e '$Devel::Leak::Object::TRACKSOURCELINES = 1' -s Starlet --max-workers=1 app.psgi -e ‘$Devel::Leak::Object::TRACKSOURCELINES = 1’ を付けると行数まで出力してくれる app.psgiはこんなの sub { my $env = shift; my $ref;$ref = bless \$ref, 'XXX'; [200,['Content
最近のPlack/Starletのパフォーマンス改善まとめ。最大2倍の性能向上 - Hateburo: kazeburo hatenablog
最近のPlackとStarletにはパフォーマンス改善のため次のような変更が加えられています。 Plackに対する変更 (カッコ内はバージョン) Plack::Request::query_parameters の最適化 (1.0018) Plack::Middleware::AccessLog に Apache::LogFormat::Compilerの導入 (1.0023) Starletに対する変更 local $SIG{..} を無くし、rt_sig* system call が呼ばれる回数を削減 (0.17_01) headerとbodyを結合して一度に出力する閾値を1024から8192に変更 (0.18) ベンチマーク これらの変更の効果を確認するために、次のベンチマークを実行してみます まずアプリケーションはこんな感じ use Plack::Builder; use Plac
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
Plack::Middleware::AxsLog でフォーマットが任意に変更できるようになったよ & PM::AccessLogとのベンチマーク - blog.nomadscafe.jp
日本語でも書く Plack::Middleware::AxsLog バージョン 0.10 をリリースしました。 cpan: https://metacpan.org/release/Plack-Middleware-AxsLog 今までのバージョンでは、combined、common、ltsvの3つのログフォーマットしか使えなかったんだけど、新しいバージョンで任意のフォーマットが使えるようになりました。 AxsLogがPM::AccessLogに比べて速いのは、ログ文字列の生成を正規表現ではなく、単純な文字列連結でやっていたためで、その代わりにフォーマットを自由に変更できない制限がありました。 けど、このバージョンから Apache::LogFormat::Compiler を使っているので、速度を犠牲にすることなくフォーマットの変更が可能となりましたぞよ。 使い方 use Plack::
Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの？」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること！ まずこのお話の前提：mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない（←ここポイント）。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう？ まずアプリケーションを組む側が「やっちまったなぁ？」な件：P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dl.dropboxusercontent.com/u/224433/plackcon/index.html
Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon : ATND
