RailsのログファイルをMessagePackで超高速解析!｜TechRacho by BPS株式会社
最近Railsがガンガン出力するproduction.logを解析してどのアクションがリクエスト多いのか、DBがボトルネックになってるアクションはないか、などを調べているんですが、production.logがどんどん肥大化して、解析ツールの開発イテレーションを回す際の効率が悪くなってきました。 また似たようなツールをやたらめったらコピペで作ってきたため、開発効率も悪くなってきたので、ここでAPIを整理しつつ、あわよくばログをなめる部分を高速化できないものかと考えました。 シンプルに正規表現をつかって変化する箇所を切り出していたのですが、これではかなり重いのは自明ですし、がんばって文字列をパースするパーサを作ってもrubyではあまりスピードは出なそう、でもrubyで書きたいし.... ということで、一度パースしたデータを読込みに効率よさそうな形式に変換することで、次以降の解析を高速化しよう
今のJVMに欠けている物
原文: チャールズ＝オリバー＝ナター 今日ツイッターで、「JVM及びJDKが、あらゆるプログラミングにおいて真にイケてるプラットフォームになる為には未だ幾つかの欠陥が有る」と呟きました。沢山の人から「もっと詳しく」とせっつかれたので、ここに短く書き起こしておきます。勿論、これで全部という訳ではないのでしょうが、今日思いついたのはこれだけです。 ゼロから起動する際のパフォーマンス現存するJVMの起動はかなり速いですが、Java 7でのHotSpot（訳注：Sun及びオラクルのJVM）にはこれをより良くする為の改良が盛り込まれています。普通、こういった改良は、バイトコードを予め検証したり（或いは検証の為のヒントを与えたり）、クラスデータを幾つかのプロセスで共有したり、在り来たりではありますがプログラムのロード時間やリンク時間を短縮する工夫を凝らす事で成し遂げられます。ところが、多くのアプリケー
Thin - yet another web server
WhatThin is a Ruby web server that glues together 3 of the best Ruby libraries in web history: the Mongrel parser, the root of Mongrel speed and securityEvent Machine, a network I/O library with extremely high scalability, performance and stabilityRack, a minimal interface between webservers and Ruby frameworks Which makes it, with all humility, the most secure, stable, fast and extensible Ruby we
Matzにっき(2010-05-10)
_ [Ruby] GC mark改善案 おひさしぶり。 GC sweep時間はわりと短縮できそうなので(authorNariくんがLazySweepパッチを書いてくれたし)、 このところGC mark時間を短縮するアイディアはないか、考えている。 今のRubyに入れたいので、制約として、 保守的 mark&sweep write barrierを導入しない というものがある。 しばらく前にTwitterで、「いくつかのオブジェクトをまとめて、その単位でマークする」というアイディアを披露してみたが、すぐに三浦さんから「トラバースのコストが減らないから効果ないんじゃない」との指摘が。ちょっと考えてみたら、確かにその通り。かっくり。 まあ、50年間、いろんな人が考えてきたGCで、画期的なアイディアを思いつくのは難しいよね。 まあ、そういう「誰も知らない系」ではなくて、mark時間短縮に効果のあり
Making Ruby Fast: The Rubinius JIT
In order to execute Ruby code as fast as possible, Rubinius has the ability to compile Ruby code all the way down to machine code when it detects that a method is heavily used. In Rubinius, the system that manages this process is its JIT. In today’s post, I’ll be giving an overview of the various players involved in the path that code takes to get from source to machine code. Without further ado,
JRuby Startup Time Tips
Charles Oliver Nutter Java, Ruby, and JVM guy trying to make sense of it all JRuby has become notorious among Ruby implementations for having a slow startup time. Some of this is the JVM's fault, since it doesn't save JIT products and often just takes a long time to boot and get going. Some of this is JRuby's fault, though we work very hard to eliminate startup bottlenecks once they're reported an
140行で作る分散リアルタイム検索エンジン（Twitter Streaming API対応） - 古橋貞之の日記
マトモに使えるRPCライブラリ MessagePack-RPC for Ruby のバージョン 0.2.0 をリリースしました！ 新たにコネクションプーリングの機能を追加しました。一度接続したコネクションを共有して使い回すことができます。コネクションを何度も張り直す負荷と遅延を削減でき、リソースの消費も抑えられます。 また、不意に切断されたコネクションを自動的に再接続する機能を導入し、信頼性を向上させています。 これを使って何か作ってみようと言うことで、twitterのリアルタイム検索エンジンを作ってみました。日本語を検索できないなど機能は貧弱ですが、プログラム全体がわずか140行に収まっています（クローラ27行、インデクサ48行、クラスタ管理ノード37行、検索クライアント28行）。 新しいつぶやきを受信するたびに、リアルタイムで転置インデックスを作成していきます。インデックスを作成するノ
Unicorn!
EngineeringUnicorn!We've been running Unicorn for more than a month. Time to talk about it. What is it? Unicorn is an HTTP server for Ruby, similar to Mongrel or Thin. It… We’ve been running Unicorn for more than a month. Time to talk about it. What is it? Unicorn is an HTTP server for Ruby, similar to Mongrel or Thin. It uses Mongrel’s Ragel HTTP parser but has a dramatically different architectu
IPA、業務システムでRubyを用いるためのチューニング手法と課題を公表 | エンタープライズ | マイコミジャーナル
IPA(情報処理推進機構)は9月7日、「自治体・企業等の情報システムへのRuby適用可能性に関する調査」の報告書を公開した。同調査ではRubyについて、自治体や企業などの業務システムの開発といった分野を想定し、機能面・非機能面からその適用性の評価を行った。 調査を実施したのは、「Enterprise Ruby コンソーシアム(テクノプロジェクト、みずほ情報総研)」。検証環境は、富士通の「Platform Solution Center」に設けられた検証ルームと検証用機器が用いられた。 富士通「Platform Solution Center」のサーバルームと検証ルーム 同検証の目的は、Rubyを用いた「入出力処理」、入出力処理によって構成される「アプリケーションとしての処理プロセス」を想定したベンチマークを取得し、幅広いアプリケーション開発にRubyを用いる際に参考となる計測データやチュー
longlife gcパッチを作成しました - I am Cruby!
GCGW中にせこせこと作っていたGCパッチをruby-devに投稿しました．内容は以下．Railsのヒープ調査2ヶ月ほど前に，ふと気になってRailsがどんな風にヒープを使用しているか調査してみました．以下のグラフはscaffoldしたRailsアプリを動かした際のものです． 調査前は，「文字列が一番多いんじゃないか」と考えていたのですが，実際には構文木オブジェクトがヒープの半分を占めているようです．その構文木オブジェクトを更に詳しく調べたグラフが以下です． このグラフにあるNODE_METHODやNODE_CFUNC，NODE_FBODYはメソッド定義の際に使用され，NODE_WHILEやNODE_BLOCKはVMの内部で使用されているようです． 長寿命GC更に調査をすると，これらのオブジェクトはとても長生きな事が分かりました．そこで，これらを長寿命領域に隔離してしまおう，という改善を
Passenger Gets Nginx Support With New Version 2.2.0
Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news. Phusion has just announced the release of Passenger 2.2.0, a significant update to the dream-come-true Apache module for deploying Rack-based Ruby applications (including Rails, Sinatra, and Ramaze apps). Or... is it? With 2.2.0 Passenger is now an Nginx module too! So if Apache isn't quite your cup of tea and you were thi
マルチコア時代の高速サーバーの実装 - Blog by Sadayuki Furuhashi
特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に
Ruby 1.9 でアプリケーションが速くなるとしたら - kなんとかの日記
個人的には、Ruby 1.9 を使っても業務アプリケーションや Web アプリケーションはそう速くはならないと思ってる。少なくとも、自分のプログラムでベンチマークした限りではそうだった。 Ruby 1.9 による高速化の恩恵を受けるのは、数値計算を多用するようなプログラムであり、具体的には、数学系、科学技術計算系、ゲーム系のアプリケーションやライブラリがこれに当たる。また業務アプリケーションなら、統計処理や Business Intelligence (BI) 系のものは速くなるだろう。 ただしこういった CPU Bound なものは、Ruby 1.9 でも満足できる速度ではないので、そもそも Ruby がメインとして使われることはほぼないと思う。あっても補助的なものに限定されるだろう。 ただ、次のような場合は業務アプリや Web アプリでも Ruby 1.9 の恩恵を受けるはず。 ・使用
YARV(Yet Another RubyVM)アーキテクチャ
これは？ Compiler (compile.h, compile.c) VM Generator (rb/insns2vm.rb, insns.def)命令記述 VM (Virtual Machine, vm.h, vm.c)レジスタ スタックフレームメソッドローカルフレーム ブロックローカルフレーム クラスフレーム フレームデザインについての補足 メソッド呼び出しについて 例外例外テーブル rescue ensure break, return（ブロック中）、retry 定数の検索定数検索パス 最適化手法threaded code Peephole optimization inline method cache inline constant cache ブロックと Proc オブジェクトの分離 特化命令 命令融合 オペランド融合 stack caching JIT Compile
だいありー
(self, cref, class, default の visibility) の関係． toplevel(main, Object, Object, private) class, module 文(mod, mod を積む, mod, public) module_eval ''(mod, mod を積む, mod, public) module_eval{}(mod, 変更無し, mod, public) instance_eval ''(obj, <<obj を積む, <<obj, public) instance_eval{}(obj, 変更無し, <<obj, public) 1.9 ではいくつか出来ていない．ruby_class と ruby_cref を一緒にしていたため． test-all TESTS=ruby 長すぎ．
RubyにLazySweepのパッチを作った - I am Cruby!
Ruby, GCplanSweepをLazySweepにして、最大停止時間を改善するHeap内のオブジェクト数がある一定を超えてからLazySweepに切り替わる 通常のプログラムのスループットを落としたくないので今は一応100万にしているLazySweepフェイズではHeapの配列の数本を、オブジェクト数が一定になるように選んでSweepする 配列一本ずつのオブジェクト数が異なるため、Sweepの時間がばらつかないように調整したHeapの配列が1.8倍づつ増えるのがメモリ効率的にあんまりよくないので、LazySweepが始まってからは少し抑えるようにした。1.1倍くらい。 理想は「オブジェクトを何百万も作ってプログラムをぶんまわす時の最大停止を改善する。」です。その場合当然スループット性能が低下してしまうのはいかしかたなし。 patchgc_lazy_sweep_r15749_patch
pragmati.st: Scaling Twitter
Britt Selvitelle Alex Payne Preconceived notions about twitter, because a month ago, the “5 questions” explosion. Didn’t say that scaling on rails is hard. He said that they run rails and scaling is hard. The story of twitter. Twitter went from being a small side project of ODEO’s company that was the brainchild of Jack Dorsey to the largest rails app in the world. He was fascinated with AIM statu
Scaling Twitter: Making Twitter 10000 Percent Faster - High Scalability -
Update 6: Some interesting changes from Twitter's Evan Weaver: everything in RAM now, database is a backup; peaks at 300 tweets/second; every tweet followed by average 126 people; vector cache of tweet IDs; row cache; fragment cache; page cache; keep separate caches; GC makes Ruby optimization resistant so went with Scala; Thrift and HTTP are used internally; 100s internal requests for every exter
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby 用仮想マシンYARVの実装と評価 | CiNii Research
ヽ( ・∀・)ノくまくまー(2007-08-20)