ISUCONでUnicornをRaptor(Phusion Passenger 5)化したときのパフォーマンス : sonots:blog
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
アプリサーバー対決 パート1：主なRubyアプリケーションサーバーの機能比較 - Engine Yard Blog
本記事は英語版ブログで公開された記事の翻訳版です。 2013年7月に、米国テキサス州オースティンで開催されたLonestar Ruby Conferenceで、Rubyによるアプリケーションサーバーについてお話させていただきました。その中でいくつかのRubyアプリケーションサーバーのパフォーマンスや、さまざまな状況における挙動の違いを比較しました。この記事では、講演準備として行ったリサーチの中で分かったことをかいつまんでご紹介します。 実際のカンファレンスの録画をご覧になりたい方は、Confreaksで公開されていますのでそちらをご参照ください。テストに使用した簡単な自作アプリケーションはGitHubに、講演スライドはSlideshareにそれぞれ公開しています。 このリサーチは、Passenger 4のパフォーマンス評価以外すべて2013年7月に行ったものなので、情報が多少古くなっている
Unicorn!
EngineeringUnicorn!We've been running Unicorn for more than a month. Time to talk about it. What is it? Unicorn is an HTTP server for Ruby, similar to Mongrel or Thin. It… We’ve been running Unicorn for more than a month. Time to talk about it. What is it? Unicorn is an HTTP server for Ruby, similar to Mongrel or Thin. It uses Mongrel’s Ragel HTTP parser but has a dramatically different architectu
Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel
Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel RailsのアプリをPound、Varnish、Nginx、Unicorn、Mongrelを使用して動かした際の速度ベンチマーク。以下の構成での同一Railsアプリをhttperfでベンチマークした結果をまとめます。 Pound -> Varnish -> Nginx -> Unicorn * 2 Varnish -> Nginx -> Unicorn * 2 Nginx -> Unicorn * 2 Mongrel (Rails.env == 'development') node.js (Express + Socket.IO) 全体の構成Poundを80番ポートを公開し、Varnishを81番ポート、nginxを8080番ポート、Unicornの2プロセスをsocke
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kzk/unicorn-worker-killer: Automatically restart Unicorn workers based on 1) max number of requests and 2) max memory
