Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signalr hub connection taking almost 40 seconds time to connect with server. #4582

Open
arielchawla opened this issue Aug 20, 2021 · 11 comments
Labels
more-info-needed We are currently waiting for a response. No further triage action is needed at this time.

Comments

@arielchawla
Copy link

On local host it is working fine but when I deployed on live server then its not working properly, it is taking very long time to connect. Please suggest me how can I solve this issue?

@arielchawla
Copy link
Author

any one faced this issue before?

@JGdalevich
Copy link

Hi,

I have not seen this problem before but here is some info that could help.

What protocol are you using? It might be that it is taking too long to negotiate between the client and the server about which protocol to use. Try setting it to websockets if possible and check if the problem is still there?

What client(s) are you using? JavaScript, .NET, something else...? What version of SignalR? Are you seeing the issue with any particular ones? If you are using JavaScript, is there a particular browser that is having an issue?

If you are not using the latest version 2.4.2, try it.

Check SignalR trace and logs (https://docs.microsoft.com/en-us/aspnet/signalr/overview/testing-and-debugging/enabling-signalr-tracing). It should show you what is happening and which steps take so long. Check if there are any exceptions inside of the SignalR library.

Are you using a proxy? If yes, check the proxy log for /negotiate and /abort SignalR messages. This is a good website explaining what the messages mean https://blog.3d-logic.com/2015/03/29/signalr-on-the-wire-an-informal-description-of-the-signalr-protocol/.

Finally, how many servers do you have in production? If more than one, are you using a backplane?

Hope this helps.

@arielchawla
Copy link
Author

arielchawla commented Aug 26, 2021

I am using SignalR (Microsoft.AspNet.SignalR (Version: 2.4.2)). On localhost it is working fine and response time is very fast, but when I'm deployed project to live server it is taking too much time to make connection.
Initially, it was taking around 30-40 seconds to make a connection and then I made a change on client side i.e. $.connection.hub.start() in the $.connection.hub.disconnect event. Now it is taking average 10 seconds to connect. Should I do any specific changes on server side or client side so that we can reduce connection time more ?

I noticed that on google chrome, and edage it is connecting in 10 seconds average but on Firefox and Internet explorer it is not connecting. All these browsers are in latest version

Here is my javascript code:

var chatHub = $.connection.chatHub;
           var qsGroupId = '@groupId';
           var qsEmail = '@email';
           registerClientMethods(chatHub);
           $.connection.hub.qs = { 'groupId': qsGroupId, 'email': qsEmail };         
           $.connection.hub.logging = true;
           $.connection.hub.start({ transport: ['webSockets'] }).done(function () {
               registerEvents(chatHub);
               $("#connection .green").text("Connected").removeClass("blink_me");
           }).fail(function(obj)
           {
               $("#connection .green").text("connection failed").addClass("blink_me");
           debugger;
           });
           var tryingToReconnect = false;
           $.connection.hub.disconnected(function () {
               //TODO: write the logic to reconnect to server.
               if (!tryingToReconnect) {
                   // notifyclient about disconnection
                   $("#connection .green").text("Connecting...").addClass("blink_me");
                       setTimeout(function () {
                           $.connection.hub.start({ transport: ['webSockets'] }).done(function () {
                               debugger;
                               $("#connection .green").text("Connected").removeClass("blink_me");
                               registerEvents(chatHub);
                           }).fail(function (obj) {
                               debugger;
                               $("#connection .green").text("connection failed").addClass("blink_me");
                           });
                       }, 1);
               }
           });
           $.connection.hub.reconnecting(function () {
               tryingToReconnect = true;
               $("#connection .green").text("Connecting...").addClass("blink_me");
           });
           $.connection.hub.reconnected(function () {
               tryingToReconnect = false;
               $("#connection .green").text("Connected").removeClass("blink_me");
           });

Here is server side code on startup:
app.MapSignalR();

I have not added any specific changes for proxy.

I have not tried this one, let me try with that:
Check SignalR trace and logs (https://docs.microsoft.com/en-us/aspnet/signalr/overview/testing-and-debugging/enabling-signalr-tracing).

I have two servers, one is for development and one is for production. I have tried on both.

@JGdalevich
Copy link

Hi,

{ transport: ['webSockets'] } this means that you are only using the websocket protocol from the client side. Is this what you want?

Try tuning SignalR on the server: https://docs.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/handling-connection-lifetime-events

There is also a section on improving SignalR performance in the documentation https://docs.microsoft.com/en-us/aspnet/signalr/overview/performance/signalr-performance

For Firefox and IE issues, checkout StackOverflow:

Looks like you may want to add a timeout to your client connect logic and change the order.

Get traces from both the client and the server. Compare client traces between Chrome and Firefox to see the differences. Try running the sample project from the documentation to see if the problem can be preproduced. This could point to something in the infrastructure.

@arielchawla
Copy link
Author

arielchawla commented Aug 28, 2021

There is not specific reason for using webSockets, now I am using just $.connection.hub.start() and it is working on all browsers.

I have also followed above examples but connection time not improved.
Some time it is connecting in 10 seconds but next time time it is taking time around 20 to 40 seconds,
I am testing with multiple tabs and few tabs are connected in 10 seconds, other tabs are taking long time to connect with hub.

I am trying to fix it from 3 weeks but I did not get access to improve connection time.
I have also noticed that it is working fine on local server, Godaddy, AWS.
But Signalr has issue only on Umbraco Cloud server.

These are the traces on development server (Umbraco Cloud server):

SignalR.Transports.TransportHeartBeat Information: 0 : Connection 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is New.
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 4449cfd3-ca0e-4ed4-ba68-8368d0029da1, transport: WebSocketTransport, message: {"C":"d-E483F0D6-B,21|s,0|D,0|t,1","S":1,"M":[]}
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 4449cfd3-ca0e-4ed4-ba68-8368d0029da1, transport: WebSocketTransport, message: {"C":"d-E483F0D6-B,22|s,1|D,0|t,1","M":[{"H":"chatHub","M":"onConnected","A":["4449cfd3-ca0e-4ed4-ba68-8368d0029da1","test@test.com",[{"ConnectionId":"035d68f9-bf1b-4d59-b2fd-6bd54027ebbd","UserName":"user@user.com","UserImage":"/media/l2ffvsm5/icon.png","LoginTime":"8/27/2021 5:36:27 PM"},{"ConnectionId":"864e5eb7-4daa-4205-a866-ca7a505d7ae0","UserName":"test@test.com","UserImage":"/media/xwvca5ai/abte11fd93f6c9ef1798b63ddaea915fcdbaf0c768d86cb2488c7e570033d050e63.jpg","LoginTime":"8/27/2021 5:50:04 PM"}],[]]}]}
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 4449cfd3-ca0e-4ed4-ba68-8368d0029da1, transport: WebSocketTransport, message: {"I":"0"}
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 864e5eb7-4daa-4205-a866-ca7a505d7ae0, transport: WebSocketTransport, message: {"C":"d-E483F0D6-B,22|o,1|D,0|p,1","M":[{"H":"chatHub","M":"onNewUserConnected","A":["4449cfd3-ca0e-4ed4-ba68-8368d0029da1","test@test.com","","8/27/2021 5:52:03 PM",[{"ConnectionId":"035d68f9-bf1b-4d59-b2fd-6bd54027ebbd","UserName":"user@user.com","UserImage":"/media/l2ffvsm5/icon.png","LoginTime":"8/27/2021 5:36:27 PM"},{"ConnectionId":"864e5eb7-4daa-4205-a866-ca7a505d7ae0","UserName":"test@test.com","UserImage":"/media/xwvca5ai/abte11fd93f6c9ef1798b63ddaea915fcdbaf0c768d86cb2488c7e570033d050e63.jpg","LoginTime":"8/27/2021 5:50:04 PM"}]]}]}
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : c2c8c048-db03-4696-b990-d47cb74fd4f3 is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection c2c8c048-db03-4696-b990-d47cb74fd4f3
SignalR.Transports.WebSocketTransport Information: 0 : Abort(c2c8c048-db03-4696-b990-d47cb74fd4f3)
SignalR.Transports.WebSocketTransport Information: 0 : End(c2c8c048-db03-4696-b990-d47cb74fd4f3)
SignalR.Transports.WebSocketTransport Verbose: 0 : Cancel(c2c8c048-db03-4696-b990-d47cb74fd4f3)
SignalR.Transports.WebSocketTransport Verbose: 0 : DrainWrites(c2c8c048-db03-4696-b990-d47cb74fd4f3)
SignalR.Transports.WebSocketTransport Information: 0 : CompleteRequest (c2c8c048-db03-4696-b990-d47cb74fd4f3)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.WebSocketTransport Information: 0 : CloseSocket(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.WebSocketTransport Information: 0 : CloseSocket(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 864e5eb7-4daa-4205-a866-ca7a505d7ae0 is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 864e5eb7-4daa-4205-a866-ca7a505d7ae0
SignalR.Transports.WebSocketTransport Information: 0 : Abort(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.WebSocketTransport Information: 0 : End(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.WebSocketTransport Verbose: 0 : Cancel(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.WebSocketTransport Verbose: 0 : DrainWrites(864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 4449cfd3-ca0e-4ed4-ba68-8368d0029da1 is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 4449cfd3-ca0e-4ed4-ba68-8368d0029da1
SignalR.Transports.WebSocketTransport Information: 0 : Abort(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.WebSocketTransport Information: 0 : CompleteRequest (864e5eb7-4daa-4205-a866-ca7a505d7ae0)
SignalR.Transports.WebSocketTransport Information: 0 : End(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.WebSocketTransport Verbose: 0 : Cancel(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.WebSocketTransport Verbose: 0 : DrainWrites(4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.WebSocketTransport Information: 0 : CompleteRequest (4449cfd3-ca0e-4ed4-ba68-8368d0029da1)
SignalR.Transports.TransportHeartBeat Information: 0 : Connection 11a4dd08-ba7b-4e95-beb8-ef112235a81c is New.
SignalR.Transports.ServerSentEventsTransport Verbose: 0 : Sending outgoing message. Connection id: 11a4dd08-ba7b-4e95-beb8-ef112235a81c, transport: ServerSentEventsTransport, message: data: {"C":"d-E483F0D6-u,0|v,0|w,0|x,1","S":1,"M":[]}


SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.TransportHeartBeat Information: 0 : Connection 561bf1e9-7097-4571-a28f-05f90efeb75c is New.
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 561bf1e9-7097-4571-a28f-05f90efeb75c, transport: WebSocketTransport, message: {"C":"d-E483F0D6-u,0|y,0|w,0|z,1","S":1,"M":[]}
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 561bf1e9-7097-4571-a28f-05f90efeb75c, transport: WebSocketTransport, message: {"C":"d-E483F0D6-u,0|y,1|w,0|z,1","M":[{"H":"chatHub","M":"onConnected","A":["561bf1e9-7097-4571-a28f-05f90efeb75c","test@test.com",[{"ConnectionId":"035d68f9-bf1b-4d59-b2fd-6bd54027ebbd","UserName":"user@user.com","UserImage":"/media/l2ffvsm5/icon.png","LoginTime":"8/27/2021 5:36:27 PM"},{"ConnectionId":"561bf1e9-7097-4571-a28f-05f90efeb75c","UserName":"test@test.com","UserImage":"/media/xwvca5ai/abte11fd93f6c9ef1798b63ddaea915fcdbaf0c768d86cb2488c7e570033d050e63.jpg","LoginTime":"8/28/2021 12:13:11 PM"}],[]]}]}
SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 561bf1e9-7097-4571-a28f-05f90efeb75c, transport: WebSocketTransport, message: {"C":"d-E483F0D6-u,1|y,1|w,0|z,1","M":[]}
SignalR.Transports.ServerSentEventsTransport Verbose: 0 : Sending outgoing message. Connection id: 11a4dd08-ba7b-4e95-beb8-ef112235a81c, transport: ServerSentEventsTransport, message: data: {"C":"d-E483F0D6-u,1|v,0|w,0|x,1","M":[{"H":"chatHub","M":"onNewUserConnected","A":["561bf1e9-7097-4571-a28f-05f90efeb75c","test@test.com","","8/28/2021 12:13:11 PM",[{"ConnectionId":"035d68f9-bf1b-4d59-b2fd-6bd54027ebbd","UserName":"user@user.com","UserImage":"/media/l2ffvsm5/icon.png","LoginTime":"8/27/2021 5:36:27 PM"},{"ConnectionId":"561bf1e9-7097-4571-a28f-05f90efeb75c","UserName":"test@test.com","UserImage":"/media/xwvca5ai/abte11fd93f6c9ef1798b63ddaea915fcdbaf0c768d86cb2488c7e570033d050e63.jpg","LoginTime":"8/28/2021 12:13:11 PM"}]]}]}


SignalR.Transports.WebSocketTransport Verbose: 0 : Sending outgoing message. Connection id: 561bf1e9-7097-4571-a28f-05f90efeb75c, transport: WebSocketTransport, message: {"I":"0"}
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(561bf1e9-7097-4571-a28f-05f90efeb75c)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.ServerSentEventsTransport Verbose: 0 : DrainWrites(11a4dd08-ba7b-4e95-beb8-ef112235a81c)
SignalR.Transports.ServerSentEventsTransport Information: 0 : CompleteRequest (11a4dd08-ba7b-4e95-beb8-ef112235a81c)

@JGdalevich
Copy link

Hi,

But Signalr has issue only on Umbraco Cloud server.

This sounds like an infrastructure problem. I also have an issue where SignalR works great in QA but not in Production; however, my issue is with using backplane and sharing SignalR load between multiple servers.

What about traces on production server? My understanding is that the development server is working fine. Is the trace from the server that is working fine? Get the trace from the problem server and a client and see what the differences are.

How many clients do you have at any one time? Check the logs to see if they are constantly connecting and disconnecting. This can cause an issue. In my implementation, I ended up adding my own ping to keep the connection alive. You might also want to "play" with the timeout settings in Application_Start.

This is what I have:

GlobalHost.Configuration.ConnectionTimeout = TimeSpan.FromSeconds(110);
GlobalHost.Configuration.DisconnectTimeout = TimeSpan.FromSeconds(30);
GlobalHost.Configuration.KeepAlive = TimeSpan.FromSeconds(10);
GlobalHost.Configuration.DefaultMessageBufferSize = 32;  // This is the minimum size

Finally, add this to your client to see if there are connection issues.

$.connection.hub.connectionSlow(function() {
    notifyUserOfConnectionProblem(); // Your function to notify user.
});

@arielchawla
Copy link
Author

It may be infrastructure problem. Actually sometime it is connecting in 3 seconds only, so I am thinking Is that infrastructure issue?

I checked traces of transports.log.txt on dev and live and it is same on both.

I also tried GlobalHost.Configurations but connection making time is not reducing.

@JGdalevich
Copy link

Sounds like something with infrastructure to me. You could try Wireshark to see if there is something that takes place when the connection is delayed.

@satish2832
Copy link

#4590

@BrennanConroy BrennanConroy added the more-info-needed We are currently waiting for a response. No further triage action is needed at this time. label Sep 16, 2021
@telshahawy
Copy link

@arielchawla any results?
I can't even connect on production for some reason, gives connection timeout.

@vazricv
Copy link

vazricv commented Apr 4, 2023

this article help me to figure out the issue and the issue got fixed by using the full url
https://dev.to/jwp/signalr-client-connection-internals-5a2p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
more-info-needed We are currently waiting for a response. No further triage action is needed at this time.
Projects
None yet
Development

No branches or pull requests

6 participants