You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Pumaに関するfuyu77のブックマーク (19)
-
fuyu77 2024/02/08
-
-
-
-
Rails: Puma/Unicorn/Passengerの効率を最大化する設定（翻訳）｜TechRacho by BPS株式会社
まとめ: アプリのサーバー設定はRuby Webアプリのスループットやコストあたりのパフォーマンスに大きな影響を与えます。設定の中でも最も重要なものについて解説します（2846 word、13分） RubyのWebアプリサーバーは、ある意味で自動車のガソリンに似ています。よいものを使ってもそれ以上速くなりませんが、粗悪なものを使えば止まってしまいます。実際にはアプリサーバーでアプリを著しく高速化することはできません。どのサーバーもだいたい同じようなものであり、取っ替え引っ替えしたところでスループットやレスポンスタイムが向上するわけではありません。しかしダメな設定を使ったりサーバーで設定ミスしたりすれば、たちまち自分の足を撃ち抜く結果になります。クライアントのアプリでよく見かける問題のひとつがこれです。 本記事では、3つの主要なRuby アプリサーバーであるPuma、Unicorn、Pass
-
PumaやSidekiqの設定で必要となる前提知識を絵で理解する
1. はじめに 本記事は、これからPumaやSidekiqの設定を考えていく必要があり、「以下の記事に有用そうな何かが書かれている気がするがどういうことだろう」と頭を悩ませている方に向けて、元ネタの内容を私なりに噛み砕いて整理した記事になります。正確性より概念的理解を重視してまとめており、大枠を理解した上で元記事を読んでいただくと、理解が捗るかと思います。 Rubyのスケール時にGVLの特性を効果的に活用する（翻訳） Rails: Puma/Unicorn/Passengerの効率を最大化する設定（翻訳） Puma 5がリリース！スリープソートによる高速化など（翻訳） Rubyの（グローバル）VMロックをトレースする（翻訳） 2. 「Rubyのスケール時にGVLの特性を効果的に活用する（翻訳）」を理解する 2-1. Rubyのコードを実行する仕組み Rubyのコードはインタプリタによって解
-
-
-
[Rails] APサーバの比較検証（Puma, Unicorn, Passenger） - Tech Log - s21g
仕事でRailsを使うことになり、APサーバの選定にあたってPuma, Unicorn, Passenger の比較検討を行いました。方法としてはJMeterでAPサーバにデプロイしたRailsアプリケーションに対して負荷をかけられるだけかけるというやり方です。 試験環境 試験の環境としては下記の構成です。 Ruby2.0, Rails4 アプリケーションサーバ：1台（VM） JMeterサーバ：3台（VM） JMeterクライアント：1台（通常の作業PC） サーバ構成 hostanameCPU仮想コア数（Per CPU）MemoryDisk用途 loadtest01248192MB20GBAPサーバ loadtest02114096MB20GBJMeterサーバ loadtest03114096MB20GBJMeterサーバ loadtest04114096MB20GBJMeterサーバ
-
Pumaの使い方 まとめ - 猫Rails
感想 スレッドベース 参考 unicornはプロセスベース pumaはスレッドベース MRIのスレッド Jruby・Rubiniusのスレッド スロークライアント railsへの導入 設定 参考URL 設定ファイルの読み込み 設定項目 bind: バインド port: バインド(portとhost) ssl_bind: バインド(SSL) workers: ワーカー数 threads: スレッド数のmin・max environment: 環境 demonize: デーモン化 pidfile: pidファイル置き場 stdout_redirect: 標準出力/標準エラーを出力するファイル preload_app!: プリロード before_fork{}: 各ワーカーのフォーク前の処理 on_worker_boot{}: 各ワーカーのboot前の処理 prune_bundler: phas
-
Pumaの起動におけるpumaコマンドとpumactlコマンドの違い - Qiita
1は何をやっているかというと、Pumaを3000番ポートを指定してproductionモードで起動させている。ただし、最小スレッドは5、最大スレッドは5を指定している。設定ファイルはconfig/puma.rbにあるからそれを読んでね。あと、ちゃんとデーモンで実行してね。といったことをやっている。 対して2はpumactlコマンドを使って起動をおこなっている。どうやら、ポートを指定したり環境を指定したりはしないらしい。ただ、デフォルトで config/puma.rb を読みにいっているようで、記述した設定に沿って起動してくれるみたいだった。 つまり、$ bundle exec puma -C config/puma.rb と $ bundle exec pumactl start は同義なのでは、というところまではすぐに理解できた。 あれ、pumactlコマンドってなんのためにあるんだろう
-
-
-
Ruby on Railsでpuma5系をdeployするときにsytemd関連で躓いたときの処方箋 - Qiita
はじめに 先日Railsアプリをサーバーにデプロイしようとしたらpumaプロセスが立ち上がらない問題が出て躓いたのでそのメモ共有です。 記事がなかなかなかったので同じ現象が起こっている方の役に立てば幸いです 環境 ruby (2.7.1p83) rails (6.0.3.4) puma (5.1.0) capistrano (3.9.0) capistrano3-puma (5.0.4) 発生していた問題 deployは成功しているのにpuma processが存在しない サーバー上で直接起動コマンドを叩いたらpumaは起動する deploy上で使用しているコマンド（systemctl restart puma / systemctl start puma）からはエラーが返ってこない systemctl status pumaではエラーが発生している模様 pumaのログ置き場のshared
-
Rails初心者がハマったCapistranoの環境変数 - dely Tech Blog
こんにちは。 delyコマース事業部エンジニアのjohnです。 もともとは開発部でiOSエンジニアとしてクラシルのiOSアプリ開発をやっていましたが、今年のはじめから新規事業のコマース事業部でwebのフロントエンドやRailsアプリケーションとかいろいろと開発をしています。 この記事は「dely Advent Calendar 2019」の16日目の記事です。 昨日はSREの井上さんによる「10分で完成！WEBサイトパフォーマンス計測基盤 ver.2019」という記事でした。 tech.dely.jp 今回は、Capistranoを使ってRailsアプリケーションをデプロイしたときに環境変数でハマった話を書きます。 なかなか、これ系の記事が少なかったので、gemの中を見るところまでしてみました。 1つのサーバーを使いまわしてのデプロイの話です。インフラがコード化(Infrastructur
-
-
Rails 6リリース記念！？Qiitaにいろいろ記事を書きました - give IT a try
先日、Rails 6が正式にリリースされました。 ついにRails 6が正式リリースされたようです！🎉 Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk | Riding Rails https://t.co/pHoJb68B97— Junichi Ito (伊藤淳一) (@jnchito) 2019年8月16日 だから、というわけでもないのですが、Rails関連の記事をいくつか書いてQiitaにアップしています。 Railsアプリのアップグレードの手順 1つ目はRailsアプリのアップグレード（バージョンアップ）の手順です。 永久保存版！？伊藤さん式・Railsアプリのアップグレード手順 - Qiita qiita.com
-
-
毎分1000リクエスト処理できるようにRubyアプリケーションをスケールさせる： 初心者ガイド | Scout APM Blog
ネイト・ベルコペック (@nateberkopec) SpeedShop(詳細),Railsパフォーマンス・コンサルタンシー 要約:Rubyアプリケーションのための”スケーリング”についての情報は、毎秒数百リクエストを処理している企業によって書かれたものがほとんどです。そうではない私たちのためのスケーリングはどのようなものでしょうか？ スケーリングは敷居の高いトピックです。Rubyアプリケーションのスケーリングに関するブログやインターネットでの情報のほとんどは、毎分何万ものリクエストへのスケーリングについて書かれたものです。TwitterやShopifyの規模です。興味深いですが...Rubyでどれくらいできるか、上限を知ることはいいことです...1台よりは多いものの、せいぜい100台以下のサーバでアプリケーションを実行している、私たちのような大多数にとってはあまり役に立ちません。スケー
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました