のえる @noellabo@fedibird.com

振り分けはmakara任せﾃﾞｽﾖ

いまチューニングしてるのはフォローインポートで、勝利条件は、じぇいフォローインポートを受け止めきること。

pumaの方は、2台のVPS（先程のsidekiqと同居）にWEB_CONCURRENCY=4 がそれぞれ置かれていて、別の入口になるサーバから、HAProxyでラウンドロビンしている。（ロードバランサー）

最近、その外側にCloudflareが加わっている。これはあっても無くても良い。以前はCloudflareでロードバランシングしていたんだけど、そこそこ金が掛かるので切り替えた。

pumaとsidekiqは、ともにPostgreSQLに接続するので、pgbouncerで接続数を制御するのと、PostgreSQLを2台動かしてレプリケーションし、読み出しだけで良いアクセスについてはレプリカ側にアクセスさせている（リードレプリカという手法）。

（オーバースペックなのでこのへんは真似しなくて良いです）

で、プロセスとキューの振り分けには色々あるけど、ウチはdefault+mailers、push、pullが、VPSを2つ使ってトータル12プロセス。これだと優先順位が付かないので、defaultを優先するために3つめのVPSでdefaultのプロセスだけ立ち上げておこうかと思っている。

defaultが動いていればサーバ内での処理は全て安定して動くので、他が詰まっていても快適に使える。

best-friends.cahtはdefault+mailersを受け持つサーバ、push+pullを受け持つサーバ(extra)の2系統に分けて、必要に応じてそれぞれ増減させる手法だったかな。

しぃちゃんの言うように、リソースの少ないサーバでは、CPUコア数にあわせて、スレッドを絞ってプロセス数でカバーが良いと思います。

Sidekiqのスレッドが効果を発揮するのは処理速度の異なるジョブを平行で実行する時で、例えば20のサーバにDeliveryWorkerが走る時に、pushキューのスレッドが20あると、5つのサーバが凄く遅くても、残りの15はすぐ終了して空きが確保されるので有利というのはあります。

フォローインポートの際は、50あっても塞がるので、どのみち詰まりますw

pullキューは、もともと優先順位を一番低く設定してあって、これを利用して、いくつかの優先順位の低いワーカーがpullを利用するようになっています。

たとえば、投稿を削除する時は、フォロワーへの削除依頼（Delete Activity）はpushキューで処理されますが、リプライやブーストされた相手先サーバへはあまり急ぐ必要がないのでpullキューを使って配送するという戦略をとっています。（DeliveryWorkerはpushですが、LowPriorityDeliveryWorkerはpullを使う）
QT: https://homoo.social/@204504bySE/104206973509156487

あけおめなのだわ

単きもだめだよ

DSNOのこともたまに思い出してあげてください

みんなDSNOの話しててえらいなーと思ったけどdenoの話だった回 #いろいろな回

ぽぺ

haraguaibad