タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

RubyとBenchmarkとRailsに関するYassLabのブックマーク (8)

  • Redis不要のSolid QueueはSidekiq OSSに勝てるのか?Rails 8で非同期処理を徹底比較

    背景と目的 Rails8.0 ではActive Jobの機能が拡充されたことに加え、これまでの Sidekiq や Resque などに加えて、新たに Solid Queue という選択肢が提示されました。しかしながら、Sidekiq の公式ドキュメントでは以下のような性能差が示唆されています: Active Job 経由と Sidekiq ネイティブ使用で 約1.2倍の差 Solid Queue と比較すると 最大15倍の差 果たしてこれらの差は現実にどの程度再現されるのか? また、Solid Queue を使う場合に Sidekiq に並ぶ性能を発揮するにはどのような設定が必要なのか? OSS ライセンスの範囲内で各方式の性能を定量的に検証しました。 実験環境 実験環境としては筆者のPCにてDocker Desktopのコンテナを利用しました。 Ruby: 3.3.5 Rails: 8

    Redis不要のSolid QueueはSidekiq OSSに勝てるのか?Rails 8で非同期処理を徹底比較
    YassLab
    YassLab 2025/05/23
    “Solid Queueも、スレッド数やプロセス数を適切に調整すれば十分に実用に耐える性能を発揮することがわかりました。 特に新規プロジェクトで Redis を導入せずに構成をシンプルにしたいケースでは、有力な選択肢”
  • Fast Allocations in Ruby 3.5

    Many Ruby applications allocate objects. What if we could make allocating objects six times faster? We can! Read on to learn more! Speeding up allocations in Ruby Object allocation in Ruby 3.5 will be much faster than previous versions of Ruby. I want to start this article with benchmarks and graphs, but if you stick around I’ll also be explaining how we achieved this speedup. For allocation bench

    Fast Allocations in Ruby 3.5
    YassLab
    YassLab 2025/05/23
    “Object allocation in Ruby 3.5 will be much faster than previous versions of Ruby. I want to start this article with benchmarks and graphs, but if you stick around I’ll also be explaining how we achieved this speedup. ”
  • 「RailsアプリはIO-boundである」という神話について考える(翻訳)|TechRacho by BPS株式会社

    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Mythical IO-Bound Rails App | byroot’s blog 原文公開日: 2025/01/23 原著者: byroot -- Railsコアコミッター、Rubyコミッターであり、ShopifyのRuby/Railsインフラチームのシニアスタッフエンジニアです 日語タイトルは内容に即したものにしました。 IO-boundは英ママとしました。 私がやりたいのは、Pitchfork1に関する記事を書いて、これがどんな理由でできたのか、なぜ現在のような形になったのか、そして今後どうなるのかについて説明することです。しかしその前に、いくつか解説しておく必要があります。 Railsとパフォーマンスの話題になると「データベースがボトルネックになる」という話がよく持ち上がりますが、RailsはいずれにしてもI

    「RailsアプリはIO-boundである」という神話について考える(翻訳)|TechRacho by BPS株式会社
    YassLab
    YassLab 2025/02/19
    “より効率的な方法があるかどうかを誰もプロファイラでチェックしなかったといった理由で、Rubyコードが目に見えて遅くなってしまう可能性もある / 使い勝手とパフォーマンスは必ずしも相反するものではありません”
  • Railsの起動時間を7分の1にした話|taogawa

    こんにちは。2021年12月にCAMPFIREに入社した小川です。 CAMPFIREではRailsを使って開発しています。わたしの入社後、いくつかRailsのパフォーマンスチューニングをする機会があったのですが、今回はそのうち、開発環境でのRailsの起動時間を約7分の1に短縮することができた事例についてご紹介したいと思います。 Railsの起動が遅いCAMPFIREで開発をしはじめてひとつ気づいたのが、開発環境でのRailsの起動にやけに時間がかかることでした。計測してみると1分以上かかっています・・・。 $ time bundle exec rake environment # ... real 1m10.845s user 0m8.075s sys 0m2.086s これは遅い。アプリケーションの規模はたしかに大きいのですが、それを加味しても遅すぎる印象です。 チームメンバーに尋ねて

    Railsの起動時間を7分の1にした話|taogawa
    YassLab
    YassLab 2025/02/17
    "速度改善においては、まず大まかなプロファイリングでボトルネック箇所を特定し、そこからより具体的に箇所を特定していくとやりやすい / BumblerはRailsの起動周りで大まかなボトルネック箇所のプロファイリングに便利"
  • 【Rails7】パフォーマンス測定ヘルパー「benchmark」で、特定の処理の速度を測ってみる

    #db/seeds.rb User.create!( name: "kamekame", email: "example-1@practice.com", password: "password", password_confirmation: "password" ) 700.times do |n| Post.create!( title: Faker::Music.band, content: "example-#{n+1}", user_id: 1 ) end ②benchmarkヘルパーをcontrollerに埋め込む 今回は、 ①posts#indexにアクセスし、@posts = current_user.posts.order(created_at: :desc)の処理を終えるまでにかかる時間 ②posts#showにアクセスし、@post = current_user.p

    【Rails7】パフォーマンス測定ヘルパー「benchmark」で、特定の処理の速度を測ってみる
    YassLab
    YassLab 2024/12/20
    “Railsを学ぶ中で、処理速度の測定に興味を持ちました。 調べていくと、Railsで使用することのできる「benchmarkヘルパー」を見つけたため、実際に試してみました。”
  • Is my host fast yet?

    Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web. Leaderboard: November 2024 Looking for the latest data? Check out the HTTP Archive Tech Report Sort by Client Host Client Websites Fast (p75 < 800ms) Average Slow (p75 >= 1800ms) See a missing hosting provider? Please help us identify how to surface them here. How do you measure real-w

    YassLab
    YassLab 2024/05/02
    “Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web. ”
  • https://twitter.com/tobi/status/1785651701858394334

    YassLab
    YassLab 2024/05/02
    “Good, but we can do better.”
  • Goで作ったシステムをRubyでリプレイスすることを検討してみた

    はじめに 弊社にはGoで作ったシステムが存在しますが、作られてから数年が経過して、メンテナンスも十分にできていない状況でした。 そこで、このシステムをリファクタリングして生産性を上げようという結論になりました。 リファクタリングにあたり、Goのままで行くのか、弊社でよく使われているRubyで行くのかを検討してみましたので、その過程を紹介したいと思います。 Rubyでリプレイスしようと思った理由 Goで動いてて言語やライブラリのバージョンアップなどメンテナンスがされてない部分はありますが、 そこを解消すればGoのままで行った方が良いのでは?と思うかもしれません。 しかし、あえてRubyでリプレイスしようと思うに至ったのは以下の点があります。 Rubyの方が開発速度があがりそう Goのリファクタリングをするのに時間がかかりそう Goのリファクタリングと機能追加でコード修正箇所が被るとスケジュー

    Goで作ったシステムをRubyでリプレイスすることを検討してみた
    YassLab
    YassLab 2024/05/01
    "実装に掛かった時間は1日程度 / Goのコード量は1,000行を超える / Rubyでは300行ほど / やはりAPIとDBの処理時間が全体の大半を占めている / 処理時間に大きな差が発生してない / CPUリソースは多く使いそうなのでその点は考慮”
  • 1