We have a ASP.NET web app that needs to display data in real time or as best s and we are currently using AJAX and web services but this causes performance issues because number of clients is getting bigger and bigger. Data is being pooled every 5-10 seconds and when this is multiplies by 1000+ clients it can make data retrieval quite slow.
You might want to try using SignalR to handle your real-time data needs. From the site:
ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is "real-time web" functionality? It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.
You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.
Try one or more of the following:
Caching – can you consider store your application data in memory for some time. That will reduce the impact on the database server.
HTML 5 Server Side events – Using Server Side Events you can actually notify clients (push data instead of pooling) when change happens. You would essentially need one ASP.NET event handler (ashx page) that pushes requests and some JS code on the client side.
Check out this article for more details and code examples on Server Side Events.
Related
I'm trying to create a new application from the ground up. I've used SignalR and WebAPI. I believe I know a lot of the differences, but isn't SignalR faster since it uses websockets? WebAPI makes sense to me for external frameworks to be able to reuse. SignalR makes sense to me for anything I'm not necessarily going to use externally. I've done some research and I can't find anywhere it says you shouldn't. I realize this is somewhat opinion-based, but why would you use a mix of the two rather than just SignalR?
I think what I'm mostly asking is if it is wrong to use SignalR to send back to the caller, except in cases where I would send to other clients on that channel? To me SignalR can be used like WebAPI when you are just sending back to the client. Is that wrong to do? It is less code for the client calls(2 lines vs 6 or more, depending on what I'm doing with it). My thinking is I may be trying to manipulate data and send it to the caller now, but maybe I want to send it to all clients later or send a notification to all clients. I'm not a fan of using signalR calls in my webApi controllers. It just feels like the signalR calls should be in the Hub. Thanks for your help.
There is no reason why you shouldn't use them together because they target two different problems. Web-API is a means of making web services easy to target by many different kind of apps/devices whereas SignalR offers bi-directional communications in a way that the Server can call a piece of code on the client without the client having to keep polling the server for results.
E.g. Instead of having a client keep asking the Server for any new messages (like facebook notifications) with SignalR the server knows that there are new notifications for a specific client and it can send them directly without the client having to ask for them.
http://www.asp.net/web-api
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://www.asp.net/signalr
ASP.NET SignalR is a new library for ASP.NET developers that makes
developing real-time web functionality easy. SignalR allows
bi-directional communication between server and client. Servers can
now push content to connected clients instantly as it becomes
available. SignalR supports Web Sockets, and falls back to other
compatible techniques for older browsers. SignalR includes APIs for
connection management (for instance, connect and disconnect events),
grouping connections, and authorization.
A potential problem is that while SignalR is great at targeting JavaScript code on a client, Web-Api enables connectivity with all sorts of platforms and devices. So the same techniques used through SignalR to target Web Browsers, will not necessarily work on a native Android App.
You can use them together depending on your application needs. I recommend you look at difference between HTTP and WebSockets protocols. WebApi uses HTTP(S), SignalR mostly WebSockets and in some cases others transports. They both have benefits and disadvantages. The main benefits of using SignalR are duplex bidirectional communication as mentioned above and low traffic overheads. Browsers send as a rule a few KB data in HTTP headers and cookies for every request.
It’s easier to use RESTfull services (HTTP) from browsers, HTTP clients, tools, languages and so on instead of using WebSockets. Google Chrome supports monitoring WebSockets traffic but very poorly and Microsoft Edge doesn’t.
Many tools like Google Analytics and Microsoft Azure Application Insights can monitor errors in HTTP requests but can’t do this for WebSockets. You need to implement monitoring manually. Actually WebSockets traffic is simple messages from client to server and vise versa, no additional information. SignalR has some wrappers for this - some kind of error message format.
WebSockets also use more server resources because of keeping open TCP connection and it’s harder to scale web applications that use WebSockets. For instance if you have 100K online users it means you have to be able to keep 100K TCP connections. For HTTP – not necessary. For some very simple sceneries you can replace SignalR with some kind of client polling, but be careful that’s approach may bring a lot of problems.
So, If you don’t need bidirectional communication and traffic overhead (as a rule a few KB per request) is not a big deal then use WebApi only.
If you need bidirectional communication you can use SignalR for server to client push notifications and WebApi for client to server requests simply to ease development, scaling, debugging and using API from other sources. But you also can use SignalR only if you are ok with disadvantages of it or traffic overhead is big for you.
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
I have a web service which is completely build using .net C#. Now I want to use either signalR or Node JS so that if web service has some update it can push it to client which is in html javascript.
Design Consideration:
I am running my web service on IIS.
Client in Html javascript
Number of user may be high. May be 100 or 200
There will be frequent updates for long period of time from web service.
Web service does DB call and little calculation
Server specification is not an issue.
Need stability and security in the web service
If you are already using the Microsoft stack (.NET, C#, IIS) on your back end then it would make sense to use SignalR because it will integrate nicely with your existing stack.
You already have development experience in C#, do you have experience in NodeJS too? If not then that's a big point to consider as there will be a learning period where you become accustomed to the Node way of programming javascript.
100-200 users isn't that many for either NodeJS or SignalR. SignalR uses some of the async features of .NET and so a thread won't be used by an open connection until something is ready to happen (e.g you might be waiting on DB IO). Similarly, all IO in node should be done asynchronously.
If you're using SQL server then you might find using SignalR opens up other possibilities, e.g using Entity Framework to improve productivity and get your product to market faster.
As for stability and security, those are often dependent on the way you design, write and configure your application rather than the technology stack itself.
Edit: A couple of resources for getting started in the respective technologies that I've found helpful in the past:
SignalR
NodeJS
How to refresh aspx page from sql server.I am using asp.net,C-Sharp with SQL Server 2008.What i mean is i have table, say Table1.If any DML operation is performed (Update,Insert etc) to Table1,then my page,say Page1.aspx should autmatically get refreshed.I can't use timer for refreshing the page.I need to trigger the refresh from database.
Even though the server may be notified when data has changed, the real challenge is communicating those changes to the client in real-time without requiring a timer or user interaction.
You have a couple of options:
Your best bet is to use a WebSocket, which enables bidirectional communication between the client and server. This is the solution I would pick.
Here are some examples using WebSockets:
Building real-time web apps with WebSockets using IIS, ASP.NET and WCF
HTML5 C# WebSockets Server and ASP.NET Client Implementation
C# WebSocket Server
WebSockets in ASP.NET 4.5
WebHooks and WebSockets in ASP.NET
There are a few good libraries around too that will take care of most of the leg work. A couple to check out are WebSync and PokeIn. Both products offer decent documentation and community editions that you can download for free.
Here are some tutorials to check out:
WebSync Tutorials
PokeIn Basic Tutorial / PokeIn Advanced Tutorial
Use AJAX to poll for changes every X number of seconds. If changes are detected reload the page, otherwise do nothing.
You probably want to look into the SqlDependency object. This object will notify you of changes to a specified database query in real time. When your application receives a message from the database, you can simply refresh the page in your code-behind.
I wonder if you could adapt SignalR to send a message to the client to prompt a refresh?
This tutorial could get you started.
I'm working with an n-Tier application using WinForm and WCF
Engine Service (Windows Service) => WCF Service => Windows Form Client Application
The problem is that the WinForm Client Application need to be 100% available for work even if Engine Service is down.
So how can I make a disconnected architecture in order to make my winform application always available ?
Thanks.
Typically you implement a queue that's internal to your application.
The queue will forward the requests to the web service. In the event the web service is down, it stays queued. The queue mechanism should check every so often to see if the web service is alive, and when it is then forward everything it has stored up.
Alternatively, you can go direct to the web service, then simply post it to the queue in the event of initial failure. However, the queue will still need to check on the web service every so often.
EDIT:
Just to clarify, yes all of the business logic would need to be available client side. Otherwise you would need to provide a "verify" mechanism when the client connects back up.
However, this isn't a bad thing. As you should be placing the business logic in it's own assembly(ies) anyway.
Have a look at Smart Client Factory: http://msdn.microsoft.com/en-us/library/aa480482.aspx
Just to highlight the goals (this is sniped from the above link):
They have a rich user interface that
takes advantage of the power of the
Microsoft Windows desktop.
They connect to multiple back-end
systems to exchange data with them.
They present information coming from
multiple and diverse sources through
an integrated user interface, so the
data looks like it came from one
back-end system.
They take advantage of local storage
and processing resources to enable
operation during periods of no
network connectivity or intermittent
network connectivity.
They are easily deployed and
configured.
Edit
I'm going ansewr this with the usual CYA statement of it really depends. Let me give you some examples. Take an application which will watch the filesystem for files to be generated in any number of different formats (DB2, Flatfile, xml). The application will then import the files, displaying to the user a unified view of the document. And allow him to place e-commerce orders.
In this app, you could choose to detect the files zip them up and upload to the server do the transforms (applying business logic like normalization of data etc). But then what happens if the internet connection is down. Now the user has to wait for his connection before he can place his e-Commerce order.
A better solution would be to run the business rules in the client transforming the files. Now let's say, you had some business logic which would based on the order determine additional rules such as a salesman to route it to or pricing discounts...These might make sense to sit on the server.
The question you will need to ask is what functionality do I need to make my application function when the server is not there. Anything thing which falls within this category will need to be client side.
I've also never used Click Once deployment we had to roll our own updater which is a tale for another thread, but you should be able to send down updates preety easily. You could also code your business logic in an assembly, that you load from a URL, so while it runs client side it can be updated easily.
You can do all your processing off line, and use some thing like Microsoft Sync Framework to sync the data between the client and the server.
Assuming both server and client are .net, you can use same code base to do the data validation both on the server and the client. This way you will have a single code base that will serve both server and client.
You can use frameworks like CSLA.NET to simplify this validation process.