Saya sedang dalam perjalanan pulang dari Rust Conf. Di Unconf, kami melakukan diskusi produktif tentang debugging dan benchmarking aplikasi asinkron. Banyak wawasan menarik dibagikan. Saya mencoba menyebutkan beberapa di antaranya di sini, bersama dengan beberapa pengalaman saya sendiri. Ini adalah draf pertama dari apa yang saya harap dapat menjadi dokumen hidup tentang praktik terbaik. Jangan ragu untuk membuka issue atau mengirim PR. Saya juga berharap dapat menambahkan aplikasi contoh dalam beberapa hari mendatang yang menunjukkan masalah-masalah ini bersama dengan bagaimana tampilan dial9 trace.— Russell

Ada sedikit aturan keras dan cepat untuk menulis kode yang berkinerja baik pada runtime Tokio; jawaban untuk begitu banyak pertanyaan adalah "tergantung". Kinerja suatu beban kerja bergantung pada apa lagi yang berjalan pada runtime saat itu. Inilah sebabnya begitu banyak masalah hanya muncul di produksi! Menulis aplikasi asinkron yang berkinerja baik adalah keseimbangan antara keadilan dan batching, contention dan isolasi. Posting ini memaparkan beberapa prinsip umum dan mencakup pengecualian di mana saya bisa. Ini mengasumsikan keakraban dasar dengan runtime work-stealing Tokio; ringkasan tingkat tinggi disertakan dalam lampiran.

Prinsip umum

Pertama, tentukan apakah Anda memiliki masalah. Jika Anda mulai mencari tanda bahaya dalam aplikasi Tokio, Anda akan menemukannya. Hampir setiap aplikasi nyata yang saya lihat memiliki poll yang jauh lebih lama daripada 10-100 mikrodetik yang direkomendasikan Alice Ryhl dalam postingnya yang sangat baik What is Blocking?. Masalah-masalah ini mungkin atau mungkin tidak memengaruhi metrik atau perilaku aplikasi yang sebenarnya Anda pedulikan. Penting untuk bekerja mundur dari metrik nyata yang ingin Anda tingkatkan. Misalnya, sebuah aplikasi dapat memiliki poll panjang yang sepenuhnya tidak berbahaya; "memperbaiki" mereka tidak akan berdampak terukur pada metrik yang menghadap pengguna. Dalam sebagian besar masalah yang saya temui, masalahnya ada di kode aplikasi itu sendiri, seringkali dalam interaksi antara beberapa komponen sistem terdistribusi (dan sebenarnya bukan di Tokio). dial9 telah memberikan banyak visibilitas ke Tokio; setidaknya sesering ia menemukan masalah Tokio, ia sebenarnya dengan jelas menunjukkan ketiadaannya. Tentu saja, terkadang ini memang masalah Tokio. Dalam hal metrik Tokio, yang paling berguna adalah histogram schedule latency yang baru ditambahkan. Schedule latency adalah jumlah waktu antara tugas Anda siap dijalankan dan Tokio benar-benar melakukan poll pada future. Meskipun ini tidak akan memberi tahu Anda apa penyebabnya, scheduling latency adalah gejala paling umum dari interaksi yang buruk antara Tokio dan kode Anda.

Pisahkan untuk latensi, batch untuk throughput. Yield lebih sering untuk mengoptimalkan latensi. Latensi rendah di banyak permintaan memerlukan keadilan antar koneksi. Pertimbangkan Redis (atau aplikasi apa pun yang mendukung pipelining permintaan). Implementasi naif akan membaca data langsung dari koneksi selama lebih banyak data tersedia. Ketika permintaan di-pipeline, seluruh permintaan yang di-pipeline akan berakhir di buffer dalam memori. Ketika Anda membaca frame darinya, masing-masing akan menjadi Poll::Ready tanpa kembali ke jaringan. Ini menciptakan poll yang panjang dan ketidakadilan antar klien. Dampak pada throughput biasanya lebih kecil: jumlah permintaan yang sama diproses. Namun, latensi berubah secara dramatis karena seluruh pipeline dapat menunggu di belakang yang lain. Secara eksplisit yield setelah setiap permintaan dapat mengurangi latensi sekitar 10× dalam contoh ini. Anda dapat melakukan lebih baik lagi dengan hanya yield setelah beberapa pembacaan berturut-turut yang langsung siap.

Entitas Kunci: Perusahaan: Tokio, Redis | Orang: Russell, Alice Ryhl | Lokasi: Rust Conf