Tokioで速いRustアプリを書くために、まず疑うべきこと
TokioはRustの非同期処理を支える定番ランタイムですが、速く動かすための「万能の正解」はありません。今回の元記事は、その前提をかなり率直に書いた実践メモです。遅い原因をTokioそのものに決めつける前に、何を測り、どこを疑い、どこで割り切るべきかを整理しています。読みどころは、抽象論ではなく「現場で本当に効く判断」が並んでいるところでしょう。 元記事は、RustConfのUnconfで交わした議論と、自身の経験をもとにした「fast Tokio applications」の原則をまとめたものだ。著者は、Tokioアプリの性能問題にはハードルの低い決まりごとがほとんどなく、「it depends」が多すぎると認める。そのうえで、まず確認すべきなのは本当に問題があるのか、という点だと強調する。多くの実アプリでは、`.await` に戻るまでの「poll」がAlice Ryhlの勧める 10〜100マイクロ秒よりずっと長いが、それが必ずしもユーザー体験やKPIの悪化に直結するとは限らない。見つけた赤信号を片っ端から直すのではなく、改善したい実際の指標から逆算せよ、という姿勢だ。 性能を
papoo.work