Rails3アプリをnginx+unicornで動かしたら速すぎた - ぱろっと・すたじお
いやぁ・・・Rails3はいいですね(｀･ω･´) ｂ Rails2とはなんだったのか・・・というレベルの完成度で、 なんとなく納得しないままRails2を使っていた私も、 Rails3になってからはバリバリに使いまくりです*1 そんなRailsを動かすAppサーバとして、 以前から定番になっていたのがpassengerでして、 私もApacheやnginxと組み合わせて使ってました*2 ただ、最近よく耳にするのがnginxにunicornを組み合わせた構成です http://unicorn.bogomips.org/ 前々から気になっていたものの、なかなか手をつけられなかったのですが、 仕事でもプライベートでもちょうどRails3アプリをリリースするタイミングだったので、 nginx+unicornの環境を試してみました なお、非常に細かな解説がある良記事がありますので、 ぜひそちらを先
nginxとUnicornでRackアプリを動かす : As Sloth As Possible
どうやらUnicornというのが良いらしいという噂を聞きつけたので、どんなもんじゃろと試してみることにした。 Route 477 - 大規模Railsサイトのための新しいHTTPサーバ、Unicorn Unicornてのは何者なのかと言うと、Rack及びRailsに対応したRubyのWebアプリ用のHTTPサーバ。詳しくは上の記事を読んで下さい。githubでも使ってるそうだ。あと、名前が格好良い（あんまり関係ない）。 まずはunicornの設定 と言っても、gem install unicornしてconfig.ruがあるディレクトリでunicornコマンドを叩けば、thinとかと同じようにサーバが起動する。rackup互換のオプションも付いてるので特に悩むこともないと思う。あとは普通にApacheとかでプロキシの設定してやるなりなんなりすればすぐ使える。 それだけだと大して面白くないの
Rack アプリケーション向けの HTTP サーバ Unicorn の基本操作
Table of Contents Open Table of Contents Unicorn とは？ Unicorn のインストールと事前準備 Unicorn の設定ファイルを用意する Unicorn サーバを起動する nginx と Unicorn を連携する Unicorn を停止する Unicorn の設定の再読込 サービスの提供を止めずにプログラムの再読込 Unicorn とは？ Rails、Rack アプリケーションを動作させるコンテナとしては、Passenger、Thin、Mongrel などの選択肢がある。 それ以外にも Unicorn という Rack アプリケーション向けの HTTP サーバがあり、今回試しに使ってみたのでそのメモ。 Unicorn: Rack HTTP server for fast clients and Unix 設計方針に特徴的な部分があり、以
UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転 改
最近は仕事でSinatraアプリを書いたりしているので、Sinatraアプリを動かすためにはどのHTTPサーバを使うのがベストなのかが気になっている。（先に結論を書いておくけれど、どれがベスト、という唯一の選択肢は今のところありません。適材適所です。） SinatraはRackの上に構築されているので、Rackに対応したHTTPサーバーを使って動かす事になるのだが、この数がやたらと多く、どれを使えばいいのか迷う。代表的なものを挙げただけでも、WebRick, Mongrel, Thin, Unicorn, Passenger(Apacheとかに組み込んで使うやつ), FastCGI, (普通の)CGI、これぐらいは選択肢がある（いくつかHTTPサーバじゃない物も混ざっているが、Rackが対応してるという点は共通している）。 WebRickはそもそもパフォーマンスに重点を置いていないし、Mo
Unicornを同期的に再起動する - 昼メシ物語
Unicornの再起動はシグナル（USR2等）を発行することで非同期的に行われるので、成功したのか失敗したのかがわかりづらい。 例えばCapistrano等でアプリケーションをデプロイしたあと、Unicornの再起動を行い、その再起動が成功か失敗かを判断したいことがある。 というわけで、 Unicorn を 同期的に restart するスクリプトを書いた。 使い方と仕組み 上記スクリプトを unicorn_restart.rb みたいな名前で保存し、以下のように Unicorn の PID ファイルを与えて実行します。 $ unicorn_restart.rb /tmp/unicorn.pidこれは以下のように動作します。 unicorn の master プロセスに USR2 シグナルを送る unicorn.pid.oldbin を監視し、再起動が終わるのを待つ 再起動が終わったら、
社内勉強会でUnicornについて発表したけどあまりの準備不足に全俺が泣いたので少しずつまとめていく〜その２ - こしごぇ
Unicornの哲学(PHILOSOPHYより) Unicornの詳細に降りていく前に、どのような哲学でもって設計・実装されているのか把握しておきたい。 Unixの哲学 「一つのことを行い、それをうまくやる。」 複雑さの排除 低速なクライアントに対応する代わりに、Unicornはバッファリング可能なリバースプロクシを信頼して代替させる。 UnicornはブロッキングI/Oと旧来のpreforkモデルを採用している。この処理モデルはモダンな方法(スレッドモデル、イベントとノンブロッキングI/O)へのアンチテーゼ。 Unicornでは、ワーカープロセスの競合を考えずに済む様に設計している。 低速なクライアントについて 「低速なクライアント」と呼ぶのは、データセンタ(ローカルネットワーク)の外側にいるクライアント(物理法則的な問題)。 HTTP/1.1の永続コネクションによって遅延を減らすことが
unicornのタイムアウト時にもRailsのログをちゃんと出力させる - 昼メシ物語
unicornはconfで timeout 20 とかやっとくと、20秒以上かかったらそのworkerが殺される。それはいい。問題はその殺され方にあって、タイムアウトしたunicorn workerはmasterにKILLシグナルで強制的に殺される。KILLで殺されてしまうと、worker側でtrapして安全に終了処理をすることができない。 一番困るのは、Railsのloggerは（production環境のデフォルトだと）リクエストが終了するまでバッファリングしているので、リクエストの途中でKILLされてしまうとloggerがflushされない。つまり、unicornのタイムアウト時には、リクエストのログは一切production.logには出力されない。異常時のログが出ないとか、まじで困ると思うんだけど、みんなどうしてんだろ。 これに対処するためにはunicornのコードに手を入れるの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
