wrkに無理矢理なpatchをあてて、unix domain socket経由でHTTPサーバをベンチマークできるようにしてみました。 kazeburo/wrk at unixdomain pullreqはしてない。 GazelleやRhebokといったアプリケーションサーバを作っていますが、TCP経由のベンチマークではEphemeral Portの枯渇やTIME WAITの上限にあたってしまい、ベンチマークがしづらいという問題があります。 そこでnginxをreverse proxyとして設置し、nginxとアプリケーションサーバ間をunix domain socketで繋いでベンチマークをとっていましたが、nginxがボトルネックになりやすく、直接アクセスしたいなと考えていたので、やってみました。 これを使ってRhebokとUnicornの “Hello World” ベンチマークを行

“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、

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は以下

うしろのばやしさんにラーメンと一緒に飲み込まれてしまった感がありますが、PSGI/Plackのパフォ厨としては、どうしても現状を報告しておきたい内容でありました。unicornに勝ちたい！！ 2日目の朝イチというコマでありましたが、大勢の方に見に来て頂いて驚きました。前半の内容を盛り込みすぎて時間が足りなくなってしまい、すみませんでした。アンケートで既にDockerを使っている方が凄く多かったので、インストールの部分とかは飛ばしてもよかったんじゃないかと思いましたが、Dockerを使う上で少しでも役に立てば幸いです。 ベストトーク賞 うずらさんのPHP発表は内容面白かったし、喋りはうまいし、スライドも作り込んであってさすがという感じでした。ベンチマークで自分がLTで紹介したオプションを使って頂いて嬉しかった。時代はPHP その他のトークではgugodの「One layer down bel

昨日のエントリで紹介した「Webアプリケーションの パフォーマンス向上のコツ 実践編」ですが、いくつかスライドを追加して、「完全版」として公開しました。 ISUCONだけに限らず、一般的なWebアプリケーション、SQLのチューニングの参考となる資料となっていると思いますので、見て頂けたら嬉しいです。 ＜追記＞ ISUCON4 オンライン予選の参加登録が開始されています！！！Webアプリケーションを書いている方もインフラを扱っているエンジニアも運用エンジニアも、ぜひチャレンジしてください！！私もでます！！ 参加はこちらから↓↓↓↓ ISUCON4 オンライン予選の参加登録を開始しました \n\n\nISUCONだけに限らず、一般的なWebアプリケーション、SQLのチューニングの参考となる資料となっていると思いますので、見て頂けたら嬉しいです。\n\n## ＜追記＞\n\nISUCON4 オン

最近、Vagrantのprovisionerを使ってパッケージの作成などをいくつか行っているのですが、その際にVMを落とし忘れ、ホストしてるマシンの余計なリソースを使ってしまっていることがあります。 なので、provisionerでサーバをdestroy/haltするやつを書いてみました。 rubygems: https://rubygems.org/gems/vagrant-destroy-provisioner github: https://github.com/kazeburo/vagrant-destroy-provisioner 勝手にshutdownしてイメージを破棄するデモ動画です。 インストールはvagrant pluginコマンドから行います。 $ vagrant plugin install vagrant-destroy-provisioner 使い方はこんな感じ

あるモジュールがPerlのコアモジュールに含まれているか、どのバージョンが含まれているかをたまに確認したくなりますが、その時に使うのが Modure::CoreList です。Modure::CoreListにはコマンドラインツールも用意されているのですが、tokuhiormが Web Interface版を作っていてとても便利でした。が、こちらは今404になってしまっているので、tokuhiromに確認の上、新しくサイトを動かしました。 http://corelist.rpee.be/ 画面はこんな感じ あるバージョンのperlにどのモジュールのどのバージョンが含まれているのかと、モジュールがどのPerlに含まれているのかのリストがでます。 もとのソースコードを参考にしつつ、Kossyとboostrap3で移植しました。移植するついでに、Proclet、Server::Starter、c

わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem

奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖

ここを書き直して転載 memcachedに関する記事は「第1回　memcachedの基本：memcachedを知り尽くす｜gihyo.jp … 技術評論社」など何回か書いていますが、最近のmemcachedでの起動オプションのおすすめをまとめてみようと思います。なおこの記事はMemcached Advent Calendarではありません。 まとめるとこんな感じです。 $ memcached -v -p 11211 -U 0 -u memcached -m 1024 \ -c 100000 -t 4 -C -B ascii ひとつずつ簡単に紹介します。 -v ログ出力 ログを verbose モードで起動します。エラーや警告が表示されます。弊社ではmemachedをdaemontools経由で起動し、ログを記録しています。 -v -vオプションは -vv、-vvv と v の数を増やす事で

それほど成果のある内容ではありませんが、strace芸の一つとしてみて頂ければ幸いです 主催のYappo++。発表者のみなさまありがとうございました~。 スライド表紙のダンボーは、ISUCON3の副賞でもらった。データホテルのロゴ入りロボダンボーです。ちゃんと動きました！ \n\nそれほど成果のある内容ではありませんが、[strace芸](http://b.hatena.ne.jp/y_uuki/20131120#bookmark-170026522)の一つとしてみて頂ければ幸いです\n\n主催のYappo++。発表者のみなさまありがとうございました~。\n\nスライド表紙のダンボーは、ISUCON3の副賞でもらった。データホテルのロゴ入り[ロボダンボー](http://www.vstone.co.jp/products/danboard/)です。ちゃんと動きました！\n\n \n\n \

Reverse Proxyの後ろでApplication Serverを動かす際に、REMOTE_HOSTを本当のアクセス元に書き換えてくれる仕組みはいくつかありますが^1、Plackでは壇上氏の Plack::Middleware::ReverseProxy がそれにあたります。 ^1 例えば mod_extract_forwarded http://www.openinfo.co.uk/apache/ PM::ReverseProxy のSYNOPSISでもそうなってますが、このような仕組みを使う場合、REMOTE_HOSTを指定するのが安全です。 builder { enable_if { $_[0]->{REMOTE\_ADDR} eq '127.0.0.1' } "Plack::Middleware::ReverseProxy"; $app; }; 拙作の Plack::Buil

以前「StarmanやStarletでmod_statusっぽい情報を得る簡易版Plack::Middleware::ServerStatus」で書いていたPlack::Middleware::ServerStatus::LIteをCPANにリリースしました。 http://search.cpan.org/dist/Plack-Middleware-ServerStatus-LIte/ 前回と大きく実装が異なっている箇所があります。１つはプロセスの状態を保持するためにParallel::Scoreboardを使うようになり、$0(PROGRAM_NAME)の書き換えを行わないようになったこと。２つ目はロケタッチを開発しているhideokiさんからの指摘で、アプリケーションが例外を起こしたときにステータスが戻らないという問題への対応をTry::Tinyを使って行っていることが大きな変更点です

PSGI/Plackにおいて、非同期にレスポンスが返せるstreamingという仕様/機能が追加されました。 PSGI/Plack streaming is now complete これを使うと、streamingをサポートしたサーバから非同期/nonblockingにhttpやGearmanを利用して外部へ問い合わせを行い、その結果をレスポンスしたりできます。 また、これがPlackで既に実装済みなので、非常に短いコードでサーバの実装ができちゃいます。 すばらしいですね。 すでにmiyagawaさんが、この機能を利用した非同期Web Framework「Tatsumaki」を書かれています。 イベントを扱う部分が隠蔽されているので、これを使うとさらに簡単に実装できます。 すばらしすぐる。 ここでは、簡単に外部へAnyEvent::HTTPを用いて、HTTPリクエストを行うサンプルを書い

トークの内容はひとつ前のエントリにて紹介していますが、なんとBest Talk Awards 第3位をいただきました！ありがとうございます！ 牧さん、941さん、JPAの皆様、ボランティアの皆様、参加した全てのPerl Mongersの皆様と、妻と子供たちに感謝です。 ベストトーク賞第3位の賞品は「国内の技術カンファレンスの参加チケット費用」ということでPerlに限らず、様々なカンファレンスに参加できるようです。せっかくなのでPerl以外で、LT発表ができるところに行ってみたいのでオススメがあれば @kazeburo 宛にメンション頂けると嬉しいです！ YAPC::Asia 2013 2日目は、藤原さんの「社内ISUCONの作り方」、弊社の話ですが、牧さんの「本当にあったレガシーな話」、myfinderさんの「フルテストも50msで終わらせたい」あたりがよかった。ISUCONの課題はもっと

livedoorBlogのPlack/Starlet化を背景として、この半年間ぐらいの間、PlackやStarletの高速化に取り組んできました。この発表はその中で学んだPSGI/Plackの基本仕様、PSGIサーバの構築の方法と最適化、PSGIサーバの選び方、またMonocerosについて紹介しました。 多くのWebアプリケーションではこの最適化の恩恵を受ける事はないかもしれません。しかし、アプリケーションが動作する基盤がどのように実装され、最適化のテクニックが施されているかを知る事により、アプリケーション層の最適化がより捗るのではないかと思います。 質問等があれば気軽に、コメントやtwitterでメッセージを下さいませ。 1日目のトークでは、tokuhiromのFuture Perlの話。新しい構文や正規表現やpfjのexobrainなど、が気になりました。 あと、前夜祭のLT-Tho

ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan　 334944 req/s nginx　111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L

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の場合は