あべ(testingmstdn) @abcang@testingmstdn.abcang.net
notificationは関係のないリレーションまで引っ張って来てしまうけど、preloadするよりも愚直にN+1のほうが早かったりするんだろうか
遅かったときの数値を出してしまってた
before:
Completed 200 OK in 256ms (Views: 98.1ms | ActiveRecord: 101.3ms)
SQL数: 67
Completed 200 OK in 216ms (Views: 72.4ms | ActiveRecord: 82.9ms)
SQL数: 59
なんとも微妙な数字(通知数7だからだろうけど、もっと多い場合は効果出るはず…？)
いや考えすぎか
statusの方はstatus_statとかaccount_statとかpreloadしてるし
notificationで*_statをpreloadしてないのはわざとなのか…？
notificationはキャッシュするから常に数値が新しくなるようにしてる…？
あー、ブランチ名が変わったことでmaster追従に失敗していることにようやく気づいた
なんか起動時に2回ビルドしてるような挙動をしている
よくわからない
とりあえず最新のmasterにするか
webpack-dev-serverのときだけ起きるな
performance monitoring、SQLが非同期で送信されてる関係でクエリの実行時間が正しく取れてなさそう(とはいえクエリ発行後の空白の時間でなんとなく察せる)
流石に毎秒は大げさなので0.01ぐらいにしておこう
毎秒アクセスがあると考えると、割合を0.005にしても超えるのでは？
10Kってだいぶ少ないな
リレー繋いでるからある程度はアクセスあるし
これいいな、発行されてるSQLとかも見れる
月10K transactionsか、なるほど
これ無料枠どこまでなんだ
アクセス多くないからtraces_sample_rateを0.5にしているけども
