SignalR sucks
-
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery :mad: Are we the only ones having these problems ? We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
-
Just a wild stab in the dark, but is Symantec Endpoint Protection involved in the equation?
I wanna be a eunuchs developer! Pass me a bread knife!
Good one, we'll check that !
-
What version of SignalR are you using, i.e. .net framework or .net core? BTW, they never tell you that if SignalR is on a port, in production, it's likely the firewall will block you at most companies.
I know they are using self hosted .NET Core SignalR and maybe .NET too ... Microsoft.AspNet.SignalR.Core.dll 2.2.6
-
did u enable trace log..
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
Yes, but we did not get any wiser, that is the most frustrating thing about SignalR: you don't have a clue what is going on :sigh:
-
Pretty much anything of that sort is created by architecture astronauts and will not fullfil any particular need.
PIEBALDconsult wrote:
architecture astronauts
This is priceless. Will be reused.
-
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery :mad: Are we the only ones having these problems ? We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
Are you using the .NET Full Framework or the .NET core? I only started with .NET core 2.1 and built distributed batch processing work queue and it's working fine and even has good performance, tested crossplatform and scaled on aws cloud without problems. I did experiment with large messages (10MB) but (de)serialization performance caused me to stick to small packets and strip of unnecessary data.
-
Are you using the .NET Full Framework or the .NET core? I only started with .NET core 2.1 and built distributed batch processing work queue and it's working fine and even has good performance, tested crossplatform and scaled on aws cloud without problems. I did experiment with large messages (10MB) but (de)serialization performance caused me to stick to small packets and strip of unnecessary data.
The problems are mainly with .NET Core SignalR. Large messages is not what SignalR is meant for, and we only use small messages.
-
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery :mad: Are we the only ones having these problems ? We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
have you looked at ServiceStack Server Events. as an alternative to SignalR?
Over..
-
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery :mad: Are we the only ones having these problems ? We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
As Sander Rossel and Scott Serl pointed out, SignalR's goal is not to be a message queue service. The fact that you can use it as one does not mean you should.
Paulo Gomes Measuring programming progress by lines of code is like measuring aircraft building progress by weight. —Bill Gates Everything should be made as simple as possible, but not simpler. —Albert Einstein
-
Yes, but we did not get any wiser, that is the most frustrating thing about SignalR: you don't have a clue what is going on :sigh:
these kind of things may need some investigation and thought..also configuration management..like what is the difference between the development and production environments ? is there a firewall..are the ports enabled... is there dpi ssl filtering ...packet inspection.... is there some timeouts that are causing connections to drop...latency...is there firewall or av on the production.. any lockdowns... are the pipes open properly...https://forums.asp.net/t/2096572.aspx?why+signalr+so+slow.... https://docs.microsoft.com/en-us/aspnet/signalr/overview/testing-and-debugging/enabling-signalr-tracing
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
have you looked at ServiceStack Server Events. as an alternative to SignalR?
Over..
Thanks for the tip, I will have a look at it !
-
PIEBALDconsult wrote:
architecture astronauts
This is priceless. Will be reused.
Apparently Joel Spolsky coined it. Look it up.
-
Apparently Joel Spolsky coined it. Look it up.
-
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery :mad: Are we the only ones having these problems ? We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
I have found that disabling all the fallbacks and forcing SignalR to use websockets makes a huge difference. Also if you are using nginx there is a config setting that limits the number of connections to 300 that you need to bump up. Also I am not sure in what capacity you are using SignalR, but you might want to check out the below library (disclaimer: I'm the author) Entity Signal - Real Time Entity Framework (EF) and ASP.NET core[^]
-
I'm always interested in talking about "WebSocket" technology. I'm using Firebase in a project right now and I've created a firebase example you may find interesting. Here is the most simple example where you can move a game pawn in your browser window and see it move (across the Internet) in the other person's browser. pawns[^] I also wrote up an article on SignalR, but unfortunately it is using a little older version of SignalR : Beginner's Guide to Using SignalR via ASP.NET[^] Possible Way To Test? You may like to open the browser on a few different devices and try it out to see if you see the same problems you are seeing in your app. If you see the problems it may be the firewall or network you are on. Here's a direct link to the SignalR one you can try: pawns[^] It's a weird URL but that is because I wrote it a while back and the URL that it is coded up with is very important in the over all project. It's just anonymous link to my web site: raddev.us You can test simply by moving a game pawn around and seeing it move in other browsers. Open up a few browser windows and try it out and let me know.
That is very cool!
-
That is very cool!
-
Thanks I really appreciate that. :thumbsup: SignalR and WebSocket tech is really interesting, but SignalR can be quite confusing to work with -- challenges with auth and security, etc. and getting it to work when deployed.
It sounds to me like another MS com tool that requires a lot of configuration and is too easy to break: WCF. When it works it works great, but when it doesn't it's very stubborn about it!
-
That looked good to me too, and also NATS (especially with future Docker microservices development in mind), but one of my colleagues already beat me to it with a Proof of Concept using ZeroMQ before I could even start a discussion about it, guess I'm getting too old and slow :sigh: And I must say, the more I read about ZeroMQ the more enthousiastic I get, it's even developed by a Dutch guy !
ZeroMQ's fine - I've used it in some projects at work. I've always got the feeling that Martin Sustrik (who then went on to start [nanomsg](https://nanomsg.org/) - another lightweight messaging system) was the main man in the development, until him and Hintjens had a falling out... Main difference between ZeroMQ & other messaging systems is the lack of a separate broker server, which is an advantage for some use cases (it was for the one we had), but probably not for others. Being able to support messaging between & within processes (where in-process messaging uses a different, more efficient transport) was also a plus point for us. We only use the REQ-REP setup, but PUB-SUB (for data distribution) is also on the cards for future developments. We layered [Protocol Buffers](https://developers.google.com/protocol-buffers/) on top, to provide message structure. That also worked well.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
ZeroMQ's fine - I've used it in some projects at work. I've always got the feeling that Martin Sustrik (who then went on to start [nanomsg](https://nanomsg.org/) - another lightweight messaging system) was the main man in the development, until him and Hintjens had a falling out... Main difference between ZeroMQ & other messaging systems is the lack of a separate broker server, which is an advantage for some use cases (it was for the one we had), but probably not for others. Being able to support messaging between & within processes (where in-process messaging uses a different, more efficient transport) was also a plus point for us. We only use the REQ-REP setup, but PUB-SUB (for data distribution) is also on the cards for future developments. We layered [Protocol Buffers](https://developers.google.com/protocol-buffers/) on top, to provide message structure. That also worked well.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Thanks, useful information !