StarmanとStarletの違いはいくつかありますが、Starletにいくつか手を加えたあと、速度はどうなっているのか比較してみた。 なお、以下の記事はHello Worldのベンチマークなので、実際のアプリケーションのパフォーマンスにはあまり影響がないと思われます。 各ソフトウェアのバージョンは以下。 Plack-1.0023 Starman-0.3008 Starlet-0.18 Starletのベンチマークとほぼ同じアプリケーションを書いてサーバを起動した use Plack::Builder; use Plack::Request; my $length = 12; my $body = 'x'x$length; builder { enable 'AccessLog', logger => sub { }; sub { my $env = shift; my $req = P
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの？」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること！ まずこのお話の前提：mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない（←ここポイント）。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう？ まずアプリケーションを組む側が「やっちまったなぁ？」な件：P
バージョン0.13以下の Plack::Middleware::Session の Plack::Session::Store::DBI は fork を伴うサーバで利用するとデータベースとの接続でエラーになるなどの問題がありました。バージョン 0.14 でエラーを回避できるオプションが加わっています。 http://search.cpan.org/~miyagawa/Plack-Middleware-Session-0.14/ SYNOPSISにある builder { enable 'Session', store => Plack::Session::Store::DBI->new( dbh => DBI->connect( @connect_args ) ); $app; }; このコードでは、builder実行時に DBI->connect も実行されデータベースに接続します。P
Plack::Server::Standalone 系を使ってウェブアプリケーション開発と運用が楽になる話 - JPerl Advent Calendar 2009 Perl に関するちょっとした Tips をのっけてみるよ。ちゃんと続くかな？ 既存の環境に対する不満 Perl のウェブアプリケーションを構築するにあたっては、リバースプロキシと mod_perl を組み合わせるか、あるいは FastCGI (ExternalServer) を利用するのが一般的だと思います。しかし、どちらをとっても、環境を構築して設定するのが難しいというのが個人的な不満でした (mod_redirect を設定したり mod_fastcgi にパッチをあててインストールしたり startup.pl を書いたり...)。自分が Plack の開発 (主に Server::Standalone と Server
アプリケーションで利用するモジュールは、できる限り先読み(preload)しておきたい。先読みしておけば、アプリケーション全体のメモリ消費が抑えられるし、遅延ロード(Lazy Load)のコストがなくなります。 モジュールの先読みは、例えば以下のように行います。 starman --preload-app MyApp app.psgi or starman -MFoo -MFoo::Bar -MBaz::DBI app.psgi あえて遅延ロードするという場合を除いて、先読みは行って損はないはず(小さいアプリだと、効果は小さいですお ^-^)。 Plack::Middleware::Debug::LazyLoadModules 明示的に use するモジュール群のピックアップはたやすい。なにせ明示されているから。しかし、暗黙に遅延ロードされてるモジュールやライブラリは調べてみると多く見つか
ヒゲをはやして、髪をモヒカン気味に切って、ベストを着ていたら「dankogaiさんですか！」と呼ばれまくって失礼ですがショックを受けてしまい、とりあえずヒゲを剃ってみたyusukebeです。気合い入れて書きます。 はじめに さて、今回はPlack::RequestやTemplate-Toolkit、XML::Feedといったモジュールを使って、小さな、だけどもなかなか使えるWebアプリを作る過程を紹介します。これを通して、今話題であるPlackについてやWebアプリの仕組みについて多少でもわかっていただければこれ幸いでございます。 実はこのネタ昨日の夜考えて作ったものであります。というのも「YouTubeの動画を垂れ流しで好きなように、みてーな」とふと思ったからです。例えばYouTube内で「Perfume」と検索をすると個別の動画以外に「再生リスト」または英語では「Playlist」とい
PSGIとPlackと 〜 軽量フレームワークAmon２入門 (３) 〜 さて、今回は裏をかいて、いったん本題のAmon2の話からはずれて、PSGI/Plackのはなしをしましょうかね。 PSGI/Plackは基本的にはアプリを書く人は知る必要はあまりないのですが、概念ぐらいは知っておくにこしたことはない、というところです。 さて、数年前のYAPCでわたくしが口を酸っぱくして申し上げたことを皆さんはおぼえているでしょうか。そう、一番大事なのは「PSGIは仕様。Plackは実装」ということなのでした。ここだけ把握していれば十分なので、PSGI/Plack の詳細に興味がない人はブラウザの Back ボタンを連打してください。 PSGIってなんだ?PSGIとは「ウェブアプリケーションとアプリケーションサーバーの間のプロトコルのこと」です。Perlの基本的なデータ型であるArrayRef, Ha
だいぶ以前 Plack::Server::AnyEvent::Prefork というのを書いて某所で使っていたのですが、ここ数日で事例がもうひとつ増えたついでに Twiggy ベースに書き直してCPANリリースしました。 https://metacpan.org/module/Twiggy::Prefork 使うには、 $ plackup -s Twiggy::Prefork -a app.psgi な感じで、Server::Starterにも対応しているので、 $ start_server --port 5000 -- plackup -s Twiggy::Prefork -a app.psgi とすれば、hot-deployも可能です。 起動オプションは、Twiggyがサポートしているオプションに加えて、 —max-workers preforkするworker数 —max-reqs-
The document discusses various web application frameworks and deployment methods in Perl. It covers common frameworks like CGI, mod_perl, Catalyst, and PSGI. It then discusses running PSGI applications with plackup, configuring middleware, and deploying PSGI apps behind web servers or as standalone daemons. Finally, it briefly covers application deployment and management with tools like daemontool
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
