あまり効果がないという話があったわね

実際、WSL2上でMisskeyバックエンドを動かし（＋DockerにDBとRedis）、1ミリ秒間隔でnotes/createを叩くツールを90ほど並列で動作させたときに明確な差が出ました。
メインプロセスのみの状態に比べ、ためしにワーカープロセスでリクエストを捌くようにしたものの方が応答間隔が短く、より多数のリクエストを捌けているように見受けられました。

（もっと性能的な制約が厳しいVMとかレンサバとかだとどうなるかも見てみたい）

データベースのデータ量が増えてくると、Nodeではなくデータベースがネックになるから効果出ないか、むしろ余計にメモリ消費して逆効果になることがあるわね

リクエスト量が多いかつデータベースの負荷がそこまで高くないシチュエーションが実際どれくらいあるかわからないけどその場合は効果が期待できそう

CPU1コア、メモリ2GBの環境にdocker-composeでアプリ、DB、Redisを詰め込んで、その状態で

1ミリ秒間隔でnotes/createを叩くツールを90ほど並列で動作させたとき

↑をやったらどうなるかの結果次第ですかね。

（systemdか何かでMisskeyのプロセスを複数立ち上げて運用されている方もいるとどこかで見た記憶があり…そのようなシチュエーションで役に立つかも…？）

あまり効果がないという話があったわね

ちなみにこれ、どこで言及されたか覚えてらっしゃいますか…？

この辺も解決できるかもしれない

#10245

Misskeyのバックエンドは、メインプロセスのほかにclusterモジュールを使用してワーカープロセスを立ち上げる造りになっており、メインプロセスではリクエスト→処理→レスポンスの流れを、ワーカープロセスではjobQueueの処理をそれぞれ担っています。

え？そうだったっけと思ったらつい最近そんな仕様になってたわ
#9662

元のIssueは、Serverをメイン (もちろん1プロセス) にやらせるのではなく、1以上のServer専任Worker と 1以上のQueue専任Worker を上げたいみたいなもの。
#9262

リソースが固定な1つのマシンで使うという前提の場合、
Server/Queue処理をフレシキブルにプロセスを設定できることのメリットはあるかもしれないけど
大量のリクエストを捌くために、Server処理専用コンテナを大量に立ち上げるような用途の場合
メインプロセス1つでServerまで処理する方が扱いやすいかもしれないわ。

たしかに。

Server処理専用コンテナを大量に立ち上げる

これはonlyQueueとonlyServerのオプションで実現できそうで、

リソースが固定な1つのマシンで使う

これのうち、そこそこの規模のインスタンスに良さそうなオプションを提供できるか考えるのがこのissueの立ち位置になりそうな感じがしてきました。

（これ、どっかの通信面でボトルネックがあるみたいな話じゃなかったっけ？）

（自分で試してた限りではnodeとdb/redisの間にあると思われるdockerのproxyが悲鳴を上げてた）