This project has moved. For the latest updates, please go here.

SqlDatabaseTraclistener performance enhancements

Jul 25, 2011 at 11:40 AM

Hi,

From the source code:

                // TODO: Would it be more efficient to create command & params once, then set value & reuse?
                // (But would need to synchronise threading)
                // TODO: Alternatively, implement buffering (and Flush()), maybe with a bulk copy operation?

I'm all for the buffering/SqlBulkCopy  approach, as it is easy to make threadsafe with a generic list or stack.

Extra attributes in the config file could be used for configuring flushing tresholds (time and/or number of entries on the stack).

The current logic could be used when "autoflush=true" is set.

SqlBulkCopy would make inserting in the database an order of magnitude faster (depending on the number of rows in each batch).

What do you think?

Danny

Coordinator
Jul 26, 2011 at 2:01 PM

I would actually want to set up some performance testing before heading down any particular optimisation path.

In fact, at some point on the plan is general performance stats across different logging frameworks (System.Diagnostics, log4net, NLog, etc) to compare in different situations, e.g. with logging turned off, etc.

The idea would be to then reuse this, or something similar, for optimising listeners.

Do you actually have a need for improving the performance of the database logging? (I'm not sure what volume of logging you are looking at.)

 

Jul 27, 2011 at 8:24 AM

I don't have a pressing need for better performance right now, but I expect this will change. 

And since buffered tracing is supported by the standard textwriter listener in the framework for performance reasons I thought it wouldn't be a bad idea to do the same for the database listener, especially as the existence of SqlBulkCopy makes it an easy option to add.