0

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?

BCarlson
  • 1,122
  • 2
  • 11
  • 26

3 Answers3

1

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.

0

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.

BCarlson
  • 1,122
  • 2
  • 11
  • 26
0

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.

Community
  • 1
  • 1
Sudhanshu Mishra
  • 6,523
  • 2
  • 59
  • 76
  • when I ran the code outside of Visual Studio, the processing time reduced from 575ms down to 30ms. – BCarlson Oct 07 '13 at 18:05
  • @BCarlson there must be other factors contributing to the improved performance. Some performance gain is expected when you run outside of VS debugger and using optimized (release) build but such significant gain?! – Sudhanshu Mishra Oct 08 '13 at 11:06
  • I suspect there are other factors, things are usually not simple. But running outside VS, it ran in the 30ms range. When I deployed to a test server, still 30ms range. – BCarlson Oct 09 '13 at 19:17