Tokioアプリを高速化する原則——「遅い」原因の大半はTokioではなく自分のコードにある
Principles for Fast Tokio Applications
RustConfのUnconfでの議論をもとに、Tokioアプリの性能を引き出す原則をまとめた記事。スケジュールレイテンシの計測から始め、レイテンシにはyield、スループットにはバッチ処理、グローバルリソースやmutexの競合を避け、並列度を制限し、ワーカーを他のスレッドから隔離する。長いポーリングが常に問題とは限らないなど、例外も丁寧に解説している。
Tokioランタイム全体を停止させる最も簡単な方法の1つは、競合したmutexでワーカーをブロックすることだ。
HNでの議論
62- saghm
「ミューテックスには注意」というのは良いアドバイスだが、tokioが代替手段として提供している様々なチャネル（詳細はこちら: https://docs.rs/tokio/latest/tokio/sync/index.html）について明示的に言及していないのは意外だ。様々なユースケースに合う多様なオプションがあり、それらを使うのにランタイム機能を有効にする必要すらない（例えば、awaitせずに完了を一度だけチェックしたい場合など）。tokioを使う際にミューテックスで見てきたボトルネックの少なくとも半分は、ミューテックスを全く使わず、代わりに本当に必要なデータを何らかのチャネルで異なるタスク間で受け渡すことで回避できたと推定する。
他に何度か使った、少しハック的だが目的を達成できるトリックは、ミューテックス下のデータのスナップショットを読むだけで十分で、他の変更を防ぐ必要がない場合だ。その場合、データをクローンしてミューテックスをドロップするだけで、データが古くなる可能性を犠牲にして他の利用を進めることができる。
- 5ersi
真の高性能を求めるなら、スレッドのビジースピン、CPUピニング、SPSC/MPSCリングバッファを使うべきだ。
- dist1ll
Tokioのチューニングをしている段階なら、ef_vi/DPDK + SPDKを検討してみてはどうだろう。
- Tsarp
エージェント型コーディングの素晴らしい使い方の一つは、この種の最適化に役立つ非常に細かいトレーシング計装を追加できることだ。
- denizay
速いTokioo、ドリフト、ドリフト、ドリフト！