h2o の fastcgi サポートで Plack::Handler::FCGI を動かす - tokuhirom's blog
h2o の fastcgi サポートで Plack::Handler::FCGI を動かす h2o で PHP を FCGI で動かすという話題が最近見かけますが､もちろん h2o+FCGI+Perl も快適に動作します｡ 具体的には以下のように書けばよろしい｡ listen: 9090 hosts: default: paths: /: file.dir: /path/to/htdocs/ fastcgi.spawn: "exec /opt/perl-5.18/bin/plackup -s FCGI --nproc 10 /path/to/app/" 簡単すぎて､とくに解説することがないです｡ h2o+FCGI で運用した場合のメリットとして､Starlet 等の application server を立ち上げる場合と異なり､application server のプロセスを daem
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
The Tale of Plack - YAPC::Asia Tokyo 2010
http://yapcasia.org/2010/talks/63D5EA98-BC8C-11DF-8791-B9FC0F276C45 皆さん、お疲れさまです。ちょっと夏は暑いんで脱いじゃいましたけれど、さっきフェライト会議室の前に居たら、が酒臭くて、僕もついつい飲んでしまいまして。（笑）２本しか飲んでいないんで。（笑） 今日は何の話をしようかなと思って、今回ゲストという形で呼んでいただいて、スタッフの皆様、特に牧さん、それから櫛井さんはじめ、あとボランティアの皆さんに、最初に感謝の言葉を言いたいと思います。ありがとうございました。（拍手） ちょっとだけ自己紹介をしますと、今サンフランシスコに住んでいまして、今週の水曜日に帰ってきまして、来週また帰っちゃうんですけれども、もう４年前に引っ越して、ずっと住んでいるんですが、まだビザで働いているんですけれど、今グリーンカードを取ろうとしていて、
Perl 初心者がウェブアプリケーションを書く時に気をつけるべきこと - tokuhirom's blog
Perl 初心者がウェブアプリケーションを書く時に気をつけるべきこと $c->req->param('id') みたいなメソッドは使ってはいけない。これは歴史的経緯から残っているものなので、基本的に使わない方がいい。 $c->req->parameters->{id} をかわりに使ってください。 Perl の世界には List コンテキストというものがあって、これがウェブアプリケーションを開発するときには鬼門となります。 +{ id => $c->req->param('id') } のようなコードは、param メソッドはリストコンテキストではすべての id を返すので、 ?id=3&id=hasegawa&id=yosuke というようなクエリが来ている場合、 +{ id => 3, hasegawa => 'yosuke' } のようなデータ構造が作成される。これは明らかに意図してい
Plackで実装したメールサーバ"Haineko"のその後/Shibuya.pl #1
Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon のLTで発表したスライド
Graduate from .psgi
最近のクライアントアプリケーションの流れ bin/riji #!/usr/bin/perl use strict; use warnings; use Riji::CLI; Riji::CLI->run(@ARGV); scriptにはあまり書かないでテスタブルにする 例(OrePAN2::Server) http://www.songmu.jp/riji/entry/2013-10-30-orepan2-inject-psgi.html use OrePAN2::Injector; use OrePAN2::Indexer; use Plack::Request; use File::Copy qw/move/; use File::Temp qw/tempdir/; use File::Spec; sub { my $env = shift; my $req = Plack::Requ
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
WSGI/Rack/PSGIの登場の背景 - $ cat /var/log/shin
何番煎じ変わりませんが、WSGI/Rack/PSGIに関して、何でこれらが必要とされるようになったのか、歴史的経緯を踏まえて色々調べたので、記録しておきます。ただし、特に歴史的な話に関しては、ネットで自分が納得できるまで探りはしましたが、正確性を欠くかもしれません*1。間違っていたらご指摘下さい。 実行環境の多様化とWAFの乱立 結論としては、この見出しがWSGI/Rack/PSGIが生まれることとなった動機といえます。 実行環境の多様化 私が小学生ぐらいの頃、20世紀終盤でしょうか、通信速度も今に比べ格段に遅く、多分スケーラビリティなんて考えも浸透していなかった頃、WebアプリといえばCGIでPerlな時代がありました*2。そんな頃の実行環境はレガシーなApacheとmod_cgiでした。 しかし、時代と共に、数多くのリクエストを捌くことが要求されるようになると、CGIでリクエスト時に毎
Amon2 5.01 was released!!! - tokuhirom's blog
Amon2 5.01 was released!!! Amon2 5.01 was released on CPAN. Core features are: Default jQuery version is now 2.0 Default template engine syntax is Kolon. Every flavors are CPAN uploding ready. Flavors does not create app.psgi. Create script/${app}-server instead. Plan for 6.00 Next step: We are rewriting Router::Simple for better performance. Enjoy! Published: 2013-10-28(Mon) 12:56
Plack::Request::WithEncodingがなぜ便利なのか | おそらくはそれさえも平凡な日々
Plack::Request::WithEncoding というモジュールをリリースしました 上記の記事にも書いているのですが、Plack::Request::WithEncodigが便利なのは、単に車輪の再発明がされまくっているのが無駄感あるってのもあるんですけど、 個人的には$env->{'plack.request.withencoding.*'}に共通の格納位置を獲得したってのが大きいと思ってます。 例えば、リクエストの文字コード判別ってのは結構だるいのですが、アプリケーションの前段のPlack::Middlewareで、リクエストのエンコーディングの判別をして $env->{'plack.request.withencoding.encoding'}に格納しておくみたいなことをすることにより、よしなに文字列をdecodeしたりすることが出来るようになります。 まーそんなことを考え
Plack::Request::WithEncoding というモジュールをリリースしました - その手の平は尻もつかめるさ
Plack::Request::WithEncoding というモジュールをリリースしました． https://metacpan.org/module/Plack::Request::WithEncoding https://github.com/moznion/Plack-Request-WithEncoding これは何 このモジュールは Plack::Request のサブクラスで， Request Parameter に対して decode 処理を行ってくれる便利なやつです． 大体の動作としては POD，特に SYNOPSIS に書いてある通りです． 経緯 この手の decode 処理は WAF を作る時なんかに職人が心を込めて丁寧に記述すると思うんですが， 「その度にいちいち再発明とかコピペするのはだるいよね～」みたいな話を YAPC の時に HUB で @tokuhirom さ
YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
PerlでWebAppの開発に必要なN個のこと - Islands in the byte stream (legacy)
あるプログラミング言語で実際にWebAppを開発できるようになるまで、何が必要だろうか。言語仕様の習得は終えているとしよう。おそらく、最低限以下のような知識が必要だと思われる。とりあえずPerlについて知っていることを書いた。 パッケージマネージャ まずライブラリの管理。モジュールをインストールし、可能であればバージョンを固定し、適切にロードする機能が必要だ。Perlの場合は cpanm というCPANクライアントでライブラリをインストールする。バージョンの固定とライブラリパスの設定は carton で行う。 https://github.com/miyagawa/cpanminus https://github.com/miyagawa/carton アプリケーションサーバ Webサーバへのインターフェイスとしては、PSGIという仕様がある。PSGIに準拠したツールキットとしてPlack
Released Plack::Middleware::DevFavicon - Islands in the byte stream (legacy)
開発環境と本番環境で 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
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
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
Webアプリケーションのインタフェース(WSGI, Rack, JSGI, PSGI)
WebアプリケーションのインタフェースxSGI(WSGI, Rack, JSGI, PSGI)のメモ。 Webアプリケーションのインタフェースといっても、いろいろな切り口があるとは思いますが、アプリケーションとサーバー(実行環境)間のインタフェース。PythonのWSGIと、その仲間(Ruby版, Javascript版, Perl版)のこと。シンプルなCGI/Fast CGI/SCGIとも異なるし、古風なxSP系(PHP/ASP/JSP)とも違う感じ。（ここのインタフェースは、それにあわせることで、Webアプリケーションを作る人はいろんなところで動かせる、Webアプリケーション実行環境を作る人はいろいろな人に使ってもらえる、と言うことになります。例えば、WSGIのpythonアプリは、自前のApacheでもクラウドのGoogle App Engineでも、動かせる、みたいな。さらに、中間
PSGI アプリを supervisord + Server::Starter で動作させる - Hatak::Techlog
PSGI で動作する Perl の Web アプリをデプロイする環境をどのように作ろうかと思って試してみたので、その手順をまとめてみます。 記事を書きかけて放置してしまっていたので、diff が古かったりするのはご愛敬で。。 構成の概要 今回構築しようと思う構成は次の通りです。 PSGI を用いた簡単な Web アプリ アプリを動作させる Perl とそのモジュール群は perlbrew + Carton で管理 複数のシステムを同一サーバで動かす可能性もあるため分離しておきたい Carton 使ってみたい アプリケーションサーバには Server::Starter + Starman を利用 Hotdeploy できるようにするため Server::Starter のプロセスは Supervisord で管理 supervisord の導入 スーパーサーバーSupervisorの導入手順
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dl.dropboxusercontent.com/u/224433/plackcon/index.html
bayashi.net
