Perl Hackers Hub 第24回PSGI/Plack実践入門―Starman、Starlet、Twiggy、Plack::Middleware、Server::Starter（2） 前回の（1）はこちらから。 PSGIサーバ ここまで主にPSGIのアプリケーション側について見てきましたが、（2）ではアプリケーションを実行するためのPSGIサーバについて紹介します。 PSGIサーバの役割 PSGIサーバはPerlによるプログラムで、PSGIアプリケーションとアプリケーションが実行される環境を結び付ける役割をします。 図2がPSGIサーバの役割を図に表したものです。ApacheやnginxなどのWeb サーバからCGI、FastCGI、HTTPプロトコルを経由してクライアントからのリクエストがPSGIサーバに届きます。PSGIサーバはそれぞれの環境からPSGIのリクエスト情報を集め
ここ数日、Amon2を解読していたのですが、結局PSGI/Plackをちゃんと理解してないと話にならないことが分かったので、PSGI/Plackを一から勉強してみました。ということでその記録です。 PSGI/Plackについて PythonにおけるWSGI、RubyにおけるRack、それに相当するのがPerlにおけるPSGIです。このあたりは、前にまとめましたし、他のところでも語り尽くされているネタですので、ここでは省略いたします。 PlackはPSGIなWebアプリケーションを開発するための汎用的なツールキットです。PSGIサーバーのリファレンス実装も含まれています。PSGIサーバー部分は、StarmanやStarletなど、多くのサードパーティ実装があります。Plack自体がよく出来たライブラリ群なので、Amon2やKossyなど、Plackが提供する機能をベースとして、薄く機能拡張を
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は以下
Perl Hackers Hub 第24回PSGI/Plack実践入門―Starman、Starlet、Twiggy、Plack::Middleware、Server::Starter（1） 本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはWEB+DB PRESS Vol.50～55まで「大規模Webサービスの裏側」を連載し、本連載でも第11回以来の2度目の登場となるkazeburoさんこと長野雅広さんで、テーマはPSGI/Plackです。 なお本稿のサンプルコードは、本誌サポートサイトから入手できます。 幅広く使われるようになったPSGI/Plack 本連載でPSGI（Perl Web Server Gatewary Interface）/Plackについて取り上げるのは2回目です。1回目は2010年2月に発売されたWEB+DB PRESS Vol.55に
Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon のLTで発表したスライドRead less
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
livedoorBlogのPlack/Starlet化を背景として、この半年間ぐらいの間、PlackやStarletの高速化に取り組んできました。この発表はその中で学んだPSGI/Plackの基本仕様、PSGIサーバの構築の方法と最適化、PSGIサーバの選び方、またMonocerosについて紹介しました。 多くのWebアプリケーションではこの最適化の恩恵を受ける事はないかもしれません。しかし、アプリケーションが動作する基盤がどのように実装され、最適化のテクニックが施されているかを知る事により、アプリケーション層の最適化がより捗るのではないかと思います。 質問等があれば気軽に、コメントやtwitterでメッセージを下さいませ。 1日目のトークでは、tokuhiromのFuture Perlの話。新しい構文や正規表現やpfjのexobrainなど、が気になりました。 あと、前夜祭のLT-Tho
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
開発環境と本番環境で favicon を変える というのに感動したのでPlack middlewareでやってみました。 単に favicon.ico ないし favicon.png という名前にマッチしたらグレースケールにして返すというだけの代物ですが、enable_ifで簡単に導入できるのが楽かなと。 使い方は以下のとおり。P::M::Staticの前にenableしてください。 builder { enable_if { $ENV{PLACK_ENV} eq 'development' } 'DevFavicon'; enable 'Static', path => qr{/favicon\.(?:ico|png)$}, root => $path_to_assets; ...; }; https://github.com/gfx/Plack-Middleware-DevFavico
Starlet が HTTP/1.1 に対応しました。これによりでnginxのupstream keepaliveなどが捗ると思われます https://metacpan.org/release/Starlet https://github.com/kazuho/Starlet ながらくStarletはHTTP/1.0 + keepaliveなサーバでしたが、version 0.20にてHTTP/1.1に対応しました。具体的に対応したスペックは以下。 HTTP/1.1 keepalive Transfer-Encoding: chunked (Request & Response) Expect HTTP Pipelining StarmanやMonocerosとだいたい同じ動きをするようになっていると思われます。 なお、導入にあたっては、リバースプロキシ等と組み合わせた場合の動作パターン
YAPC::Asia Tokyo 2013 にて「PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方」というはなしをします。 トークの内容は 先日、MonocerosというPlack::Handler(サーバ)をリリースしました。MonocerosはStarmanやStarletと同じくPrefork型ですが、AnyEventを使い、C10Kのような多数のコネクションを捌くことができる特徴を持ち、非常に高いパフォーマンスを備えています。 このセッションではStarmanやStarlet、Twiggyといった各Plack::Handlerの内部構成の簡単な紹介、Monocerosを実装する上で学んだPlack::Handlerの構成や作成方法から、forkやUNIXプロセス、Linux TCPの話を交えて、高性能なWebアプリケーションサーバ
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の場合は
PSGIアプリなら簡単にherokuで動かせます。 Miyagawaさんのbuildpack(https://github.com/miyagawa/heroku-buildpack-perl)を 使います。使い方もREADMEに書いてあったけど、以下にも書きます。 アプリ側の準備 deployしたいアプリケーションのgitリポジトリ上で以下をやります。 cpanm --installdeps . で依存モジュールがちゃんと入るようにする(cpanfile使うのがオススメ) アプリ起動用のapp.psgiを配置する herokuにアカウントを作る https://www.heroku.com/ toolbeltを入れる https://toolbelt.heroku.com/ インストールが終わるとherokuコマンドが使えるようになります。 % heroku login と打ってコマンド
C10K対応Prefork型高速PSGI/Plackサーバの Monoceros をHTTP/1.1に対応させました。 https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros MonocerosではHTTPのKeepAliveに対応して、大量の接続を捌く事ができますが、リリース時点ではHTTP/1.0 KeepAliveにしか対応していませんでした。しかし、nginxのupsream などでは、keepaliveを有効にしてHTTPセッションを使い回したい場合にHTTP/1.1が求められます。 以前このあたりの事をしらべてblog書いています nginx-1.1.x で httpなupstreamにもkeepaliveができるようになったので検証してみた https://blog.nomads
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
packageごとのメモリ使用量とリクエストを処理する前後の増分を確認できるPlack::Middlewareを作りました。 時間が経つとぶくぶく太るプロセスがいるときに、犯人特定の助けになると思います。 https://github.com/hirose31/Plack-Middleware-MemoryUsage 要、B::TerseSizeB::Size2::Terse, Devel::Symdumpです。 新しめ(5.10以降？)のPerlでB::TerseSize (B::Size)がエラーになってインストールできないときは、 https://github.com/gfx/p5-B-Size-patched のを入れてください。 https://metacpan.org/module/B::Size2 を入れてください。 使い方は、 use Plack::Builder; bui
plack を使ってて「サーバのサブフォルダを間借りして動かしたい」って事がたまにあるんだけど、そんな場合 nginx の設定でリバースプロキシに渡すって事をやります。 location /foo { try_files $uri $uri.html $uri/index.html @proxy-foo; } location @proxy-foo { proxy_pass http://localhost:5000; proxy_set_header Host $http_host; } この場合、通常の Plack アプリケーションだと / がアプリケーションルートになっているので404になってしまう。よって app.psgi とは別に !perl use strict; use warnings; use Plack::Builder; use Plack::Util; builde
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く