集合知プラットフォーム事業部・エンジニアの榎本です。コロナ禍の運動不足を解消すべく筋肉体操で筋トレを続けてますが、上腕三頭筋がいい感じに成長しており継続の大切さを身に沁みて実感しております。 目次 TL;DR（三行要約） Rubyアプリケーションのメモリ肥大化問題 jemalloc を使ってみる jemalloc とは？ jemalloc で改善するのか？ jemalloc の設定方法 jemalloc をプロダクション導入してみた結果 まとめ おまけ：jemalloc についてMatzに聞いてみた TL;DR（三行要約） jemalloc でRubyアプリのメモリ効率改善 jemalloc でRubyアプリのパフォーマンス改善 jemalloc の導入も簡単 Rubyアプリケーションのメモリ肥大化問題 Ruby on RailsなどのRubyアプリケーションを運用する上で、メモリ使用量の
Speedshop is a Ruby on Rails performance consultancy that optimizes the full stack - frontend, backend and environment - to generate revenue and cut scaling costs for businesses on Rails through tools, information and training. Fast sites are profitable sites. Speed is a feature. New: 日本に支社があります . Products and Services The Rails Performance Workshop. A four-week program that makes your Rails app f
サーバーサイドエンジニアの内藤(@naitoh) です。 Rails で構築された小規模な APIサーバー(Rails の API モードで構築したもの)で、Ruby 3.2 の YJITを有効化する事で性能アップすることができましたので、喜びを分かち合いたく共有させて頂きます。 shopify.engineering We’re able to measure real speedups ranging from 5% to 10% (depending on time of day) on our total end-to-end request completion time measurements. YJIT を開発した Shopify では 5%から10%の処理速度の改善があったという事で、以前から弊社でも本番で運用を開始したかったのですが、比較的検証のし易い APIサーバーで
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Instrumenting Rails with Prometheus 原文公開日: 2018/02/02 著者: Sam Saffron -- Discourseの共同創業者であり、Stack Overflowでの開発経験もあります。 Discourseで行っているRailsのinstrumentation（測定）方法を皆さまにご紹介します。 私をフォローいただいている方は以下のようなグラフが投稿されているのをたまに目にします。 この種のinstrumentationとグラフ化をNewRelicやSkylightに任せていることがよくありますが、私たちほどの規模になると、instrumentationやグラフ化や監視をローカルで行うことには絶大なメリットがあります。私たちはホスティングをビジネスとして行っており、ホスティングは私
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Faster JSON generation using PostgreSQL JSON function | BigBinary Blog 原文公開日: 2018/05/29 著者: Chirag Shah サイト: BigBinary 参考: JSON関数と演算子 -- 本記事で扱われている関数が掲載されています RailsでのJSON生成方法は多種多様です。#to_jsonメソッドはRailsに組み込まれていますし、jbuildergemやactive_model_serializers gemも同じ目的に使えます。 データベースのレコード数が増加するに連れて、Railsのレスポンス生成時間が大きく増大します。このボトルネックを追うと一般にJSON生成部分にたどり着きます。 最近私たちのアプリで、ページ読み込みに異常に時間が
Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: How to Speed Up Assets Precompilation Time in Ruby on Rails App 原文公開日: 2018/01/10 著者: Marcin Brzeziński サイト: netguru 1つの巨大なファイルに何もかもバンドルしないこと。CDNを用いて、必要なページでだけrequireしましょう（CDNはCKeditorなどのツールでも使われています）。 I18n-jsは翻訳を個別のファイルに保持します。必要な言語だけを設定するようにしましょう。さもないと、新しいライブラリを導入するたびに翻訳ファイルがあっという間に肥大化してしまいます。必要な言語だけを設定することでコンパイル済みファイルの肥大化を回避でき、ひいてはコンパイルとページ読み込みを高速化できます。 config.i18n.
まとめ: アプリのサーバー設定はRuby Webアプリのスループットやコストあたりのパフォーマンスに大きな影響を与えます。設定の中でも最も重要なものについて解説します（2846 word、13分） RubyのWebアプリサーバーは、ある意味で自動車のガソリンに似ています。よいものを使ってもそれ以上速くなりませんが、粗悪なものを使えば止まってしまいます。実際にはアプリサーバーでアプリを著しく高速化することはできません。どのサーバーもだいたい同じようなものであり、取っ替え引っ替えしたところでスループットやレスポンスタイムが向上するわけではありません。しかしダメな設定を使ったりサーバーで設定ミスしたりすれば、たちまち自分の足を撃ち抜く結果になります。クライアントのアプリでよく見かける問題のひとつがこれです。 本記事では、3つの主要なRuby アプリサーバーであるPuma、Unicorn、Pass
meguro.rb#9で発表した資料です 「心霊現象」という文字が映らない心霊現象が発生しております。
Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
という記事があった、色々と面白かったので訳してみる。良いとこも悪いとこもあると思うけど参考までにメモとして 元記事：Top 10 Ruby on Rails performance tips Rubyの基本的なコードを見直してみる自分で作ったクラスよりもできるだけ組み込みのクラスライブラリを使うできるだけ正規表現を使用する、文字列処理にコストの高いループは避けるREXMLは遅いのでLibxmlライブラリを使用する （Cで書かれたXMLパーサらしい、環境に依存するのは嫌かもしれない）if文の多用は避ける、例えば||=を使う ( z||="none" で unless(z){ z = "none" })Hashはコストが高いので他のデータ構造を検討してみる （でも使いたいときあるよね？）キャッシュを有効活用する acts_as_cached でModelをキャッシュ化してみる(PDF資料
RubyProfを使って、Railsアプリのプロファイリングをする方法を紹介します。 まずは、ruby-profをGemでインストールします。 インストールが完了したら、ruby-profプラグインをRailsアプリにインストールします。 ruby-profプラグインは、Gemがインストールされたディレクトリの下にあります。 環境によって場所は変わりますが、例えば/usr/local/lib/ruby/gems/1.8/gems/ruby-prof-0.6.0/rails_plugin/ruby-profなどの場所にあります。 これをvendor/plugins/ruby-profにコピーすれば設定は完了です。 あとはproduction環境でRailsアプリにアクセスすると、以下のようなログが出力されます。 1 Thread ID: 3076980460 2 Total: 2.030
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか？ そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
Rawk - Ruby on Rails Log Analyzer 時間のかかっている処理をログから抽出したいと思い検索し見つけたツールです。 ただのRubyのスクリプトで $> ruby [ダウンロードしたスクリプトファイルのパス] < [対象のログファイルのパス(production.log等) で解析し、コンソールに結果を出力してくれます。 ただ、現時点の最新(1.2)が私の環境(Rails 1.2.5)のログだとうまく動いてくれず(ZeroDivisionErrorが発生)、スクリプトを修正する必要がありました。 修正は、スクリプトの181行目に対し以下のように行いました。 修正前) next unless $_.index("Completed in") == 0 修正後) next unless $_.index("Completed in") 同じ現象が発生するなら試してみて
New Relic Now Dream of innovating more? Start living the dream in October.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
