私はRust Confから帰る途中です。Unconfでは、非同期アプリケーションのデバッグとベンチマークについて生産的な議論を行いました。多くの興味深い洞察が共有されました。ここではそのうちのいくつかを、私自身の経験とともに列挙しようと試みています。これは、ベストプラクティスの生きたドキュメントになればと願うものの最初の草稿です。ぜひissueを立てるかPRを開いてください。今後数日以内に、これらの問題とdial9 traceがどのように見えるかを示すサンプルアプリも追加したいと考えています。—— Russell

Tokioランタイムで優れたパフォーマンスを発揮するコードを書くための厳格で絶対的なルールはほとんどありません。多くの質問への答えは「状況による」です。ワークロードのパフォーマンスは、その瞬間にランタイム上で他に何が動いているかに依存します。だからこそ、多くの問題は本番環境でしか現れないのです！優れたパフォーマンスを発揮する非同期アプリケーションを書くことは、公平性とバッチ処理、競合と分離の間のバランスです。この記事ではいくつかの一般的な原則を提示し、可能な限り例外もカバーします。Tokioのwork-stealingランタイムについての基本的な知識を前提としています。高レベルの概要は付録に含まれています。

一般的な原則

まず、本当に問題があるかどうかを判断してください。Tokioアプリケーションで危険信号を探し始めれば、必ず見つかります。私が見てきたほぼすべての実際のアプリケーションは、Alice Ryhlが彼女の優れた記事What is Blocking?で推奨している10〜100マイクロ秒よりもはるかに長いpollを持っています。これらの問題が、あなたが実際に気にかけているアプリケーションのメトリクスや動作に影響を与えるかどうかは場合によります。改善しようとしている実際のメトリクスから逆算して考えることが重要です。たとえば、アプリケーションが完全に無害な長いpollを持っていることがあります。それらを「修正」しても、ユーザー向けのメトリクスに測定可能な影響はありません。私が遭遇した問題の圧倒的多数では、問題はアプリケーションコード自体にあり、多くの場合、分散システムの複数のコンポーネント間の相互作用にありました（実際にはTokioにはありませんでした）。dial9はTokioに多くの可視性をもたらしました。少なくともTokioの問題を見つけるのと同じくらいの頻度で、実際には問題がないことを明確に示しています。もちろん、時にはTokioの問題であることもあります。Tokioのメトリクスに関しては、最近追加されたschedule latencyヒストグラムが最も有用です。Schedule latencyとは、タスクが実行可能になってからTokioが実際にfutureをpollするまでの時間です。これは原因を教えてくれるわけではありませんが、scheduling latencyはTokioとあなたのコードの間の不適切な相互作用の最も一般的な症状です。

レイテンシのためには分割し、スループットのためにはバッチ処理する。レイテンシを最適化するには、より頻繁にyieldする。多数のリクエストにわたる低レイテンシには、接続間の公平性が必要です。Redis（またはリクエストパイプラインをサポートする任意のアプリケーション）を考えてみてください。素朴な実装では、より多くのデータが利用可能な間、接続から直接データを読み取ります。リクエストがパイプライン化されると、パイプライン化されたリクエスト全体がメモリ内バッファに入ります。そこからフレームを読み取ると、ネットワークに戻ることなく、それぞれがPoll::Readyになります。これにより、長いpollとクライアント間の不公平の両方が生じます。スループットへの影響は通常小さく、同じ数のリクエストが処理されます。しかし、レイテンシは劇的に変化します。なぜなら、パイプライン全体が別のパイプラインの後ろで待つ可能性があるからです。この例では、各リクエストの後に明示的にyieldすることで、レイテンシを約10倍削減できます。連続するいくつかの即座に準備完了の読み取りの後にのみyieldすることで、さらに改善できます。

主要なエンティティ：企業：Tokio、Redis | 人物：Russell、Alice Ryhl | 場所：Rust Conf

FAQ：パフォーマンス問題を診断するための最も有用なTokioメトリクスは何ですか？

最近追加されたschedule latencyヒストグラムが最も有用なTokioメトリクスです。Schedule latencyとは、タスクが実行可能になってからTokioが実際にfutureをpollするまでの時間です。これは原因を教えてくれるわけではありませんが、scheduling latencyはTokioとあなたのコードの間の不適切な相互作用の最も一般的な症状です。