Botframework-solutions: يستغرق BeginDialogAsync وقتًا أطول للتنفيذ عند الطلب الأول

مرحبًا GustavoMoreiraPT

هذا مجرد اختبار / تصحيح أخطاء محليًا باستخدام المحاكي؟ أو من الروبوت المنتشر في اللازوردية مع ngrok؟

هل لدى مستخدمين إضافيين نفس السلوك؟ (في حالة الاختبار باستخدام المحاكي ، فقم ببدء محاكي ثانوي وبدء محادثة جديدة كمستخدم جديد)

مرحبًا dmvtech ،

شكرا جزيلا لردك.

يحدث هذا عند النشر من اللازوردية بدون ngrok ، ومع ngrok عند التشغيل محليًا.

هذا يحدث فقط للمستخدم الأول.
مستخدم ثان لا ينتظر 5 ثوان لرد الروبوت.

لست متأكدًا مما إذا كان هذا سلوكًا يمكننا التحكم فيه من جانبنا.
يسعدني المساعدة في كل ما هو مطلوب.

مرحبًا GustavoMoreiraPT

من السلوك الذي أوضحته والاختبار المعتدل من جانبي ، أعتقد أنك ترى بدء تشغيل / تمهيد تشغيل تطبيق net. وخادم kestrel. بمجرد تشغيل الروبوت ، فلن يضطر إلى القيام بأي من ذلك مرة أخرى.

للمساعدة في التخفيف من ذلك في بيئة Azure ، يمكنك التأكد من تعيين خدمة التطبيق على التشغيل دائمًا . حتى لا يتم إغلاق الخدمة عند عدم استخدامها بشكل نشط (وبالتالي لا يلزم إعادة تشغيلها).

بالإضافة إلى ذلك ، إذا كنت تفعل شيئًا مع النشر المستمر ، فيمكنك تكوين شيء من شأنه إرسال رسالة إلى الروبوت بعد النشر. للتأكد من بدء التشغيل الأولي قبل أن يصل إليه أي مستخدم فعلي.

مرحبًا dmvtech ،

شكرآ مرة اخرى لردك.
فقط للتوضيح ، لدينا حل مخصص يعتمد على إطار عمل الروبوت ، ولكنه يوسع نطاقه بالفعل.
لقد حاولنا بالفعل تخفيف المشكلة عن طريق إحماء خط الأنابيب قبل تنفيذ الطلب الأول.

ساعدتنا مهام الإحماء التي أتحدث عنها على تحسين وقت استجابة الطلب الأول بحوالي 50٪ على الأقل. قبل هذه الإجراءات ، سيستغرق تنفيذ الطلب الأول من 10 إلى 15 ثانية. تمكنا من تقليل هذا الوقت إلى متوسط ​​5 ثوانٍ ، أكثر أو أقل.

لدينا أيضًا تمكين "دائمًا" في AppService. نظرًا لأنه تم تمكين رؤى التطبيق لخدمة AppService ، يمكننا التحكم في كمية الطلبات التي تصل ، ولاحظنا أنه بعد فترة قصيرة دون أي طلبات (5-10 ثوانٍ) ، يستغرق تنفيذ الطلب الأول التالي وقتًا أطول من الطلبات التالية .

على الرغم من أن 5 ثوانٍ ليست أسوأ مشكلة في العالم ، إلا أننا نود تجنب هذا الاختناق في حلنا ، وحتى الآن لم يتم اكتشاف اكتشافات جديدة.

بالنظر إلى إجراءات الإحماء التي ذكرتها في المنشور الأول حول هذه المشكلة ، هل يمكنك رؤية بعض المهام الإضافية التي قد تكون ذات صلة بالعمل عليها؟

شكرا

مرحبًا مرة أخرى dmvtech ،

لقد كنت أقوم بجلسة تصحيح الأخطاء لمعرفة المشكلة المبلغ عنها.
لقد وجدت شيئًا يستغرق وقتًا أطول بالتأكيد في الطلب الأول.

عند استدعاء BeginDialogAsync ، تحدث إحدى استدعاءات الأسلوب الداخلي على SkillWebSocketTransport ، ForwardToSkillAsync

على الرغم من أنني ما زلت لم أقيس أوقات التنفيذ للجزء الأحمر المحدد من الكود ، نظرًا لأن هذا إعلان ملف pdb ، فإن لدي قيودًا على كيفية قياسه ، فمن الواضح أن المكالمة الأولى تستغرق ما بين 1،5 إلى 2 ، 5 ثوان في المتوسط ​​، بينما يتم إنهاء المكالمة الثانية على الفور.

بالطبع قد يكون هذا بسبب نوع من ذاكرة التخزين المؤقت التي تحدث داخل الطريقة ، لكنها تؤثر حقًا على تجربة المستخدم لدينا.

هل يمكننا إلقاء نظرة على هذا؟ واسمحوا لي أن أعرف كيف يمكنني المساعدة

في غضون ذلك ، سأقوم بتحديث هذا المنشور بمجرد توفر الوقت للمشاركة.

تحياتي الحارة

أهلا مرة أخرى،

بناءً على الرسائل السابقة ، واصلنا النظر في المشكلة وعند بدء تشغيل التطبيق ، نحن الآن نمر بكل مربع حوار نحتاجه ، وننشئ مكالمة وهمية تقوم بتهيئة خط الأنابيب بالكامل بنقطة دخول في BeginDialogAsync .
بهذه الطريقة ، يكون لدينا بالفعل الرمز المميز مؤقتًا عندما نقوم بتنشيط الحوار الحقيقي الأول. من خلال تطبيق تهيئة بدء التشغيل هذه ، تمكنا من استرداد ثانية إلى ثانيتين إضافيتين عند الطلب الأول.

لذا فهذه ليست مشكلة محددة في إطار عمل الروبوت ، بل هي موجودة على حزمة يستخدمها إطار عمل الروبوت.

استنادًا إلى الإصدار الذي نستخدمه ، Microsoft.Bot.Builder.Solutions 4.7.0 ، أحد تبعيات هذه الحزمة هو
هناك اتصال http هناك يستغرق وقتًا أطول ، وهذا هو السبب الذي جعلنا نشهد تأخيرًا إضافيًا.

هل واجه شخص آخر هذا؟
أنا فضولي حقًا لمعرفة ذلك لأنني لم أر هذا المبلغ عنه في أي مكان آخر.

أخبرونى من فضلكم،

جوستافو

مرحبًا GustavoMoreiraPT

كان استرداد الرمز المميز الأولي يمثل عنق الزجاجة المعروف في أداء بدء التشغيل لبعض الوقت. في تشرين الثاني (نوفمبر) 2017 ، قدمنا ​​بعض الإرشادات المشابهة لما وصفته: https://blog.botframework.com/2017/11/02/optimizing-latency-bot-framework/ لم يتم تحديث هذا لـ V4 sdk ، ولكن يمكنك رؤية النمط المماثل لاسترداد رمز مميز عند بدء التشغيل ، وتحديثه بشكل دوري في الخلفية.

مرحبًا EricDahlvang ،

شكرا لردك.
قمنا بأسلوب مماثل ، من خلال تهيئة استدعاء وهمي لـ DialogContext.BeginDialogAsync وعلى هذا النحو ، سيتم تخزين الرمز المميز مؤقتًا قبل الطلب الأول.
لقد ساعدت ، لكنها لا تزال غير مثالية.

في غضون ذلك ، هل وجدت أي تحسينات إضافية لم يرد ذكرها في المقالة؟

شكرا.

GustavoMoreiraPT لقد قمت بنقل هذا إلى botframework-Solutions repo ، حيث توجد هذه الحزمة: Microsoft.Bot.Builder.Solutions

فريق solutions ، هل لديك أي توصيات أخرى لـ GustavoMoreiraPT قد تساعد في تحسين وقت بدء التشغيل؟

ستكون الخطوة الأولى الجيدة هي الانتقال إلى إصدار GA الجديد للمهارات الذي يزيل الاعتماد على Websockets.

لدينا بعض الخطوات المباشرة لتغييرات VA هنا ولأية مهارات مخصصة هنا .

تمتلك مهارات GA أسلوبًا مختلفًا للمصادقة ولست على دراية بمشكلات الأداء المماثلة. إذا كانت لديك أية مشكلات تتعلق بتحديثات جهاز VA ، فالرجاء إخبارنا والاهتمام بمعرفة كيف يساعدك ذلك.

اعتمادًا على التغييرات التي أجريتها على VA ، هناك طريقة أخرى تتمثل في إنشاء VA جديد وترحيل التغييرات ولكن إذا قمت بإجراء الكثير من التغييرات ، فستوجهك الخطوات المذكورة أعلاه.

مرحبا darrenj ،

شكرا على الرد.

لقد لاحظنا الإصدار الجديد V0.8 ونحن نتعامل بالفعل مع التغييرات لإجراء الترحيل ، ولكنه عمل قيد التقدم.

سأبقيك على اطلاع بخصوص هذا الأمر.

شكرا جزيلا مرة أخرى.

مرحبًا GustavoMoreiraPT ،

ما عليك سوى المتابعة لمعرفة ما إذا كان هناك أي شيء آخر تحتاجه منا حاليًا لهذه المشكلة بالذات؟ يبدو استنادًا إلى تعليقك الأخير أن لديك طريقًا للمضي قدمًا من خلال الانتقال إلى الإصدار v0.8.

إذا لم تكن هناك حاجة نشطة للمساعدة ، فسأغلق المشكلة في الوقت الحالي. إذا واجهت في أي وقت مشكلات أخرى بخصوص هذا الأمر ، فلا تتردد في إعادة التنشيط ويمكننا القفز مباشرة مرة أخرى للمساعدة.

اسمحوا لي أن أعرف إذا كان لديك أي اعتراضات أو بحاجة إلى أي مساعدة في أي شيء بنشاط!

مرحبًا peterinnesmsft ،

شكرا لردك.
كنت أنتظر توفر المقاييس لمشاركتها معك بعد ترحيل الإصدار V0.8 ، ولكن للأسف بسبب قيود الوقت ، تم تعليق الترحيل.

لذا فقد أنشأنا حاليًا بشكل أساسي موفر Fake Turn Context عند التهيئة ، مما يفرض الحصول على الرمز المميز والذي أدى بالفعل إلى تجاوز وقت استجابة الطلب الأول.
على الرغم من أنه يعمل ، إلا أنه ليس مثاليًا (لا يزال أبطأ من الطلبات التالية) ، ولكن بعد كل هذا ، تمكنا من تقليل وقت الاستجابة الأولي من 10/15 ثانية إلى 2/3 ثانية.

سأرد على هذا التعليق بمجرد انتقال المشروع إلى V0.8.
في الوقت الحالي ، أعتقد أنه يمكن إغلاقها ، على الرغم من أن المشكلة تبدو حقيقية.

شكرا لمساعدتكم ودعنا نتحدث قريبا! :)

مرحبًا GustavoMoreiraPT ،

لا تقلق من التأخير في الهجرة. أنا سعيد لأنك حققت بعض النجاح في تقليل وقت الاستجابة الأولية ، لكنني أوافق على أنه يمكننا على الأرجح المساعدة في إيجاد طرق لتقليله أكثر.

سأغلق المشكلة في الوقت الحالي ، ولكن دعنا ننتقل إلى هذا مرة أخرى عندما تكون قادرًا على إعادة الزيارة ويمكننا بسعادة أن نساعد في البحث لمعرفة نوع التحسينات التي يمكننا إجراؤها.

نتطلع إلى الاستماع منك قريبًا! :)

مرحبًا GustavoMoreiraPT ،

لا تقلق من التأخير في الهجرة. أنا سعيد لأنك حققت بعض النجاح في تقليل وقت الاستجابة الأولية ، لكنني أوافق على أنه يمكننا على الأرجح المساعدة في إيجاد طرق لتقليله أكثر.

سأغلق المشكلة في الوقت الحالي ، ولكن دعنا ننتقل إلى هذا مرة أخرى عندما تكون قادرًا على إعادة الزيارة ويمكننا بسعادة أن نساعد في البحث لمعرفة نوع التحسينات التي يمكننا إجراؤها.

نتطلع إلى الاستماع منك قريبًا! :)