Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
How we've made Phusion Passenger 5 ("Raptor") up to 4x faster than Unicorn, up to 2x faster than Puma, Torquebox
Phusion Passenger 5 (codename "Raptor") is a web server that's up to 4x faster than Unicorn, and up to 2x faster than Puma and Torquebox. Learn more about Phusion Passenger 5 here. This blog post is part of a series of posts on how we've implemented Phusion Passenger 5. How we’ve made Phusion Passenger 5 (“Raptor”) up to 4x faster than Unicorn, up to 2x faster than Puma, Torquebox The following pe
UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転 改
最近は仕事でSinatraアプリを書いたりしているので、Sinatraアプリを動かすためにはどのHTTPサーバを使うのがベストなのかが気になっている。（先に結論を書いておくけれど、どれがベスト、という唯一の選択肢は今のところありません。適材適所です。） SinatraはRackの上に構築されているので、Rackに対応したHTTPサーバーを使って動かす事になるのだが、この数がやたらと多く、どれを使えばいいのか迷う。代表的なものを挙げただけでも、WebRick, Mongrel, Thin, Unicorn, Passenger(Apacheとかに組み込んで使うやつ), FastCGI, (普通の)CGI、これぐらいは選択肢がある（いくつかHTTPサーバじゃない物も混ざっているが、Rackが対応してるという点は共通している）。 WebRickはそもそもパフォーマンスに重点を置いていないし、Mo
なぜ Forkwell はリリース初日にサーバダウンを繰り返したのか - 表参道フォークウヱル別館
こんにちは。Forkwell の中の人、大岡（おおか）です。 本日は、お恥ずかしながら Forkwell リリース初日の失態について、詳細をお話しようと思います。 当初からのユーザーの方はご存知かもしれませんが、先週4月3日（火）に Forkwell がリリースされた際、殺到するアクセスの負荷に耐え切れず、深夜までサーバダウンを繰り返しました。なぜそんなことになったのか。 端的に言えば、ロクに負荷テストを行ってなかったからというのが真相という間抜けなオチなのですが。 初めての慣れないディレクター業務で連日サービスリリースのことで頭が一杯になっていた大岡は、負荷テストのことがすっぽり頭から抜けていました。 私も過去、Apache Bench や JMeter で負荷テストを行った経験はもちろん何度もあったのですが、今回はウソのようにきれいさっぱり忘れてしまっていました。 ディレクター業務に加
nginx + unicorn + Rails on Mac - Aerialarts
とりあえず動かしてみたのでメモ。 unicornを動かす まずはgemをインストール。 $ gem install unicorn unicornの処理を設定する $ cd <RAILS_ROOT> $ vi config/unicorn.rb <RAILS_ROOT>/config/unicorn.rbはこんな感じ（nginx + unicorn を試してみたからほぼそのまま拝借）： # ワーカーの数 worker_processes 2 # ソケット経由で通信する listen File.expand_path('tmp/sockets/unicorn.sock', ENV['RAILS_ROOT']) # ログ stderr_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT']) stdout_path File.exp
nginx + unicornでrails3.1が動作する環境を作る - A Peak Never Ending !
方針 手元(Ubuntu)で開発して、サーバ(Ubuntu)にデプロイ出来るrails 3.1動作環境を作るのが目標 プロジェクト毎にユーザを作成する (各ライブラリをプロジェクト毎にbundlerで管理、デプロイをするため) 同様の理由でrbenvを使って各ユーザ毎にrubyのバージョンを管理 構成 静的なファイルへのリクエストは直接nginxで返す構成をとります(railsのpublic配下のディレクトリにあるファイル、適宜nginxのconfigに設定を追加する必要あり)。またrails3.1からAsset Pipelineが導入されたため/assets/〜に関するリクエストに関してもnginxで直接返すようにします。加えてnginx <=> unicorn間の接続にはUnix Domain Socketを用います。イメージを図にすると下記のようになります。 unicorn gith
社内勉強会でUnicornについて発表したけどあまりの準備不足に全俺が泣いたので少しずつまとめていく〜その３ - こしごぇ
Unicornの設計(DESIGNより) 哲学を学び、設計も学ぶ。取り急ぎ、英文を和訳する程度。 Unicornは伝統的なUnixのpreforkウェブサーバ スレッドを使わないことで、アプリケーションのデバッグと修正を簡単にできる アプリケーションの調子が悪いとき、KILLシグナルで該当ワーカーだけを片付けることができる RagelとCによるHTTPパーサはMongrelから持ってきている この部分のみが非Rubyで、今後ここ以外に非Rubyのコンポーネントを増やす予定はない HTTPの処理 すべてのHTTPリクエストヘッダを処理する Rackアプリケーションを実行する HTTPレスポンスをクライアントに返す keepaliveやパイプライニングはサポートしない 設定はRubyのeval()で行われる RubyはYAMLより曖昧ではなく、フック処理をインライン定義できる 一つのマスタプロ
UnicornとかRainbows!とかの話 : As Sloth As Possible
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった？ なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
RailsとUnicornでサブディレクトリのデプロイについて - 忘れたときの備忘録
unicorn_railsのオプションでアプリのURLにprefixをつけることができる。 unicorn_rails --path /foo -D -e productionこのまま実行するとルートのエラーが起きる。 アプリケーション側でprefixを含んだパスを認識できていないためである。 ENV['RAILS_RELATIVE_URL_ROOT']がアプリのルートパスになるので 起動時に対応させる必要があります。 設定ファイルはconfig.ruで行います。 require ::File.expand_path('../config/environment', __FILE__) # run Foo::Application if ENV['RAILS_RELATIVE_URL_ROOT'] map ENV['RAILS_RELATIVE_URL_ROOT'] do run Foo:
さくらVPS Capistrano編 - プログラミングノート
基本設定、開発環境設定に引き続き、今回はCapistranoを導入して自動デプロイできるように設定。unicorn+nginx周りの設定も変更して快適にデプロイできるようになりました。 リモートリポジトリの作成 リモートサーバーにリポジトリを作成します。 今回は全て同じサーバーでやるので、自分のホームディレクトリ直下に作りました。 $ mkdir -p /home/ntaku/git/sample $ cd ~/git/sample $ git --bare init 後からcapistranoでアプリを配置するためのディレクトリも作成しておきます。 # mkdir /var/www プロジェクト作成 ここからはローカルで。 新規プロジェクトを作成して、テスト用のコントローラーを追加します。 $ rails new sample -d mysql $ cd sample $ rails g
nginx + Unicorn を試してみた - milk1000cc
追記(2012/02/21 09:39): nginx 設定ファイルの例に、X-Frame-Options, X-Content-Type-Options に関する設定を加筆しました。 追記(2011/10/17 19:18): Rails 3.1 用に、nginx 設定ファイルの例を加筆・修正しました。 追記(2010/09/25 12:07): 現在はさくらの VPS を使用しています。 追記(2010/08/16 11:18): nginx 設定ファイルの例に root 文を書き忘れていたので追加しました。 話題の Unicorn を試してみました。 Unicorn については、以下の記事が詳しいです。 次世代Ruby on RailsサーバーUnicorn（汎用のRackアプリケーションサーバ）を使ってみた | TechRacho 現在 PONPON は nginx + Unico
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
CentOS5.6 で MySQL+Nginx+Unicorn な Rails アプリを動かす - happy lie, happy life
完全に自分用の備忘録。VirtualBox にインストールした CentOS5.6 に表題の環境を構築してサーバを動かすまで。 サーバのメモリは512Mでパーティションは40Gと、（記事執筆時では）一般的な低価格帯 VPS を意識したスペックに調整してあります。 また、すべての作業は su で root ユーザに昇格した上で行う前提になっているので sudo を使う場合適宜置き換えて下さい。 必要なパッケージのインストール 今後の作業に使うパッケージを yum からインストールしておきます。 yum install gcc gcc-c++ openssl* readline* ncurses* zlib* libxml* libjpeg* libpng* libxslt* libtool* MySQL のインストール これも yum からインストールします。 yum install mys
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://2ndscale.com/rtomayko/2009/unicorn-is-unix
「Server::Starterに対応するとはどういうことか」の補足 : sonots:blog
湘西堂陨人力资源有限公司