I am using the SignalR silverlight client and my hubs are hosted in the windows services. Hubs talk to the compact database to return the data.
What i have noticed is, the time taken to return the data is alarmingly high even though the volume of data returned is not significant and also since the hubs server is local, do not see any network latency issues as well.
I want to know, what are the performance improvements/configurations that can be done at the SignalR hub level in order to improve the performance?
eg:
Is there any standard Transport channel that I should use depending on the client type?
Are there any configuration parameters that i should set?
Thanks,
Alpee
As far as I understand, SignalR uses fallback protocols so it would depend on the capabilities of your server and client.
You might want to take a look to this for further abstract
Moreover, there are some performance recommendations (only related to IIS and SignalR together) in the main project wiki
I would recommend you to use Performance Counters (check "Generating Client Load with crank" section) to better diagnose where is your performance issue.
Hope that helps,
Cheers
Related
I want to create a web app using React as the front end technology. A requirement for the app is that the server will be able to update all the clients with information about changes (not have to be an exact real time, but should update after no more than 10 seconds).
Solutions like clients requesting updates from the server every several seconds are out of the question.
Requirements:
1) The server's should be implemented with either .NET or with Node.js.
2) The connection MUST be secured via port 443 of the IIS.
I read a bit about Micorsoft's SignalR and about Pusher Channels which seems to provide exactly the kind of service I require.
Could you please elaborate about what exactly are the differences between them? When should I choose each? Which of them got more community support? Which is easier to implement? Stuff like that...
Both SignalR and Pusher Channels ultimately both use websockets to deliver messages to clients, so both should meet your requirements to deliver messages to clients in realtime.
1) Both offerings also meet your requirements for both library support:
SignalR supports .NET:
https://dotnet.microsoft.com/apps/aspnet/signalr
Pusher Channels has server support for both nodejs and .NET:
https://github.com/pusher/pusher-http-node
https://github.com/pusher/pusher-http-dotnet
2) Both offerings also meet your requirements for sending messages over TLS/WSS:
SignalR:
https://kimsereyblog.blogspot.com/2018/07/signalr-with-asp-net-core.html
Pusher Channels:
Securing Pusher's messages
In terms of the differences between them this depends on your implementation, if you just run SignalR on your own ISS server then it will be down to you to manage all of the websocket connections and all of the scaling challenges that come with this.
However similar to how Channels works, SignalR also has a managed websocket service, so you do not need to manage the connections or scaling. You just make an API request with the message you want to send to either Channels or SignalR and this message is then broadcast to the interested clients connected by websockets. In this scenario you do not manage the websocket connections yourself.
However in terms of pricing Channels appears to be far more competitive (especially the free offering), so if you are looking at the managed offering Channels looks to be a better value proposition:
https://azure.microsoft.com/en-gb/pricing/details/signalr-service/
https://pusher.com/channels/pricing
Both offerings look fairly similar in terms of implementation (assuming you are using the managed service). The complexity would increase if you implement SignalR on ISS:
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-2.2
In terms of support Pusher has a free application support offering:
https://support.pusher.com/hc/en-us
Hope this helps!
This presentation has some answers A 10 Minute Guide to Choosing a Realtime Framework
I want to create a program for my desktop and an app for my android. Both of them will do the same, just on those different devices. They will be something like personal assistants, so I want to put a lot of data into them ( for example contacts, notes and a huge lot of other stuff). All of this data should be saved on a server (at least for the beginning I will use my own Ubuntu server at home).
For the android app I will obviously use java and the database on the server will be a MySQL database, because that's the database I have used for everything. The Windows program will most likely be written in of these languages: Java, C#c C++, as these are the languages I am able to use quite well.
Now to the problem/question: The server should have a good backend which will be communicating with the apps/programs and read/write data in the database, manage the users and all that stuff. But I am not sure how I should approach programming the backend and the "network communication" itself. I would really like to have some relatively easy way to send secured messages between server and clients, but I have no experience in that matter. I do have programming experience in general, but not with backend and network programming.
side notes:
I would like to "scale big". At first this system will only be used by me, but it may be opened to more people or even sold.
Also I would really like to a (partly) self programmed backend on the server, because I could very well use this for a lot of other stuff, like some automation features in my house, which will be implemented.
EDIT: I would like to be able to scale big. I don't need support for hundreds of people at the beginning ;)
You need to research Socket programming. They provide relatively easy, secured network communication. Essentially, you will create some sort of connection or socket listener on your server. The clients will create Sockets, initialize them to connect to a certain IP address and port number, and then connect. Once the server receives these connections, the server creates a Socket for that specific connection, and the two sockets can communicate back and forth.
If you want your server to be able to handle multiple clients, I suggest creating a new Thread every time the server receives a connection, and that Thread will be dedicated to that specific client connection. Having a multi-threaded server where each client has its own dedicated Thread is a good starting point for an efficient server.
Here are some good C# examples of Socket clients and servers: https://msdn.microsoft.com/en-us/library/w89fhyex(v=vs.110).aspx
As a side note, you can also write Android apps in C# with Xamarin. If you did your desktop program and Android app both in C#, you'd be able to write most of the code once and share it between the two apps easily.
I suggest you start learning socket programming by creating very simple client and server applications in order to grasp how they will be communicating in your larger project. Once you can grasp the communication procedures well enough, start designing your larger project.
But I am not sure how I should approach programming the backend and
the "network communication" itself.
Traditionally, a server for your case would be a web server exposing REST API (JSON). All clients need to do http requests and render/parse JSON. REST API is mapped to database calls and exposes some data model. If it was in Java, it would be Jetty web server, Jackson Json parser.
I would really like to have some relatively easy way to send secured
messages between server and clients,
Sending HTTP requests probably the easiest way to communicate with a service. Having it secured is a matter of enabling HTTPS on the server side and implementing some user access authentication and action authorization. Enabling HTTPS with Jetty for Java will require few lines of code. Authentication is usually done via OAuth2 technique, and authorization could be based on ACL. You may go beyond of this and enable encryption of data at rest and employ other practices.
I would like to "scale big". At first this system will only be used by
me, but it may be opened to more people or even sold.
I would like to be able to scale big. I don't need support for
hundreds of people at the beginning
I anticipate scalability can become the main challenge. Depending on how far you want to scale, you may need to go to distributed (Big Data) databases and distributed serving and messaging layers.
Also I would really like to a (partly) self programmed backend on the
server, because I could very well use this for a lot of other stuff,
like some automation features in my house, which will be implemented.
I am not sure what you mean self-programmed. Usually a backend encapsulates some application specific business logic.
It could be a piece of logic between your database and http transport layer.
In more complicated scenario your logic can be put into asynchronous service behind the backend, so the service can do it's job without blocking clients' requests.
And in the most (probably) complicated scenario your backend may do machine learning (for example, if you would like you software stack to learn your home-being habits and automate house accordingly to your expectations without actually coding this automation)
but I have no experience in that matter. I do have programming
experience in general, but not with backend and network programming.
If you can code, writing a backend is not very hard problem. There are a lot of resources. However, you would need time (or money) to learn and to do it, what may distract you from the development of your applications or you may enjoy it.
The alternative to in-house developed of a backend could be a Backend-as-a-Service (BaaS) in cloud or on premises. There are number of product in this market. BaaS will allow you to eliminate the development of the backend entirely (or close to this). At minimum it should do:
REST API to data storage with configurable data model,
security,
scalability,
custom business-logic
Disclaimer: I am a member of webintrinsics.io team, which is a Backend-as-a-Service. Check our website and contact if you need to, we will be able to work with you and help you either with BaaS or with guiding you towards some useful resources.
Good luck with your work!
I am new to SignalR and I try to understand the difference between consistent connection and long polling,Is there different use in methods ? is one better than the other? are there any diffrenet functions need to polling and other functions to use consistent connection?, I googled but didn't find a simple answer to this question, can someone help? need an explanation.
SignalR is a framework that allows us to build real-time web applications. Ideally, we would use web sockets for this. However, web sockets is a new protocol and requires support from both the browser and the server. Thus, web sockets are not generally available and SignalR tries to provide an abstract connection similar to web sockets but built upon existing technologies and techniques. This abstraction is called a Persistent Connection.
Persistent connection is the term used to describe SignalR's abstract connections.
Long polling is one of several techniques used to implement SignalR's persistent connections (the others are Forever Frame, Server-Sent Events and Web Sockets).
It's seems to me that SignalR is only temporary step towards global domination of System.Web.WebSocket, and it's lower level System.Net.WebSocket.
If I have IIS8, and my clients have IE10, do I have any reason to use signalR?
Does it have a future?
(Of course, the same goes for Socket.IO + Node.js)
Thanks
ref:
http://pieterderycke.wordpress.com/2012/07/20/websockets-vs-signalr-or-why-you-should-not-have-to-care/
A number of advantages:
SignalR abstracts the actual connection type away so that you only deal with a logical connection. The advantage is that you can switch to other connection types if you want to without having to change your code (SSE might actually provide better performance than WebSockets in some cases).
You get the fallback options (long-polling etc.) for free in case you need to connect from a client that doesn't support WebSockets.
Hubs provide a level of organization (you can do that yourself, of course, but it's a good starting point, and it's convenient)
SignalR provides a rich API for calling a specific client, a group of clients, all clients (including the ability to exclude certain clients). Again, you can implement it yourself, so this is mostly about convenience.
You can pass strongly typed parameters between client and server (both ways).
You'll (probably) have to deal with less boilerplate code with SignalR.
Scale-out support
Off the top of my head, the group membership/broadcast and the ability to scale out on a webfarm are features that you don't get built into the WebSockets classes - so if you're using those features, you'll probably continue to use SignalR for the near future.
Additional to Damien's points:
SignalR also supports long polling and some other techniques if the user has no browser with web socket support
It's very easy to call methods on the client from the server
Also, when WebSockets is updated, SignalR will also be updated, so you won't need to worry about coding for the new version of WebSockets.
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck