はい、というわけで自分のトークです: 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記:スライドに「ログにマーカーをつける」というのは、(コード読んでないけど)多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました: 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました! (
How to build a High Performance PSGI/Plack Server AI-enhanced description The document provides a comprehensive guide on building a high-performance PSGI/Plack server, focusing on optimizations for handling a large volume of requests, especially for the Livedoor Blog service. It discusses various layers involved in improving performance, including hardware, networking, caching, and server architec
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の場合は
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
概要 Plack::App::PHPCGIは、PlackでPHPを実行するモジュールです。 php-cgiを利用して実行しています。 Plack::Component 「Plack::App::*」モジュールをつくるためのベースクラス。 prepare_appとcallをオーバーライドする。 callはto_appで呼び出されるようになっている。 Plack::App::PHPCGIでは以下のように実装している(コメント追加)。 sub prepare_app { my $self = shift; # PHPスクリプトのパス my $script = $self->script or croak "'script' is not set"; $script = File::Spec->rel2abs($script); # php-cgiコマンドの設定、設定されていない場合はパスを自動検
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの?」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること! まずこのお話の前提:mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない(←ここポイント)。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう? まずアプリケーションを組む側が「やっちまったなぁ?」な件:P
Plack::Middlewareでリクエスト終了後になにがしかのか処理をしたい場合 sub call { my ($self, $env) = @_; my $t0 = [gettimeofday]; my $res = $self->app->($env); my $ela = Time::HiRes::tv_interval($t0); }; と書きそうになりますが、これだと $res が CodeRef になるStreaming形式のレスポンスでは正しく処理ができません。 Streaming形式のレスポンスは多くないだろうとか思ってると、Catalystがstreaming形式のレスポンスを返したりするので注意が必要です そこで Plack::Util::response_cb を使うと楽です sub call { my ($self, $env) = @_; my $t0 = [
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
« Perl Advent Calendar Japan 2012 は明後日からです、みんな参加して寿司を食べよう! | Main | PLACK_ENV my way » plackp -R したプロセスを終了する時には SIGHUP ではなく SIGTERM を送るべき、もしくは daemontools で plackup -R するのは筋が悪い話 スレタイ速報だから内容は無いけど、 plackup -R や plackup -r した場合には Plack::Loader::Restarter で fork して親プロセスでファイルシステム監視をして、変更があったら子プロセスで立ち上げた plack を再起動するみたいな事やってるんだけど、この親プロセスに対して SIGTERM を送ると子プロセスの方にも TERM 送ってくれるから良いんだけど、うっかり SIGHUP を送っちゃうと親
Plack上でPHP(php-cgi)を動かすモジュール、Plack::App::PHPCGIと任意のCGIも動かせるPlack::App::CGIBinを使ってApacheナシでNagiosをインストールする方法 まず、php-cgiをインストールする。CentOSの場合、php(53)?-cliというパッケージがあるのでそれを使います $ sudo yum install php53-cli #centos5。centos6だとphp-cli 次にnagiosを動かすユーザを作成します $ sudo /usr/sbin/adduser nagios nagios本体とpluginをダウンロードしていれます。その際にApacheの設定はインストールしません $ wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagio
ネタではありません。メリーお正月 Plack上でみんな大好きPHPをphp-cgiを使って動かすモジュールをリリースしました https://metacpan.org/release/Plack-App-PHPCGI https://github.com/kazeburo/Plack-App-PHPCGI PlackにはPlack::App::WrapCGIというモジュールもあって、これを使うと任意の言語で作られたCGIをPlack上で動かすことができます。 ただ、PHPの場合にはshebangがなかったり、実行bitも付いていないことが多いので、WrapCGIでは対応することができません。そこで、今回のモジュールを作りました。中身はWrapCGIのコピペと環境変数の追加だけでできました どうしてこれが作りたかったかというと、管理ツールなどでPHPを動かす為だけにApacheを起動したくな
割と良く見る間違いです builder { enable "ServerStatus::Lite", path => '/server-status', allow => [ '127.0.0.1', '192.168.9.0/24'], scoreboard => ..; enable 'ReverseProxy'; $app; }; これは間違いです。リバースプロキシ配下にてアプリケーションサーバを起動すると、/server-statusに対して全世界からアクセス可能になります Plack::Middleware::ReverseProxyがX-Forwarded-Forヘッダをみて、REMOTE_ADDRを書き換える前、上の図の状態でPlack::Middleware::ServerStatus::Liteが実行されてしまうので、/server-statusへのアクセスが許可されてし
任意のダミー画像が簡単に動的生成できると、Webサイトのモック作成作業が捗ったりしますね。 というわけで、某チャンネルで dot gif の Plack::Middleware ないねーという話が出ていたのもありつつ、そういえばこれ欲しいと思ってたので書いてみました。 でも、既出ですね、、 http://placehold.it/ http://dummyimage.com/ まあでも、開発環境だとこういうの気軽に使えないとかありますよね。 Plack::App::DummyBox Plack::App::DummyBox はこんな感じで使えます。 # app.psgi use Plack::App::DummyBox; my $dummy_box_app = Plack::App::DummyBox->new->to_app; # then map it use Plack::Build
Plack Handbookは、CGI以降の最近のPerlを使ったウェブサイトを作る上でベースとなるPSGIという仕様の実装であるPlackのまとまった(電子)書籍です。待ちに待ってましたという感じだったんですが、でやっと入手して読んだ感想とかをメモります。 といいつつPlackって何?詳しく教えて? 上述した通りなものがPlackなのですが、FTPでアップしてふんふんふん、という事をしている人にとって、いまいちピンとこないのがPlackだと思います。昔は、FTPを使って.cgiファイルみたいなのをアップしてちょっとした動的な動きをするページを作るには、PerlだとCGI.pmというCPANモジュールに準拠しながらいろいろと作っていたのです。ただ、ApacheのCGIという技術の上だと、何分毎回プログラムファイルの読み込みをとかを行うので遅かったりしたのです。そこで、FastCGIとかmo
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
PSGI で動作する Perl の Web アプリをデプロイする環境をどのように作ろうかと思って試してみたので、その手順をまとめてみます。 記事を書きかけて放置してしまっていたので、diff が古かったりするのはご愛敬で。。 構成の概要 今回構築しようと思う構成は次の通りです。 PSGI を用いた簡単な Web アプリ アプリを動作させる Perl とそのモジュール群は perlbrew + Carton で管理 複数のシステムを同一サーバで動かす可能性もあるため分離しておきたい Carton 使ってみたい アプリケーションサーバには Server::Starter + Starman を利用 Hotdeploy できるようにするため Server::Starter のプロセスは Supervisord で管理 supervisord の導入 スーパーサーバーSupervisorの導入手順
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 するモジュール群のピックアップはたやすい。なにせ明示されているから。しかし、暗黙に遅延ロードされてるモジュールやライブラリは調べてみると多く見つか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く