Originally presented at Baruco 2014. Updated for RubyConf Portugal 2014. Video here: https://www.youtube.com/watch?v=fGFM_UrSp70.
![Writing Fast Ruby](https://cdn-ak-scissors.b.st-hatena.com/image/square/d88269ab59ecb5917bb45f52efdea70f98a640e2/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F585245d01ee1013238737e42b879906f%2Fslide_0.jpg%3F3712458)
Originally presented at Baruco 2014. Updated for RubyConf Portugal 2014. Video here: https://www.youtube.com/watch?v=fGFM_UrSp70.
Rails の練習ってことでちまちまとアプリを作ってました。作ってたのはまぁ Twitter と連携するちょっとしたアプリ。しかしどうも、作れば作るほどアプリケーションの遅さが気になってきました。で、ぐぐってみると Rails の高速化テクがいくつもヒットしました。 いくつかピックアップして紹介します。(Rails 2 系など古い記事も含まれてます) 1. 『Ruby on Rails を高速化する』IBM DeveloperWorks N+1 クエリー問題 の解決アプローチです。これは Rails のしくみを使って db へのクエリ回数を減らすテクニックですね。Rails で何も考えずにコーディングするよりもある程度知識をもってコード書くだけでクエリを劇的に減らせるってことがわかります。RDB の遅さを緩和することによる高速化ですね。 2. 『現実の世界の Rails、第 2 回:高度な
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました!びっくり!\(^o^)/ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
インフラストラクチャー部の成田です。 先日開催された 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 を採用し、ずっと使い続けてきました。サービスが成長するとともに
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか? そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
Rails製アプリは、1画面に結構な量の情報を表示しようものなら、すぐにパフォーマンスが悪くなってしまいます。基本を押さえておけばこういったことに陥らないのですが、Railsがあまりにもサクサク開発できちゃうもんですから、ついつい調子に乗って基本を忘れてしまいがち。自分を戒めるためにも、パフォーマンス・チューニングの基本をまとめておくことにします。 環境 Rails 3.2.14 Ruby 2.0 sqlite3(データベース) WEBrick(httpサーバ) Mac Book Air 2012 Mid (デュアルコア2.0GHz Intel Core i7) チューニングするデモアプリ いまいち冴えないビジュアルのこのデモアプリ『Bookshelf(本棚)』を使用します。テーブルの1セル(td)に1冊の本が納められているつもりです。 Bookshelf仕様 著者(Author)はN件の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く