Bot response time is slow

[somprabhsharma]

I am experiencing slow response time for my bot on messenger, slack, telegram. If i do not use MBF and direct interact with the respective webhook, then the response time is much quicker. Response time through MBF is around 2-3 seconds while it should be less than 1 seconds.

[jameslew]

@somprabhsharma This may be something we're resolving soon. Where is your bot deployed, and where are you connecting to it from (regionally)? Depending where you're at the message is bouncing through our east & west coast datacenters. We're expanding our deployments soon though.

[somprabhsharma]

Our bot is deployed in AWS us-east-1 (N. Virginia) region.

[somprabhsharma]

@jameslew any update on this ?

[jameslew]

Given that you're asking, the fix we did probably hasn't resolved your problem :). We're deployed in the US, Europe and Southeast Asia now.

Can you tell me more about what your bot does (architecture wise)? What services are you using for your bot; LUIS, etc?

I would expect us to introduce some time via the extra hop, but in the 10's to 100 ms range.

[tomlm]

Please post an example JSON of an activity you are posting. We see <~2 second post times in all data centers on most channels (email and SMS are slow at the transport level.)

[ykensuke]

The same issue is happening for me. I was developing with accessing Facebook Graph API directly without MBF. And I'm trying to transfer my code to on MBF, but the delay is obviously big and it effects user experience. My Node.js code is running on AWS EC2 US West (N. California).
Should I use Azure?

[ykensuke]

@tomlm In my case, I just executed session.send('test') with Node.js, and it takes about 4 times longer than accessing Facebook api directly.

This specific testing routes from Send to Receive are
MBF case: Send on Messenger App > Facebook > MBF > our AWS > MBF > Facebook > Receive on Messenger App
No MBF case: Send on Messenger App > Facebook > our AWS > Facebook > Receive on Messenger App

No MBF case takes about 1 second. On the other hand, MBF case took about 3~4 seconds. There are 2 more http requests between our AWS and MBF than No MBF case, but I think normally http request doesn't take such a long time even though the servers place very far location.

[somprabhsharma]

We have abandoned using MBF for its slow response.

[chrimc62]

Sorry this did not work for you. @tomlm is this something that should be better with the new geo locations?

[dandriscoll]

Thanks all for participating in this thread. We're always working to improve performance and have made additional changes since this discussion. Performance investigations tend to be very specific (based on physical location, message payloads, etc.) so if you're encountering poor performance, please open a new issue and we can follow up in detail.

[ishandutta2007]

Microsoft bot framework is too slow compared to direct channel integration.
Bot deployment I tried is india central region.
Too much latency might be a pushback for developers using BotsFramework, which also brings up the question why was it designed this way than providing option to configure and connect to channels directly.

[ykensuke]

I understood and totally agreed with what @dandriscoll explained.
But at least, I hope Microsoft clarifies and announces whether this issue is something about performance of MBF or a problem happening to particular developers unintentionally.
All developers use this framework with big delay like several seconds per requests? Or only us?

[larsbeck]

This may be useful for others. We ran a few tests where we were using the echo sample bot. We sent messages via the DirectLine Nuget Package and received messages through the WebSocket endpoint:

• Hosting Direct Line Client in Azure EU + Hosting Bot as WebJob in EU or WestUS -> 3 seconds from sending a message to receiving echo message
• Hosting Direct Line Client in Azure WestUS + Hosting Bot as WebJob in EU -> 3 seconds from sending a message to receiving echo message
• Hosting Direct Line Client in Azure WestUS + Hosting Bot as WebJob in WestUS -> 0.5 seconds from sending a message to receiving echo message
• Hosting Direct Line Client in Azure WestUS + Hosting Bot as Bot Service (https://azure.microsoft.com/en-us/services/bot-service/) -> 0.5 seconds from sending a message to receiving echo message

[dandriscoll]

We have a new feature in development that further decentralizes the conversation and moves it to a faster backing store. It's in closed beta right now and will be in public preview soon.

[pmizel]

@dandriscoll do you have a specific date for the public preview?
thx

[dandriscoll]

@pmizel, we're looking at this week sometime.

[ykensuke]

@dandriscoll Has the new feature been officially released?

[dandriscoll]

Hi @ykensuke, this feature is available as "High-speed storage." More details here: https://blog.botframework.com/2017/02/02/Direct-Line-performance-improvements/

[champ0007]

on Telegram Channel - I am facing the 4-6 seconds latency in the MBF response (MBF + Azure).
Similar setup API.AI integration using Webhooks on AWS is responding <1sec
I have tried changing the app regions, but the response times are really bad.

[jianwshen]

We are facing a slowness issue to use MS Teams as Chatbot channel.
The average response time from our Chatbot server API is 1000 ~ 2000 ms.
This number is from the API test using Postman.
If using a Chatbot UI to send a 'hello' message, the response time to the Chatbot UI is the same as API response time about 1000 ~ 2000 ms.
But if we integrate the same API with MS Teams as a channel, the response time on MS Teams client console is about 6000 ~ 7000 ms.
There is 5 seconds delay to receive the response message after sending a 'hello' message from MS Teams client console.
The MS Teams client is in Australia.
The question is: How can we know what may cause this slowness using MS Teams as a Chatbot channel?

[kamalpaliwal]

On DirectLine BOT performance is good but once we integrated BOT on Teams, response is very slow. It is taking time more than 10 seconds for each query even Hi and Hello.

[ill-yes]

I'm facing the same issue. Any updates here?