ioが3万こえてる。絵文字リアクションもリアルタイム更新なら通信量めっちゃかかると思うし、マストドンよりも1人あたりのコスト高そう。
3万受け入れるためにあのスペックが必要ってんならちょっときついな‥‥

軽量なActivityPub実装を作るとかいう活動が必要なのかもしれない。

絵文字リアクションはほんと魅力的な機能だと思うんだけど、こういう極端なケースが発生してしまうとなんともね‥‥
軽量版は機能少なすぎて需要あるか‥‥

フォロー

@askyq @204504bySE Fedibirdと比較しても今のMisskey重すぎるので、かなり改善の余地あると思うよ。それが間に合うかどうかは別だけど!

機能が多いと重くなるのは当然として、mastodonの公式ドキュメントにあった「Scaling up your server」のページがmisskeyのドキュメントにはないですね。プログラムの改善もそうですが、そもそもスケーリングに対するノウハウが蓄積されているか、スケーリング可能な仕組みになっているか心配なところはあります(いうてもロードバランサでいけるでしょうけど)

@askyq @204504bySE Mastodonのドキュメントにあるぐらいのことはできるようになっていて、misskey.ioもデータベースもジョブキューもフロントも複数に分かれて平行して走ってるので、対応できないということじゃないと思うんだ。

たとえばタイムラインを取得するクエリーがデータベースに直接走ってるのと、redisにフィードして貯めておいてそれを参照してる(Mastodon)のとの違いとか、クエリが遅いとか、アンテナなどの処理が重めだったりとか、いろいろあると思う。

ソースコード読んだりしてなかったのですが、DBを直接読むのは重くなりますね。なるほどです。
一通り落ち着いたあとでいいので工夫すべきポイントですね。今はioに集まりすぎて爆発しないことを祈ります

@askyq @204504bySE ちなみにMastodonではPgBouncerが紹介されてますが、misskey.ioはPgpool-IIだったと思います。

mastodon.socialもパンクしてるときにパフォーマンス改善PRを何個か突っ込んでRTAしてたよw

ちょっと調べてみましたが日本発なうえに2023年12月31日サポート終了なやつでした。。pgBouncerでも問題なさそうですが、Mastodonで「db:migrateのときは使わないように、PREPARED_STATEMENTSをつけるように」と言われてるようなテストは必要なのかしら。

試行錯誤は開発の常ですし、現状を壮大な負荷テストだと思って頑張るしかなさそうです。

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。