ioが３万こえてる。絵文字リアクションもリアルタイム更新なら通信量めっちゃかかると思うし、マストドンよりも１人あたりのコスト高そう。
３万受け入れるためにあのスペックが必要ってんならちょっときついな‥‥
団地妻と付着同一化
@askyq 軽量なActivityPub実装を作るとかいう活動が必要なのかもしれない。
@204504bySE 絵文字リアクションはほんと魅力的な機能だと思うんだけど、こういう極端なケースが発生してしまうとなんともね‥‥
軽量版は機能少なすぎて需要あるか‥‥
@askyq @204504bySE Fedibirdと比較しても今のMisskey重すぎるので、かなり改善の余地あると思うよ。それが間に合うかどうかは別だけど！
@noellabo @204504bySE 機能が多いと重くなるのは当然として、mastodonの公式ドキュメントにあった「Scaling up your server」のページがmisskeyのドキュメントにはないですね。プログラムの改善もそうですが、そもそもスケーリングに対するノウハウが蓄積されているか、スケーリング可能な仕組みになっているか心配なところはあります（いうてもロードバランサでいけるでしょうけど）
@askyq @204504bySE Mastodonのドキュメントにあるぐらいのことはできるようになっていて、misskey.ioもデータベースもジョブキューもフロントも複数に分かれて平行して走ってるので、対応できないということじゃないと思うんだ。
たとえばタイムラインを取得するクエリーがデータベースに直接走ってるのと、redisにフィードして貯めておいてそれを参照してる（Mastodon）のとの違いとか、クエリが遅いとか、アンテナなどの処理が重めだったりとか、いろいろあると思う。
@askyq @204504bySE ちなみにMastodonではPgBouncerが紹介されてますが、misskey.ioはPgpool-IIだったと思います。
mastodon.socialもパンクしてるときにパフォーマンス改善PRを何個か突っ込んでRTAしてたよw
@noellabo @204504bySE ちょっと調べてみましたが日本発なうえに2023年12月31日サポート終了なやつでした。。pgBouncerでも問題なさそうですが、Mastodonで「db:migrateのときは使わないように、PREPARED_STATEMENTSをつけるように」と言われてるようなテストは必要なのかしら。
試行錯誤は開発の常ですし、現状を壮大な負荷テストだと思って頑張るしかなさそうです。
@noellabo @204504bySE ソースコード読んだりしてなかったのですが、DBを直接読むのは重くなりますね。なるほどです。
一通り落ち着いたあとでいいので工夫すべきポイントですね。今はioに集まりすぎて爆発しないことを祈ります