Paul Randal of SQLskills continues his series on maintaining happy and healthy transaction logs in SQL Server, this time focusing on configuration issues that can lead to less than optimal performance.
In my previous post on streamlining the operations of the transaction log, I discussed two of the most common causes of extra log records being generated: dead weight from unused nonclustered indexes and page split operations (that cause index fragmentation). Assuming you've read that post, I mentioned that there are more subtle problems that can be detrimental to transaction log performance, and I'm going to cover these here.
Many people have implemented ASPState in their environment. Some people use the in-memory option (InProc), but usually I see the database option being used. There are some potential inefficiencies here that you might not notice on low volume sites but that will start to affect performance as your web volume ramps up.
In many SQL Server workloads, especially OLTP, the database's transaction log can be a bottleneck that adds to the time it takes a transaction to complete. Most people assume that the I/O subsystem is the real bottleneck, with it not being able to keep up with the amount of transaction log being generated by the workload.