Learn how to transform your snail-paced Rails app into a sub-100 millisecond powerhouse. The Complete Guide to Rails Performance is a full-stack course that gives you the tools to make your Ruby on Rails applications faster and more delightful for users, scale better and for less money, and take less effort to maintain. 3rd Edition: Updated for Rails 5 through Rails 7.1 Why is your Rails applicati
AさんはRailsで書かれたある遅いコードの検証をしていました。 X-Runtimeヘッダを見ると $ curl -Is localhost:3000/hello | grep X-Runtime X-Runtime: 5.008580 5秒もかかってる。 しかしRailsのログを見ると Started HEAD "/hello" for 127.0.0.1 at Tue Apr 03 13:04:11 +0900 2012 Processing by HelloController#index as */* Rendered text template (0.0ms) Completed 200 OK in 10ms (Views: 9.7ms) こんな感じで10msで返していることになっている。なんだこれは? こういう状況で疑わしいことの一つとして、Rack等のMiddlewareのど
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
最近会社でHibernateのN+1問題事例を調べてたんですが、ActiveRecordでも当然のように起こりますね。 BOOKSテーブルが、1対NでREVIEWSテーブルと関連を持っています。(BOOKSが1、REVEWSがN) 以下のコードでは、BOOKSテーブルを全件検索して、それに関連するREVIEWSテーブルのレコードを取得して、REVIEWSテーブルのBODYカラムを出力する。 Book.all.each { |book| book.reviews.each { |review| puts review.body } } このコードではBOOKSテーブルに対して1回のSQLが発行され、REVIEWSテーブルに対してはBOOKSテーブルのレコード数分のSQLが発行されます。N+1問題です。BOOKSテーブルとREVIEWSテーブルの多重度に関係なく、親テーブルを複数検索して、子テ
N+1問題とは SQLクエリが 「データ量N + 1回 」走ってしまい、取得するデータが多くなるにつれて(Nの回数が増えるにつれて)パフォーマンスを低下させてしまう問題です。 次のように、何度もクエリが走ってしまい、その度に0.1msほどかかってしまってます。 Processing by PostsController#index as HTML Post Load (0.2ms) SELECT "posts".* FROM "posts" User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 1]] User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id",
Sam Saffron Programming, Technology and the Art of Hacking Recently Godfrey Chan got Discourse working on Rails Master. It was a rather long task that involved some changes to Discourse internals and some changes to Rails internals. Knowing Rails 4.2 was just around the corner I decided that it seemed like the perfect time to see how performance is. Seeing Rails 4.2 contains the adequate record pa
Speed Up Your Rails App by 66% - The Complete Guide to Rails Caching Caching in a Rails app is a little bit like that one friend you sometimes have around for dinner, but should really have around more often. Nearly every Rails app that's serious about performance could use more caching, but most Rails apps eschew it entirely! And yet, intelligent use of caching is usually the only path to achievi
Summary: Ruby apps in the memory-restrictive and randomly-routed Heroku environment don't have to be slow. Achieve (3706 words/18 minutes) I've seen a lot of slow Ruby web apps. Sometimes, it feels like my entire consulting career has been a slow accumulation of downward-sloping New Relic graphs. Why is the case? If you read that bastion of intellectual thought, Hacker News, you'd think it was bec
Releases, Offers & More Be the first to hear about our newest content, best promotions and upcoming events. Plus get 25% off your next purchase. Newsletter Sign Up Download Accounts Your email address is your account identifier. You can create a password, or just download from the links sent via email. My Orders (Resend order emails) How We're Different Hands-on instructions Solutions to real-worl
Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
ニコニコ超会議3のアサインされたブースは超時空ニコニコ研究所だったはずなんですが、 ブース説明会に参加して1時間半ほど真面目に説明を聞いていたところ、 最後の最後に「4人はハッカソン行ってね」と突然言われて「ファッ!?」ってなったわけです。 というわけで超チューニング祭に参加してきました。 やったこと 成果物 フロントエンドの専門知識があるわけでないので 事前に指摘されていたように、 特にフロントを弄ってスピードが改善されるような予感は全くありません。 デザインもできないので提供されたデータ一式には一切手を付けないことにしました。 なので配信周りで速くすることを目論みました。 (全員こっちの方は最低限やってくると思ったのに意外にほとんどの人は全くやってなかった) 方針 配信を速くする その処理をスクリプトで自動化する 元ファイルの構造は弄らない 現実に即した複数ページに応用可能なチューニン
As a follow-up of my previous post I want to explain how to get Sidekiq to work on Heroku with a Redis To Go Nano instance. Because the Nano instance has some connection limitation you have to make some config changes so you won’t get ERR max number of clients reached error messages. Why this post Today I’ve been struggling a lot with getting the Sidekiq to work probably with Redis to Go Nano on H
インフラストラクチャー部の成田です。 先日開催された RubyKaigi 2013 で、 "High Performance Rails" というタイトルの発表をしてきました。 スライドと動画 発表の様子は ustream の録画をご覧ください。 [ustream id=33559705 hwaccel=1 version=3 width=480 height=302] スライドは以下にアップロードしてあります。 High Performance Rails (long edition) // Speaker Deck なお、発表時間の都合上、当日はここから 40 枚ほどのスライドを削除してしまいました。発表に使った短いバージョンのスライドはこちらです。 発表の概要 クックパッドは 2008 年から Ruby on Rails を採用し、ずっと使い続けてきました。サービスが成長するとともに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く