Could be any number of reasons: poor design, no primary key / index,
inefficient use of ADO.NET, not closing connections etc...

I definitely concur with analysing before fixing.

However, it is very likely that a suitably buffered flat file writer will
be faster than committing individual log entries to a database.

Each thread could have its own buffered logger which only flushed to a common
synchronized disk file logger when the buffer is full.
If log entries are timestamped, the ordering of log messages are not important.

Of course, this does run the risk of data loss in case of system failure.

If it is undesirable to have even small waits when flushing to the synchronized
logger, the logger could also be buffered with a separate thread to flush
it to disk.

MSMQ does seem like a bit overkill here, unlesss you really need transactional
support, distribution etc.

XML is not a very suitable format for log files, since they require all content
to be wrapped in a single element. It would, however,
be possible to have a log file containing lots of xml fragments.

Good luck!

Niels

Performance clearly depends on how much data you stick in the app object
before you archive it off.  You'll need to load test whatever your doing.

You always run the risk of losing data in any application crash before its
written to disk/database.  What you need to work out is how many records are
you prepared to lose and make sure your write events minimise the impact.
So if you can only lose 10 records then dont wait until 100 to write to the
database.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog