タグ

Rubyとパフォーマンスに関するtoshi3221のブックマーク (5)

  • RubyProfでRailsアプリのプロファイリングをする方法 - Hello, world! - s21g

    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

    toshi3221
    toshi3221 2010/08/23
    ruby-prof 0.6.0付属のrails_pluginを配置すればログにプロファイルがアクセスごとに出る
  • 第4回 Railsアプリケーションをもっと速く | gihyo.jp

    Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか? そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh

    第4回 Railsアプリケーションをもっと速く | gihyo.jp
    toshi3221
    toshi3221 2010/08/23
    railsのplugin内に突っ込めばプロファイリングできるっぽいぞ
  • Rails勉強会@東京第23回に参加してきた : As Sloth As Possible

    表題通り。恵比寿にあるドリコム東京社に行ってRails勉強会に参加してきました。体調不良でえらい豪華なメンバーのランチには参加できなかったし、それどころか恵比寿についてから迷って遅刻ギリギリになるし、まぁいろいろとアレだったけども。うん、そう、ここのところ頭痛いなぁとか思ってたら、体が熱っぽいくて意識が遠くなって、そうかこれ風邪ひいてんじゃね?とか気が付いたのは帰り道。馬鹿は風邪ひかないんじゃなくてひいたことに気が付かないとは名言だなーとか思いながらよれよれと帰ってきました。それはそれとして、勉強会は非常に楽しかったです。以下、自分で後で見返すためにも軽くまとめ。 Rails 2.0は案外普通だな 前半のセッションでは「Rails 2.0を読む」と題してRails 1.2から2.0になって変わったところをざっとさらい、該当箇所のソースを読んで、どんなことやってんだろうなどと話した。Rai

    Rails勉強会@東京第23回に参加してきた : As Sloth As Possible
    toshi3221
    toshi3221 2010/08/23
    Production Log Analyzer、RubyProf、debugger辺りをベンチマーキングに使ってみたという話。
  • 無形ソフトウェア@ふじみ野: railsとjruby on railsのベンチマーク比

    2010年2月21日日曜日 railsjruby on railsのベンチマーク比 今回は、最近話題のwarblerを使ってTomcatにデプロイした rails(jruby on rails)と基的なrailsスタックで、ベンチマークをとり、 パフォーマンスを比較、測定しました。 テストシナリオを以下のとおりです。 ・サーバはscaffoldで作成したありがちな   peopleコントローラとpersonモデルに対し、   一覧表示、作成、更新、削除を行う(入力時間を考慮したタイマーは設けない) ・テストクライアントはjmeterを使用 ・IDはCSVファイルからランダムに抽出   (IDをパラメータから取得するようコントローラは修正済み) ・スレッド数50、ランプアップタイムは2秒 ・合計30回以上のシナリオを走行して平均を取る 構成は以下のとおりです。 【共通】 ・Windows

  • Ruby なんて遅くて使えないよねって言ってみる - Akasata's Page(あかさたのページ)

    2007-07-03 16:25 : Ruby なんて遅くて使えないよねって言ってみる 「Ruby なんて遅くて使えない」という意見が出ます。(昔、Java も似たようなことを言われましたっけ。)これに対して、Ruby 好きな人からは、「大抵の Web アプリではボトルネックは IO になるからアプリの言語は遅くても構わない」「CPU 時間よりも開発者の時間の方が重要」というような反論が展開されます。 Rails 厨にならないためにも、ここは Ruby に批判的な目を持って、この問題を考えてみたいと思います。 ■ 前提 Ruby を採用するとなると Rails 絡みで Web アプリでしょうから、Web アプリについて考えてみます。(でも、DLR とか話に出てくるわけですから、クライアントで使う場合もそろそろ検証した方がいいと思いますけどね。) ■ Ruby は遅

    toshi3221
    toshi3221 2010/08/02
    Webアプリで使っている分には問題ないのかな
  • 1