検証用のインスタンスです。トップページの注意書きを読んで下さい。
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回なのは以前からか
?
https://github.com/webpack/webpack-dev-server/issues/2978
なんか起動時に2回ビルドしてるような挙動をしている
よくわからないとりあえず最新のmasterにするか
webpack-dev-serverのときだけ起きるな
これになってるhttps://github.com/tootsuite/mastodon/issues/10926
performance monitoring、SQLが非同期で送信されてる関係でクエリの実行時間が正しく取れてなさそう(とはいえクエリ発行後の空白の時間でなんとなく察せる)
N+1の気配を感じる(通知取得API)
流石に毎秒は大げさなので0.01ぐらいにしておこう
毎秒アクセスがあると考えると、割合を0.005にしても超えるのでは?
10Kってだいぶ少ないなリレー繋いでるからある程度はアクセスあるし
これいいな、発行されてるSQLとかも見れる
月10K transactionsか、なるほど
これ無料枠どこまでなんだアクセス多くないからtraces_sample_rateを0.5にしているけども
❗このインスタンスは検証用インスタンスです。❗ Mastodonのupstreamに追従してエラーを見つけるためのインスタンスです。