I am using WebApi with Entity Framework to implement a REST service. I need to log the usage to the database. I can do this in the controller before it returns or in an ActionFilterAttribute. I want to be able to fire off a call to update the database, BUT I don't want to wait for completion. I want the response to return to the user without waiting for the update.
I was thinking about using a BackgroundWorker and passing in the objects.
Anyone have thoughts on if this is the good way to do this?
I think the question you should ask yourself is how much latency the database update can add to your overall response time. In most cases, it will be a lot simple to do the update as part of the request processing. Background worker is generally not a good solution but here is a good read related to that topic. If you absolutely need to do the database update outside of request processing, it will be better to consider a queueing mechanism like MSMQ, RabbitMQ, etc from the perspective of reliability.
I believe my performance problem is related to running in VS2012 debugger. When running the site directly, performance increased drastically. So I won't need to do any 'tuning tricks' if this proves out when deployed to test server.
Have you tried exploring NLog's async capabilities? We use NLog's async wrappers by wrapping a database logging target like so:
<targets async="true">
<target name="dbLog" xsi:type="Database" dbProvider="sqlserver" connectionString=".." />
.
.
</targets>
A quick startup on logging to MS SQL DB using NLog is found here
Moreover, you could make your logging method call async (.NET 4.5 required) and if you do not care for the result, choose not to await the method execution.
Look at this SO Thread for a sample NLog.config.
Related
I encoutered a question here and need your help.
I had a .net web api project using PushStream to do async downloading, something like
new PushStreamContent(async (outputStream, httpContent, transportContext))=>{}
In this way, I can do multiple parts downloading in the action.
However, now I want to move the project into .net core and I cannot find a replacement in .net core for pushstream.
Could you please let me know is there something like pushstream in .net core or any methods to implement it?
Thanks a lot.
PushStreamContent works by essentially setting a callback to be invoked when the output stream is being processed. This was necessary in ASP.NET Web Api because there was no direct access to OutputStream.
However, in ASP.NET Core, you do have direct access to the output stream via HttpContext.Response.Body. As a result, you can just directly write to that stream without needing something like PushStreamContent.
FWIW, while this can save some server resources, it's actually pretty bad, especially with something like an API. Since you're writing directly to the output stream, the headers are already sent, including the response status code. This means if there's any exception raised while you're writing, there's no opportunity to handle it appropriately. The response is simply aborted, and the client is left hanging with a supposedly "successful" response, and only a partial body. Personally, I would say avoid this practice altogether and take the resource hit. Unless you're streaming gigs of data, any good server setup will have a plentiful amount of RAM to handle what you're doing. Even then, there's probably better methods to handle delivering that data.
I am working in WPF now...here we use Background_Worker,TaskFactory.StartNew functions and async/await.
In web apps I know that we have AJAX, MVC partial views etc.
My question is do we really use above mentioned async methods (Tasks, sync/await) in Web apps ? If we use, could you give me some examples ?
I have a document generation module in my web app in which I have to fetch data from DB and create documents out of it. Is it a good scenario for async calls? (to call the function and throw..and never care about it).
I am working in WPF now...here we use Background_Worker,TaskFactory.StartNew functions and async/await.
You really should be using Task.Run instead of BackgroundWorker and Task.Factory.StartNew. Task.Run has much better defaults than StartNew, and is more composable and type-safe than BackgroundWorker.
My question is do we really use above mentioned async methods (Tasks, sync/await) in Web apps ?
On ASP.NET, you should almost never use your own background threads (BackgroundWorker, StartNew, Task.Run). However, you certainly can use async and await.
If we use, could you give me some examples ? I have a document generation module in my web app in which I have to fetch data from DB and create documents out of it.
Yes, database queries are one example of an I/O-based operation. So is "writing" documents - whether as uploads to cloud storage or to the local file system.
I have an MSDN article on async ASP.NET that you may find useful.
Async is useful any time you have disk/database/network I/O. It allows you to do other things while you wait for the I/O to complete, which can result in significant savings. Async isn't really useful for normal CPU bound operations, because of the increased overhead of making it async.
This holds true in WPF as well web applications.
If you want to see a concrete example, Scott Hanselman has a blog entry entitled The Magic of using Asynchronous Methods in ASP.NET 4.5 plus an important gotcha which you may find very interesting.
I have an asp.net 3.5 web application which generates alot of audit related data. Since that data isn't immediately relevant to the user, I'd like to be able to save it to the MSSQL database asynchronously and let the user go onto the next page without waiting. I'm using Nhibernate as my ORM.
I've looked into PageAsyncTasks and as far as I can tell they simply allow you to perform page operations in parallel, but all operations still have to complete before the page finishes loading. Is there an alternative, fairly lightweight method to have asynchronous processing that will continue on without affecting page load? Is simply spinning up a new thread manually an acceptable process?
You could create a web service within your solution and when your server-side code is finished and ready to move the user on to the next page it could call your web service to do the auditing as a fire and forget type thing.
Not sure if the NHibernate session is threadsafe so if you create a new thread be careful with the context.
Ideally you could use queues and a servicebus to deal with this sort of thing safely and async but that involves architectural changes.
Not sure if this is possible but if the auditing is actually noticeably slowing the UI down maybe you'd be better off to improve that process and keep it synchronous. Either way, good luck.
I have been given a task where it should be possible for a user to pass some information to a database table.
The table should be seen as a queue.
My question is:
Is it possible to execute some code on the webserver asynchronously, so the users can use the website for others tasks meanwhile processing the queue?
Is it possible to use the Thread class and how ?
Look into Asynchronous Pages as a start - it is teh easiest way to do what you describe.
http://msdn.microsoft.com/en-us/magazine/cc163725.aspx
You could use a service bus to get this done. If you feel up to it you could have a look at my open source esb:
http://shuttle.codeplex.com
It has an implementation that can use a sql table as a queue.
We have an application that hits a web service successfully, and the data returned updates our DB. What I'm trying to do is allow the user to continue using other parts of our web app while the web service processes their request and returns the necessary data.
Is this asynchronous processing? I've seen some console app samples on the msdn site, but considering this is a web form using a browser I'm not sure those samples apply. What if the user closes the browser window mid request? Currently we're using the Message Queue which "waits" for the web service to respond then handles the DB update, but we'd really like to get rid of that.
I'm (obviously) new to async requests and could use some help figuring this out. Does anyone have some code samples or pertinent articles I could check out?
Yes, what you're describing is async processing.
The best solution depends to some degree on the nature of the web services call and how you want to handle the results. A few tips that might help:
One approach is to send a request from the initial web request to a background thread. This works best if your users don't need to see the results of the call as soon as it completes.
Another approach is to have your server-side code make an async web services call. This is the way to go if your users do need to see the results. The advantage of an async call on the server side is that it doesn't tie up an ASP.NET worker thread waiting for results (which can seriously impair scalability)
Your server-side code can be structured either as a web page (*.aspx) or a WCF service, depending on what you want to have it return. Both forms support async.
From the client, you can use an async XMLHTTP request (Ajax). That way, you will receive a notification event when the call completes.
Another approach for long-running tasks is to write them to a persistent queue using Service Broker. This works best for things that you'd like users to be able to start and then walk away from and see the results later, with an assurance that the task will be completed.
In case it helps, I cover each of these techniques in detail in my book, along with code examples: Ultra-Fast ASP.NET.
If you're not blocking for a method return you're doing asychronous processing. Have a look at Dino Esposito's article on using AJAX for server task checking.
You can perform asynchronous web service calls using both Web Service Enhancements (WSE) and Windows Communication Foundation (WCF) in your C# code. WSE is discontinued, so its use is not recommended. Generically speaking, if you were to terminate program execution in the middle of an asynchronous call before the response returned, nothing bad would happen; the client would simply not process the result, but the web service would still be able to perform its processing to completion.
If your client web application is responsible for updating the DB, then without anything else in your client code, quitting in the middle of an asynchronous operation would mean that the DB was not updated. However, you could add some code to your client application that prevented the browser from quitting entirely while it is waiting for an asynchronous response while preventing new web service calls from being run after Close is called (using Javascript).
You have 2 distinct communications here: (1) from web browser to web application and (2) from web application to web service.
diagram http://img697.imageshack.us/img697/6713/diagramo.png
There is no point of making (2) asynchronous: you still would have to wait for web service to finish processing request. If you end HTTP request from browser to web application the client would have no clue what the result of request was.
It is much better to make asynchronous request from web browser to your web application. Ajax is ideal for that. In fact, that's what it was created for. Here's couple of links to get you started:
jQuery Ajax
ASP.NET AJAX