logging application requests

Question

I have several web services that logged-in user interact with. Currently they're running on ASMX but pending an upgrade to WCF. I'm going to write a logger that tracks the name of the request, the user ID, the parameters, the time processing time, if there was an error and a few other things. I'm thinking of something like this:

public class MyWebService : System.Web.Services.Webservice
{
    MyAppLogger TheAppLogger = new MyAppLogger();

    [WebMethod(EnableSession = true)]
    public string SomeWebService(string SomeParameters)
    {
         TheAppLogger.StartLogging();
         TheJsonStringToReturn = "";

         try
         {
            //do something that populates TheJsonStringToReturn
         }
         catch
         {
             TheAppLogger.LogException();
         }

         TheAppLogger.LogRequest();

         return TheJsonStringToReturn;
    }
}

My question is this: if I go with what I just described, the LogRequest() method would store the request in the DB before the request is complete. Is that going to be performance problem? How would I change this code so that the database write would happen AFTER the request is responded to?

Thanks for your suggestions.

Why do you think that LogRequest would execute before the `//do something` finishes? — NotMe, Oct 25 '12 at 00:17
From the return statement forward, the times are going to vary wildly due to network performance of both the client and server for similar requests. Are you sure that's what you really want? If so, you are better off having some type of javascript or whatever on the client side to record that. That information is rarely useful. — NotMe, Oct 25 '12 at 00:29

score 0 · Accepted Answer · edited May 23 '17 at 12:27

0

You have a few options - queuing, asynchronous processing, spawning a worker thread, etc. See this post for a few good answers:

doing database write after the response

edited May 23 '17 at 12:27

Community

1
1

answered Oct 25 '12 at 00:43

Craig Koster

496
5
15

Also just as a note - your insert to the DB will probably only be problematic performance-wise if the table you're writing to has one or more indexes and/or the service has *extremely* high traffic. – Craig Koster Oct 25 '12 at 00:45
2

Another point - in the interest of avoiding the re-invention of the wheel - there is WCF tracing available out of the box so if it fits the bill it might save you some work trying to roll your own: http://stackoverflow.com/questions/4271517/how-to-turn-on-wcf-tracing – Craig Koster Oct 25 '12 at 00:48
I think the tracing route is probably best for what the OP is doing. It appears that the only reason to do the write after the response is done is to ensure it captures the time spent actually writing the data back to the client. – NotMe Oct 25 '12 at 01:07

logging application requests

1 Answers1