GitHub - fastruby/fast-ruby: :dash: Writing Fast Ruby -- Collect Common Ruby idioms.
In Erik Michaels-Ober's great talk, 'Writing Fast Ruby': Video @ Baruco 2014, Slide, he presented us with many idioms that lead to faster running Ruby code. He inspired me to document these to let more people know. I try to link to real commits so people can see that this can really have benefits in the real world. This does not mean you can always blindly replace one with another. It depends on t
Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由（翻訳）｜TechRacho by BPS株式会社
要約 メモリ断片化は測定や診断が困難ですが、驚くほど簡単に修正できることもあります。マルチスレッドのCRubyプログラム（mallocのスレッド単位メモリアリーナ）におけるメモリ断片化の原因を追ってみましょう。本記事のボリュームは3343語、20分程度です。 単純な設定変更だけで問題を完全に解決できることはめったにありません。 私の顧客のSidekiqプロセスが大量のメモリを消費していたことがありました（1プロセスあたり1 GB程度）。開始当初の各プロセスは300MB程度でしたが、時間の経過とともにじわじわと肥大化してほぼギガバイトレベルにまで達したところで落ち着き始めました。 私は顧客にMALLOC_ARENA_MAXというたった1つの環境変数の変更を依頼しました。「2に設定してください」と。 プロセス再起動後、「じわじわ肥大化」現象はピタリと止みました。プロセスのメモリ使用量は以前の半
Rails: Puma/Unicorn/Passengerの効率を最大化する設定（翻訳）｜TechRacho by BPS株式会社
まとめ: アプリのサーバー設定はRuby Webアプリのスループットやコストあたりのパフォーマンスに大きな影響を与えます。設定の中でも最も重要なものについて解説します（2846 word、13分） RubyのWebアプリサーバーは、ある意味で自動車のガソリンに似ています。よいものを使ってもそれ以上速くなりませんが、粗悪なものを使えば止まってしまいます。実際にはアプリサーバーでアプリを著しく高速化することはできません。どのサーバーもだいたい同じようなものであり、取っ替え引っ替えしたところでスループットやレスポンスタイムが向上するわけではありません。しかしダメな設定を使ったりサーバーで設定ミスしたりすれば、たちまち自分の足を撃ち抜く結果になります。クライアントのアプリでよく見かける問題のひとつがこれです。 本記事では、3つの主要なRuby アプリサーバーであるPuma、Unicorn、Pass
Rubyでforkを利用したマルチプロセスでコアを使い切りたい気持ち - Qiita
Rubyで書かれたちょっと重たいバッチ処理があって速くする必要があったので、fork(2)とpipe(2)を使ったマルチプロセス化でコアを活かした並列処理に書き直した話します。 以下の記事に詳しく書いてあるので、TL;DRはそちらを見てな? Forking and IPC in Ruby, Part I Forking and IPC in Ruby, Part II なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 Threadじゃいかんの? — GILについて 並行プログラミングとしてまず最初に思いつくのはマルチスレッド化ですが、RubyにおいてはGVL(Giant VM lock)があるためマルチコアを活かすことは難しいのです。 ネイティブスレッドを用いて実装されていますが、 現在の実装では Ruby VM は Giant VM lock (GVL) を有し
クックパッドの本番環境で使われている Ruby のバージョンが 2.2 になりました - クックパッド開発者ブログ
技術部の鈴木 (@eagletmt) です。 先日、クックパッドで使われている Ruby のバージョンを 2.0.0 から 2.2 にアップグレードしました。 アップグレードは主に @sorah と私で進めました。 今回はアップグレードまでの過程やアップグレード当日の流れ、そして今のところ見られているアップグレードによる効果などについて紹介します。 アップグレードまでの準備 テストを通す Ruby 2.1 がリリースされたときから 2.1 にアップグレードできないか検証環境でテストを回していました。 しかし、当時はクックパッドの全テストを実行すると必ず途中で Ruby がクラッシュする現象に悩まされていました。 Ruby の GC のバグ、拡張ライブラリのバグを疑いながら色々やってみたものの結局解決できず、Ruby 2.2 がリリースされてからもこの状況は改善されませんでした。 しかしある
(翻訳) Ruby 2.2 のシンボル GC - FIVETEESIXONE
Ruby 2.2 の新機能にシンボル GC というものがあります。 正直、「え、シンボルって GC されないから速いんじゃないの？なのにシンボル GC で Rails が速くなるとか話聞くけど、いったいどういうことなの？」という感じでサッパリ理解できてなかったのですが、その辺りの疑問に対してまとめられている記事がありました。 Symbol GC in Ruby 2.2 とても分かりやすく素晴らしい記事だと感じたので、許可をもらって以下に日本語訳を公開します。 Symbol GC in Ruby 2.2 シンボル GC ってなに？それって気にしなくちゃいけないことなの？ リリースされたばかりの Ruby 2.2 の大きな新機能として「インクリメンタル GC」が挙げられますが、もう1つの注目すべき新機能が、この「シンボル GC」 です。 もしあなたがこれまで Ruby の世界で過ごしてきたのな
Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
Writing Fast Ruby
Originally presented at Baruco 2014. Updated for RubyConf Portugal 2014. Video here: https://www.youtube.com/watch?v=fGFM_UrSp70.
Ruby でラインメモリプロファイラ - Qiita
プロファイラ好きなモニタの前の皆さんこんにちは。@sonots です。この記事では、Ruby コードのどの行がどのぐらいメモリを消費しているか調べる方法を紹介します。 オブジェクトの数を数える Ruby には ObjectSpace というオブジェクトの情報を集めたり操作したりする module があります。 このモジュールの each_object メソッドを使用すると、RubyVM 上の全てのオブジェクトを取り出すことができます。 このメソッドを使って、以下のようなコードを書くと、実行した地点で、RubyVM 中にどのクラスのオブジェクトが何個存在しているのかカウントできたりするわけです。興味深いですね! ObjectSpace.each_object.inject(Hash.new 0) {|h,o| h[o.class]+=1; h } #=> {Class=>241, Strin
Writing Fast Rubyというスライドが良い | mah365
ちょっとしたコードの書き方でパフォーマンスが変わることがあります。リーダビリティを重視する向きからすれば小手先のテクニックに映るかも知れないのですが、リーダビリティを維持しながらちゃんとしたパフォーマンスを出すためにも、テクニックを知ることは大事なことだと思うのです。 結構違うもんですなー というわけで、そんなテクニックをまとめたスライドがWriting Fast Ruby。見ていて参考になったのでメモ。 たとえば引数に&blockをとってcallするよりも、yieldの方が5倍速い、とか、 def slow(&block) block.call end def fast yield end mapにブロックを渡すよりも、シンボルを渡す方が20%速い、とか (1..100).map {|i| i.to_s} (1..100).map(&:to_s) mapしてからflattenを呼び出すよ
超チューニング祭に参加した - masarakki's blog
ニコニコ超会議3のアサインされたブースは超時空ニコニコ研究所だったはずなんですが、 ブース説明会に参加して1時間半ほど真面目に説明を聞いていたところ、 最後の最後に「4人はハッカソン行ってね」と突然言われて「ファッ!?」ってなったわけです。 というわけで超チューニング祭に参加してきました。 やったこと 成果物 フロントエンドの専門知識があるわけでないので 事前に指摘されていたように、 特にフロントを弄ってスピードが改善されるような予感は全くありません。 デザインもできないので提供されたデータ一式には一切手を付けないことにしました。 なので配信周りで速くすることを目論みました。 (全員こっちの方は最低限やってくると思ったのに意外にほとんどの人は全くやってなかった) 方針 配信を速くする その処理をスクリプトで自動化する 元ファイルの構造は弄らない 現実に即した複数ページに応用可能なチューニン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsアプリケーションのパフォーマンス改善手法 / #ginzarb