Sidekiq アンチパターン: 序 - SmartHR Tech Blog
こんにちは どうも、ぷりんたいです。さいきん、 Mastodon がTwitter廃人たちの間で大ブームですね。 今日はそんな Mastodon の話……ではなく、 Mastodon でも採用されている Ruby 製のバックグラウンドジョブフレームワーク Sidekiq を軸に非同期処理の話をします。 ターゲット読者は、 Sidekiq で非同期処理をはじめたばかりの入門レベル程度の方を想定しています。 アンチパターン アンチパターンとは、一言でいえば「よくないやり方」のことです。 みなさんの現場でも当座をしのぐことだけを目的として、エイヤ設計やソイヤ実装をしてしまうこともあるかもしれません。しかし、それらはしばしの眠りの後に技術的負債、または技術的致命傷としてプロダクトに跳ね返ってきます。 そういった、現場で起こりがちな問題の早期発見や予防をするために、誤った設計や実装の例を集め分類され
なんとなく、Railsアプリケーションの高速化について自分が知っていることを吐き出してみる
まず、RailsやRubyが遅いせいでユーザ体験に影響がでるというのは、普通のWebアプリケーションであれば基本は無いんじゃないかと思います。GitHubもShopifyもRailsです。まず自分のコードや構成を疑うのが大体の場合正しいと思います。 計測して、必要になるまではやらない 時間は貴重なので、不必要な最適化をしないというのが結構重要だと思います。 当て推量で無駄なことをしてしまったり、最適化するの自体が楽しくなってしまって時間を使ってしまいがちです。 その上では 目標を立てて十分早ければそれでよいと考える 例えばクックパッドでは（平均？）レスポンスタイム200ms以下を目標にしているようです 計測する が重要かと思います。 計測するには、とりあえずはありものの道具を使いましょう。 サーバサイドであれば 開発環境にはrack-mini-profiler を入れましょう 本番ではAP
Railsで大量データを扱うときに気をつけていること - LCL Engineers' Blog
バックエンドエンジニアの横塚です。 Railsで中規模以上のサービスを運用していると、大量のレコードやcsvをバッチで処理したい場面などが出てくると思います。 当たり前のように意識できている人も多いかと思いますが、今回はおさらいの意味も込めてバッチで大量データを扱うときに気をつけていることをまとめていこうと思います！ 大量レコードに対して処理をするときはfind_eachやfind_in_batchesを使う DBからデータを取得してきて処理をしたい場合、eachで処理しようとすると対象データがすべてメモリに展開されてしまいますが、find_eachは1行ずつメモリに展開するため、レコード数を気にせず処理をすることができます。 User.each do |user| # なんか処理 end ↓ User.find_each do |user| # なんか処理 end また、find_in_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
