Railsスケーリング（1）Puma、コンカレンシー、GVLのパフォーマンスへの影響を理解する（翻訳）｜TechRacho by BPS株式会社
rails newでRailsアプリケーションを作成したときのデフォルトWebサーバーは、Pumaになります。PumaがHTTPリクエストをどのように処理するかを説明しましょう。 🔗 Pumaがリクエストを処理するしくみ Pumaは受信リクエストをTCPソケットでリッスンします。 リクエストが到着すると、そのリクエストはそのTCPソケットのキューに入れられます。次に、そのリクエストがPumaのプロセスによって取得されます。Pumaのプロセスとは、Railsアプリケーションのインスタンスを実行する、独立したOSプロセスです。 それでは、Pumaがリクエストをどのように処理するかを、順を追って見てみましょう。 Pumaの内部構造 すべての受信コネクションは、ソケットバックログ（socket backlog）に追加されます。ソケットバックログは、保留中のコネクションを保持するOSレベルのキュー
Rubyのスケール時にGVLの特性を効果的に活用する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Practical Effects of the GVL on Scaling in Ruby 原文公開日: 2020/05/11 著者: Nate Berkopec サイト: Speedshop -- フロントエンド、バックエンド、環境を含めたフルスタックのRailsパフォーマンスコンサルタントです。 画像は元記事からの引用ですが、著作権を確認しきれないものはリンクにとどめました。 コンカレンシーとパラレリズムの説明がとても丁寧なのが嬉しいポイントです😋。 概要: MRI RubyのGlobal VM Lock（GVL）は、何かと説明が的外れだったり誤解されたり批判にさらされたりしがちです。RubyはGVLのせいでコンカレンシーにもスケーリングにも縁がないのでしょうか？この点を完全に理解するには、Rubyの仮想マシン（
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
