Botframework-solutions: BeginDialogAsync membutuhkan waktu lebih lama untuk dieksekusi pada permintaan pertama

Hai @GustavoMoreiraPT

Ini hanya menguji/men-debug secara lokal dengan emulator? Atau dari bot yang digunakan di Azure dengan ngrok?

Apakah pengguna tambahan memiliki perilaku yang sama? (jika menguji dengan emulator, memulai emulator sekunder dan memulai percakapan baru sebagai pengguna baru)

Hai @dmvtech ,

Terima kasih banyak atas balasan Anda.

Ini terjadi ketika digunakan dari Azure tanpa ngrok, dan dengan ngrok saat dijalankan secara lokal.

Itu hanya terjadi pada pengguna pertama.
Pengguna kedua tidak menunggu 5 detik untuk balasan bot.

Tidak yakin apakah ini adalah perilaku yang dapat kita kendalikan dari pihak kita.
Senang membantu dengan apa pun yang dibutuhkan.

Hai @GustavoMoreiraPT

Dari perilaku yang Anda jelaskan dan pengujian moderat di pihak saya, saya pikir Anda melihat aplikasi inti .net mulai/bootstrap dan server kestrel memulai. Setelah bot berjalan, maka bot tidak perlu melakukan semua itu lagi.

Untuk membantu mengurangi hal ini di lingkungan Azure, Anda dapat memastikan bahwa Layanan Aplikasi diatur ke selalu aktif . Sehingga layanan tidak dimatikan saat tidak digunakan secara aktif (dan karenanya tidak harus memulai ulang).

Selain itu, jika Anda melakukan sesuatu dengan Continuous Deployment, Anda dapat mengonfigurasi sesuatu yang akan mengirim pesan ke bot setelah penerapan. Untuk memastikan startup awal terjadi sebelum pengguna sebenarnya mendapatkannya.

Hai @dmvtech ,

Terima kasih lagi atas balasan Anda.
Untuk memperjelas, kami memiliki solusi khusus yang didasarkan pada kerangka bot, tetapi sudah memperluasnya.
Kami sudah mencoba untuk mengurangi masalah dengan memanaskan pipa sebelum melakukan permintaan pertama.

Tugas pemanasan yang saya bicarakan ini membantu kami meningkatkan waktu respons permintaan pertama sekitar setidaknya 50%. Sebelum tindakan ini, permintaan pertama akan membutuhkan waktu 10 hingga 15 detik untuk dieksekusi. Kami dapat mengurangi waktu ini menjadi rata-rata 5 detik, memberi atau menerima.

Kami juga mengaktifkan "selalu aktif" di AppService. Karena kami memiliki wawasan aplikasi yang diaktifkan untuk AppService, kami dapat mengontrol jumlah permintaan yang datang, dan kami melihat bahwa setelah beberapa saat tanpa permintaan apa pun (5-10 detik), permintaan pertama berikutnya membutuhkan waktu lebih lama untuk dieksekusi daripada yang berikut. .

Meskipun 5 detik bukanlah masalah terburuk di dunia, kami ingin menghindari kemacetan ini dalam solusi kami, dan sejauh ini tidak ada penemuan baru yang dilakukan.

Mempertimbangkan tindakan pemanasan yang saya sebutkan di posting pertama tentang masalah ini, dapatkah Anda melihat beberapa tugas tambahan yang mungkin relevan untuk ditindaklanjuti?

Terima kasih

Hai lagi @dmvtech ,

Saya telah melakukan sesi debugging untuk mencari tahu masalah yang dilaporkan.
Saya menemukan sesuatu yang pasti memakan waktu lebih lama dalam permintaan pertama.

Saat memanggil BeginDialogAsync, salah satu panggilan metode internal terjadi di SkillWebSocketTransport , ForwardToSkillAsync

Meskipun saya masih belum mengukur waktu eksekusi untuk bagian merah tertentu dari kode, karena ini adalah iklan file pdb, saya memiliki batasan tentang cara mengukurnya, jelas bahwa panggilan pertama membutuhkan waktu antara 1,5 hingga 2 ,5 detik rata-rata, sedangkan panggilan kedua langsung dihentikan.

Tentu saja ini mungkin karena beberapa jenis cache yang terjadi di dalam metode, tetapi ini benar-benar memengaruhi pengalaman pengguna kami.

Bisakah kita melihat ini? Dan tolong beri tahu saya bagaimana saya dapat membantu

Sementara itu, saya akan memperbarui posting ini setelah saya memiliki waktu untuk berbagi.

Salam

Halo lagi,

Jadi berdasarkan pesan sebelumnya, kami terus mencari masalah dan pada startup aplikasi, kami sekarang melalui setiap dialog yang kami butuhkan, dan membuat panggilan dummy yang menginisialisasi seluruh pipa dengan titik masuk di SkillDialog. Metode
Dengan cara ini kita sudah memiliki token yang di-cache ketika kita melakukan aktivasi dialog nyata pertama kita. Dengan menerapkan inisialisasi startup ini, kami dapat memulihkan 1 hingga 2 detik tambahan pada permintaan pertama.

Jadi ini bukan masalah khusus pada kerangka bot, melainkan terletak pada paket yang digunakan oleh kerangka bot.

Berdasarkan versi yang kami gunakan, Microsoft.Bot.Builder.Solutions 4.7.0, salah satu dependensi paket ini adalah Microsoft.IdentityModel.Clients.ActiveDirectory, Version=5.2.4.0 , yang merupakan rakitan tempat permintaan token dieksekusi .
Ada panggilan http di sana yang membutuhkan waktu lebih lama, dan itulah alasan kami melihat penundaan tambahan.

Apakah orang lain menghadapi ini?
Saya sangat ingin tahu karena saya belum pernah melihat ini dilaporkan di tempat lain.

Tolong beritahu saya,

Gustavo

Hai @GustavoMoreiraPT

Pengambilan token awal telah menjadi hambatan kinerja startup yang diketahui selama beberapa waktu. Pada bulan November 2017 kami memberikan beberapa panduan yang serupa dengan yang Anda jelaskan: https://blog.botframework.com/2017/11/02/optimizing-latency-bot-framework/ Ini belum diperbarui untuk V4 SDK, tetapi Anda dapat melihat pola serupa dalam mengambil token saat startup, dan menyegarkannya secara berkala di latar belakang.

Hai @EricDahlvang ,

Terima kasih untuk balasan Anda.
Kami melakukan pendekatan serupa, dengan menginisialisasi panggilan dummy ke DialogContext.BeginDialogAsync dan dengan demikian, token akan di-cache sebelum permintaan pertama.
Ini membantu, tetapi masih belum ideal.

Sementara itu, apakah Anda menemukan perbaikan tambahan yang tidak disebutkan dalam artikel?

Terima kasih.

@GustavoMoreiraPT Saya telah mentransfer ini ke repo solusi botframework, tempat paket ini berada: Microsoft.Bot.Builder.Solutions

@solutions team, apakah Anda memiliki rekomendasi lain untuk GustavoMoreiraPT yang dapat membantu meningkatkan waktu startup?

Langkah pertama yang baik adalah bermigrasi ke versi GA baru Keterampilan yang menghilangkan ketergantungan pada Websockets.

Kami memiliki beberapa langkah langsung untuk perubahan VA di sini dan untuk keterampilan khusus apa pun di sini .

Keterampilan GA memiliki pendekatan yang berbeda untuk otentikasi dan saya tidak mengetahui masalah kinerja yang serupa. Jika Anda memiliki masalah dengan pembaruan VA Anda, beri tahu kami dan tertarik untuk melihat bagaimana ini membantu Anda.

Bergantung pada perubahan yang Anda buat pada VA, pendekatan lain adalah membuat VA baru dan memigrasikan perubahan, tetapi jika Anda telah membuat banyak perubahan, langkah-langkah di atas akan memandu Anda.

Hai @darrenj ,

Terima kasih balasannya.

Kami telah melihat versi baru V0.8 dan kami telah menangani perubahan untuk melakukan migrasi, tetapi ini masih dalam proses.

Saya akan membuat Anda diperbarui mengenai hal ini.

Terima kasih banyak sekali lagi.

Hai @GustavoMoreiraPT ,

Hanya menindaklanjuti untuk melihat apakah ada hal lain yang saat ini Anda butuhkan dari kami untuk masalah khusus ini? Kedengarannya berdasarkan komentar terakhir Anda bahwa Anda memiliki jalur maju melalui migrasi ke v0.8.

Jika tidak ada kebutuhan aktif untuk bantuan, maka saya akan menutup masalah untuk saat ini. Jika suatu saat Anda mengalami masalah lebih lanjut mengenai hal ini, jangan ragu untuk mengaktifkan kembali dan kami dapat langsung kembali untuk membantu.

Beri tahu saya jika Anda memiliki keberatan atau membutuhkan bantuan apa pun secara aktif!

Hai @peterinnesmsft ,

Terima kasih untuk balasan Anda.
Saya menunggu metrik tersedia untuk dibagikan dengan Anda setelah migrasi V0.8, tetapi sayangnya karena keterbatasan waktu, migrasi ditunda.

Jadi saat ini kami pada dasarnya membuat penyedia Fake Turn Context pada waktu inisialisasi, yang memaksa penerimaan token dan itu benar-benar menabrak waktu respons permintaan pertama.
Meskipun berfungsi, itu tidak sempurna (masih lebih lambat dari permintaan berikut), tetapi setelah semua ini, kami berhasil mengurangi waktu respons awal dari 10/15 detik menjadi 2/3 detik.

Saya akan membalas komentar ini setelah saya memindahkan proyek ke V0.8.
Untuk saat ini saya pikir itu bisa ditutup, meskipun masalahnya tampak nyata.

Terima kasih atas bantuan Anda dan mari kita bicara segera! :)

Hai @GustavoMoreiraPT ,

Jangan khawatir tentang keterlambatan migrasi. Saya senang Anda berhasil mengurangi waktu respons awal, tetapi saya setuju bahwa kami mungkin dapat membantu menemukan cara untuk menurunkannya lebih jauh.

Saya akan menutup masalah untuk saat ini, tetapi mari kita bahas lagi ketika Anda dapat mengunjungi kembali dan kami dengan senang hati dapat membantu menggali untuk melihat peningkatan seperti apa yang dapat kami lakukan.

Berharap untuk mendengar kembali dari Anda segera! :)

Hai @GustavoMoreiraPT ,

Jangan khawatir tentang keterlambatan migrasi. Saya senang Anda berhasil mengurangi waktu respons awal, tetapi saya setuju bahwa kami mungkin dapat membantu menemukan cara untuk menurunkannya lebih jauh.

Saya akan menutup masalah untuk saat ini, tetapi mari kita bahas lagi ketika Anda dapat mengunjungi kembali dan kami dengan senang hati dapat membantu menggali untuk melihat peningkatan seperti apa yang dapat kami lakukan.

Berharap untuk mendengar kembali dari Anda segera! :)