contentタイムラインへ一斉通知するたびにサーバーが落ちかけるのでチューニングした話RubyRailsリファクタリングチューニング経緯toC向けのサービス(Railsで動いてる)を扱っていて、太古から存在するユーザーさんへの一斉通知のロジックがひどかったので、改修をすることになりました。今回はその際の対応をまとめました。前提として、下記のような感じ。insertしてる上記のため、一斉通知をするたびに、APIサーバーからDBへの接続待ちでCPUがアップアップする。3回に1回くらいはOOM-Killerが発動してサーバーが死んでた。解決案ユーザがそのお知らせ表示の対象者かどうかを判定するテーブルを追加する。ユーザが表示対象であればタイムラインにお知らせを表示し、対象外であれば表示しない。これにより、Timelineテーブルに登録される件数を数万件→1件にすることが可能!例:年齢が20代、プロフィールの都道府県が東京都、など*DB分割やNoSQLで処理する方法もありますが、今回の場合は「そもそも1件登録するだけでよくね?」というのがあったのでこうしました。変更イメージ(雑)before一斉通知ボタンを押すと、Timelineに対象者分のINSERT処理が走るafterTimelineには1件だけ登録し、お知らせ表示対象のユーザ条件を判定するテーブルを作る具体的な対応タイムラインにどのお知らせを表示するか決めるための条件を管理するテーブル(TimelineType)を作る。TimelineTypeは表示条件の種類(年齢、国籍など)を管理するtypeカラムと、その閾値を管理するvalueを持つ。Railsではtypeカラムに入った値がそのモデルのサブクラスとして扱えるので、STIを利用して各サブクラスの中でvalueの値を使って、判定条件を実装する。requestStockLike1yu-croco@yu-crocoパフォーマンス改善が好物のバックエンドエンジニアです。backend/Infraやってます。upLoginユーザーは見つかりませんでした。