Currently I have an application in which a user stares at a dashboard, the dashboard will display new orders coming in for that user. I have rolled out the application for testing and most users are complaining of time delays and crahsing.
Currently I am using jQuery and Ajax using setInterval() and then an Ajax call to get the orders and update the screen every 30 seconds. However in some instances where there are a lot of orders the Ajax calls become overlapped.
I have stumbled across a new technology to me which seems like the solution SignalR but I have looked at the examples and have not seen any comments on performance.
Question - What is the performance like and would it be a better solution to the current above, also is it possible to configure this to target only a specific user and can this be done to the current logged in user's ID? I am using MVC4.
Any comments would be appreciated,
Thanks
You can use SignalR to send messages to a specific client/user. Take a look at the documentation here to find out more about this: https://github.com/SignalR/SignalR/wiki. SignalR allows you to make remote procedure calls (RPC's) from the client and the server and you should be able to push any notifications/new orders to the client almost immediately.
There aren't any published performance metrics for SignalR as yet but you can test it out to see how efficiently your traffic is handled.
Related
I realise this question has been asked in different variations but with newer features to .net (e.g. async await) I wonder what solution is the best.
I have a C# .Net Web Forms app that has a long running task: The task handles a user request where they upload a csv data file, serialises into object, and imports to a database. The task can take a few minutes and the browser regularly times out - this causes usability issues.
I have seen many solutions whereas the user will upload the data and then the task is carried out in the background. The page will then call the server intermittently to request the status of the task, thus keeping the user informed of the progress.
I would like to know how this is achieved? The options I see on the table:
Windows Service
Web Service - how is this hosted: IIS or a windows service?
Async, Await - is this a possibility?
I think you could take two different approaches.
The first would be a pull approach, you would be keeping the state of the process per user in the server, perhaps in session, and having the process update that state, then the client can pull the actual state via ajax regularly. The ajax call is made from the client's browser, and the function can be put in the same web page that the client is viewing, there's no need to separate it if it's going to be used only from there.
The second could be a push approach, which is a bit more complex but gives you other possibilities. You would need to use a library like signalr https://www.asp.net/signalr, that allows you to communicate from the server to the client's browser, call JS functions, and push the updated state to the client's form. That could create a more functional two-way communication and a better user experience in exchange of a bit more complexity.
I'm learning basic web application development using Microsoft WebAPI. I've created a drinks ordering service where users order drinks, post it to the server, and the server stores them for later.
Users post their order to a RESTful endpoint on an OrdersController. The endpoint stores the order in a list and checks the list against a condition. E.g, "Are number of orders > 5?"). If satisfied, the server sends a push notification to the users' mobile phones using the Google Cloud Messaging service.
I wish to expand the type of conditions that could trigger a push message. For example, "If no orders have been received in the last 5 minutes, send a push notification". In other words, I would need to check the condition more often than just in response to receiving a new order request.
What is the best way to accomplish this? My initial thought was just to create a Timer which runs the condition checking method at intervals, but a search of stack overflow has suggested that this kind of approach might be a bad idea.
I have several ideas depending on the hosting environment:
If it's your server (virtual or otherwise)
Create a seperate application that runs as a windows service or a windows application that handles that process seperately from the webAPI.
If running on Azure as a Cloud Application you can create a web worker role that is scheduled to run every so many minutes and could then query and process items.
If you only have a hosting enviornment for MVC/WebAPI then you could look into the cache/callback trick. You basically add an entry to the cache when a callback to a method.
a. Create a controller method that adds a cache entry with a callback to a method
b. The method does whatever work it need to do then calls the controller action so another entry is placed in the cache.
Each time the cache times out, it calls the callback method which you can use to process information and then call the controller method to start the process over again.
When I was experimenting with this, I created a small scheduling project that looped through a list of tasks. Each task was responsible for determing if they any processing was needed. Amazingly enough it worked well and the server never shuts down the process.
Keep in mind if your hosting in the cloud that this will simulate activity and memory usage which could cost you some amount of money, although I would think it would be trival.
I've heard they are scheduling solutions, possible even a monitoring service that can call a WebAPI endpoint every so many minutes which could work much like the callback method. You could check for the need to process each time the monitoring service calls the endpoint.
You can use Reactive Extensions: it lets you program time-related events in a declarative manner without having to bother with handling timeouts and tracking. You can even test your setup by controlling time itself!
For example, to trigger an event after some inactivity, you could use the Timeout method of an observable. The Buffer method can let group trigger an event after x drinks have been ordered, etc
In general what you describe sounds like a backend task/responsibility. You can consider this library HangFire.io to safely perform this operation from ASP.NET - http://hangfire.io/
The other way you could simulate event firing from with ASP.NET for simple one-off cases is , is you can you can use the built-in cache and its expiration event.
I have been using SignalR in my mvc4 asp.net application in order to update Views and have real Time aspect without having to get back to database each time to check states.
The code I integrated in my web api controller and views is working perfectly while debugging. However, I usually get cases where no refresh take place.
I can't seem to figure out the reasons behind such behaviour ( sometimes it works instantly and others not ). I have been relating it to internet connection problems but it seems that it isn't the only fact.
Any ideas or reflexions to keep in mind while using SignalR ?
check for following
Maximum concurrent requests per CPU
Request queue limit
Maximum requests per application
DefaultMessageBufferSize
one of these may be blocking the request.
Reference: http://www.asp.net/signalr/overview/signalr-20/performance-and-scaling/signalr-performance
A client came to me with a request to have a web app that does a lot of processing in the backend (reads from a file, writes to a web service). My question is that since this "process" (when the user clicks 'Go') may take hours, how do I make it so the processing continues after the user closes the web page? Please let me know if this does not make any sense and I can give more information. Any help would be greatly appreciated, thanks!
You have to create MS Windows Service for it.
You have provide for that Service some database table which client is going to use by your Website functionality.
This is, basically, a "batch job" requirement, and that's how I suggest that you approach it.
The client would use the web-page, not to perform the work, but rather to manage the list of batch jobs that are performing the work .. scheduling them, starting or stopping them, viewing their status and current output, and so on. (Yup, just like they did it in the 1970's, but without "//FOOBAR JOB (123,456)" ... thank god.
The user goes to the web-page and enters a request. A back-end service process on the host (the batch job manager...) now starts the job, perhaps on one computer; perhaps on several at a time. The user can, meanwhile, log off the web-site and do whatever he pleases. Then, he can come back at any time, go back to whatever the job-monitoring web page may be, and see how things are going. Stop the job, suspend/resume, what have you.
There are lots of batch-job monitoring tools out there already, for all sorts of environments, both free and commercial. So, it's not like you have to build all this stuff; you merely have to identify what off-the-shelf package works best for you and for your client.
The best possible solution will be to do the work in a windows service, and use your web app just to trigger the processing.
I'm writing a video cms and want all my users to have new assets displayed immediately as they come in.
If I'm right, facebook updates its wall-page in realtime. So when I post something to a friend it immediately displays on his wall. The realtime web, as they say.
I wonder how you do that? Not the technology of client-server-communication, but what goes on on the server.
I understand the principles of the observer-pattern.
But a wall is in fact a query on a table of messages.
How does the observer know what query a user is interested in?
Does it hold all the query's of all connected users and reruns it when something new comes in.
I believe Google-realtime works that way to.
Thank you for helping me out.
When you open facebook, open the script timeline in your browser to see what scripts are executing on the page. You'll notice that there is a polling script being executed several times a second. So the page is looking at the cache several times a second to see if there is any new information that can be displayed.
http://www.ajaxwith.com/Poll-vs-Push-Technology.html - this should give you a background on the subject.
Facebook uses AJAX and a JavaScript timer that polls in the background looking for anything that's changed. Other sites use the same type of functionality to update stock quotes embedded in the page, etc. It's not truly updating immediately, it's updating as frequently as the JavaScript timer hits their server. This is because web browsers use HTTP, which is a request/response protocol. A browser won't display anything that's not as a direct response to a request initiated by the browser; there's no way to just send content directly to the browser from your webserver.