amakanをUnicornからPumaに移行した - ✘╹◡╹✘
移行したぞ、というだけで特に技術的な知見の無い記事です。 移行の背景 https://amakan.net/ という、レビューの無いシンプルな読書管理サービスを2016年7月から運営している。 5ヶ月ほど運用している中で、利用してくれている人達に色々な意見をもらうことができて、これに対応して年末に時間を取って大きく改善しようとしている。しかし「年末に時間を取ってやろうとしていて...」という発言は明らかに危険信号で、高確率で「結局やれなかったよHAHAHA」ということになるのが目に見えている。そこで、年末に向けて小さな改善を徐々に積み重ねていくことで、モチベーションを高めつつ、新たに変更を加えることへの心理的障壁を無くそうと目論んでいる。今回はその一環として、amakanを動かすWebサーバをUnicornからPumaに変更することで、改善を図ることにした。 amakanの事情 amaka
RailsアプリをNginx+UnicornなAWSにCapistranoでデプロイ - 珈琲駆動開発
Special Thanks Rails 初心者が Capistrano3 で AWS EC2 にデプロイするためにがんばったこと。 RailsアプリをEC2にデプロイしてみる。 - xxxcaqui.log 追記@2016/04/29 最近は環境やconfファイルのsetupはitamaeでやるようになりました。めっちゃ楽ですitamae。。 goo.gl totutotu.hatenablog.com PostgreSQLの設定は、以下を参考にしていつも自分でやってます。 totutotu.hatenablog.com 手順 手順をまとめると、以下のようになります。 前準備 nginxの設定 設定ファイルの用意 権限変更 Capistrano設定 Unicorn設定 ssh設定 デプロイ myAppの部分は適宜読み替えてやってください。また、設定ファイルのうち編集する必要がある場所にT
Zero Downtime Deployment With Unicorn And Capistrano - benjaminknofe.com
Everytime we're fixing a bug or adding a new feature, we want it to go live very fast to have happy users at gigmit. Thats why we really love to deploy several times a day. While running a pretty standard Rails stack with Unicorn and handling deployments with Capistrano, we always had a few seconds when the Unicorn workers were restarted. We did this only at night, because it wasn't always sure[1]
Lighting fast, zero-downtime deployments with git, capistrano, nginx and Unicorn · devroom.io
Lighting fast, zero-downtime deployments with git, capistrano, nginx and Unicorn Everyone who has ever developed a web app has had to deploy it. Back in the day you simply uploaded your files with FTP and everything would be good. Today we have to clone git repositories, restart servers, set permissions, create symlinks to our configuration files, clean out caches and what not. Doctor, what’s wron
rails4 + unicorn + nginx - Qiita
@app_path = '/home/rails/rails/test/json_server' worker_processes 2 working_directory "#{@app_path}/" preload_app true timeout 30 listen "/tmp/unicorn.sock", :backlog => 64 pid "/tmp/unicorn.pid" stderr_path "#{@app_path}/log/unicorn.stderr.log" stdout_path "#{@app_path}/log/unicorn.stdout.log" before_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnec
PumaでActiveRecordのErrorが出てハマった話 - 月曜日までに考えておきます
応答に500ms以上掛かる外部APIに依存するサービスを作ってて、Unicornのworker数だと簡単に詰まって死ぬという現象が起きていたのでしばらく前にPumaに置き換えました。 既に Nginx + Unicorn で運用しているサーバのUnicorn部分をPumaに置き換えるのは割と簡単で、これを参考にしたらほぼうまくいきました。(*) coderwall.com : establishing geek cred since 1305712800 (*) ただし、capistranoを set :pty, true にすると capistrano-sidekiqが効かずにsidekiqが動かなくなって死ぬというknown issueを踏んだので注意 それ以降、順当に運用できていたのですが、負荷がかかったときに500エラーが出るという現象はUnicornよりマシになったものの出続けて
最近の Rack サーバ事情について - おもしろwebサービス開発日記
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
Unicorn の graceful restart と環境変数 - eagletmt's blog
Unicorn の graceful restart は無停止でのデプロイを可能にして非常に便利だが、fork を用いて実装されている都合で古いプロセスから新しいプロセスに環境変数が引き継がれるため、そのことに起因するトラブルがいくつかある。 dotenv の設定が書き変わらない 設定情報を dotenv で管理している人も多いと思うけど、環境変数を使っているので罠がある。 例えば最初に .env に MEMCACHE_SERVERS=memcache-server-001:11211 と書いてあったとする。 このとき Unicorn を起動すると、dotenv によって MEMCACHE_SERVERS=memcache-server-001:11211 が環境変数に追加される。 その後、接続先として memcache-server-002:11211 を追加したくなって .env を編
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でさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
unicornにどんなシグナル送るとどうなるのかまとめました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
File: SIGNALS [Unicorn: Rack HTTP server for fast clients and Unix] の一部を超訳しただけ
UbuntuでNginxとUnicornを使いRailsアプリを動かす - Qiita
Ubuntu 13.04 Nginx 1.5.4 Ruby 2.0.0p247 Ruby on Rails 4.0.0 最新のNginxを入れる cd ~ Nginxの鍵をダウンロードし追加する wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key /etc/apt/sources.listに以下の2行を追加する deb http://nginx.org/packages/mainline/ubuntu/ raring nginx deb-src http://nginx.org/packages/mainline/ubuntu/ raring nginx apt-getを更新 sudo apt-get update Nginxをインストール sudo apt-get install
Unicorn+Rails入門 - Less is Best
Railsでよく使われているサーバーUnicornについて勉強しておこうと思います。以前Unicorn+Nginxで動かそうとしたらうまく動かせなかったので、とりあえずゼロからテストアプリ作って、Unicornで動かすまでを1つづつ勉強して仕組みを理解して行こうと思います。 rails new unicorn_sample cd unicorn_sample rails g scaffold article title:string content:string rake db:migrate vim config/routes.rb routes.rb + root "articles#index" で動くアプリを一応作成 Unicornを導入 Gemfile + gem 'unicorn' bundle install touch config/unicorn.rb https://g
Rails 3 + Nginx/Unicorn を Amazon AWS に Capistrano 3 でデプロイする - bekkou68 の日記
はじめに Amazon AWS 環境下で Rails 3 のアプリを Nginx/Unicorn で動くように Capistrano 3 でデプロイする手順をまとめました。 以下を前提に話を進めます デプロイ対象のアプリ/DBインスタンスはすでにつくられているとします デプロイ対象のアプリインスタンスのドメインは production.example.com とします アプリインスタンスは ephemeral disk がマウントされているとします プロジェクト名は myproject とします。ご自身のプロジェクト名に読み替えてください アプリインスタンスに SSHログインするための秘密鍵は ~/.ssh/myproject.pem に配置してあるとします RVM を使ってます。rubyenv での設定はこちらの記事が参考になるかと思います デプロイ先ディレクトリの準備 アプリを /va
nginxのupstreamから502を対象外にする | SawanoBlog 2G
railsをunicornでrackupする際、よくunixsocket経由でnginxをフロントに使う。 で、それをバックエンドにしてさらにNginxでロードシェアする時の設定。 バックエンドのunicornが健在の時はフロントバック間のレスポンスは上図のようになり、適当にロードシェアされます。 nginxのデフォルト設定ではバックエンドがunicornの状態に応じて502を返す際にも、フロントは気にしません。 上図の状態になってもupstream対象を調整せずに、200, 502, 200, 502 とレスポンスを返します。 そりゃ困るということでドキュメントを参照、 HttpProxyModuleのproxy_next_upstream を使ってupstreamのポリシーを指定すればOKです。 デフォルトだとこうなっているので、 “proxy_next_upstream e
Thinは遅い? - lab.ursm.jp
March 02, 2013 「Heroku でアプリケーションサーバを Uniron (or Puma, etc) にしたらn倍速くなったぜ!」みたいな話をたまに見掛けますが、本当なんでしょうか。実験してみましょう。 テスト環境 Funtoo Linux x86-64bit Ruby 2.0.0-p0 Thin 1.5.0 Unicorn 4.6.2 Rainbows! 4.5.0 Puma 1.6.3 アプリケーションは Rack で、50msec の sleep の後に 500KB のレスポンスを返します。各サーバに対して100回のリクエストを、同時接続数を 1-20 の間で変えつつ投げました。詳しくはソースを見てください。 (凡例の c は concurrency、同時接続数です) はい、どう見ても Thin は遅いです。まったくスケールしません。本当にありがとうございました。 こ
Unicornのダウンタイムなし再起動は考え無しに使うと危険 - ひげろぐ
UnicornのプロセスにUSR2シグナルを送ると古いプロセスを残しつつ新しいプロセスが起ち上がるので、ダウンタイムが発生しない。 というのはUnicornの利点の一つとして数えられているが、実は罠なんじゃないだろうかと思い始めた。 USR2を送った直後の状態でプロセスのリストを見ると以下のようになる。（行が長いのでプロセス名の部分だけ抜粋） akahige:# ps aux |grep unico unicorn_rails master -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails worker[0] -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails master (old) -E production -D --path /hog
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PumaとUnicornで最近自分が理解したこと
[Rails] APサーバの比較検証（Puma, Unicorn, Passenger） - Tech Log - s21g
「Server::Starterに対応するとはどういうことか」の補足 : sonots:blog
Capistranoで「nginx + Rails3 + Unicorn + RVM」環境を構築してみた。｜Ruby｜サムライファクトリー開発ブログ
