神楽坂しえる @Clworld@md.ggtea.org

(やっぱりそうか(略))

既に積みれてるJobの積み直しはかなり高コストというのもけっこう来る

Sidekiq根本的にRedisにキューがあってそれをpopして処理をしていく感じなので優先度を付けるというのとすごい相性悪い(キューたくさん作ってランダムな確率で比率調整になると思う)

今思い付く限りの Better Sidekiq
・スレッド単位のキュー割り当て
・実行時間比率でのjob割り当て
・特定jobのスレッド占有防止機能(QoS)
・実行時間等による動的優先度調整(重いjobの処理優先度低下)
・async/await(外部リクエスト応答待ち等の際jobを中断して別jobを処理する)
・jobルーティング(画像処理等を特定プロセスのスレッド等に送る)
・プロセス死亡時のリカバリ

定期的に望まれる 銀の弾丸こと Better Sidekiq なんですけど
どこかに要求仕様まとめておくと
見た時にうわーってなって良いと思います

そういえば Amazon Aurora (PostgreSQL互換) ってどうなの

うなしの画像がおいげんさんにBoostされて末代が重くなる現象 良くある<BT

フォロワーが多い上に鯖缶のよしみで多種多様なインスタンスにフォローされてるAdminがtootすると多種多様なインスタンスに飛んでくのでやばい

jpまで行ってもそうなん…

AdminがpostするとSidekiqが詰まる 良くありました。

最近普通のアルファベットの書き方に不安があるしえるさんの心の叫びです。

結構初期の段階でSidekiqのキュー定義を増やしたりしてはいけない縛りは発生していた

Sidekiqのキューで何をどう実行するのかの定義が外部に定義されてしまっているのがまたSidekiqの自由度を制限してしまっているんですよね…。(もっと自由に増やしたり変更できたりすれば強くなりそうなんだけど)

画像ファイルのURLが連合に流れるので後からURLを変えられない問題はmstdn.jpのさくら移行時の爆破主要因だからね…。(md.ggtea.orgだけ画像ファイルURLをstore.ggtea.orgに変えてる)