使用Entity Framework和SQL Server 2008,我们有一个应用程序写入大量数据,例如每分钟1000个新行,每个都在自己的DBContext.saveChanges调用中(我们没有将它们批处理在一起)。
问题是我们的写入非常落后。到了似乎像是折磨的程度。例如,我们会在两分钟内多次使用saveChanges保存新行,但不会进行任何写入,然后突然间我们会得到一些写入(但很多都完全丢失)。
我们已经进行了SQL跟踪,并发现SQL甚至没有接收到写入命令的10%。
因此,在saveChanges和SQL Server之间似乎存在某个问题。我想知道这个调用是如何工作的。它使用线程池吗?排队?我们可能正在超出的某个缓冲区?也许由于写入的数量而默默失败?
MSDN对解释这些东西的实际工作原理几乎没有用处。
问题是我们的写入非常落后。到了似乎像是折磨的程度。例如,我们会在两分钟内多次使用saveChanges保存新行,但不会进行任何写入,然后突然间我们会得到一些写入(但很多都完全丢失)。
我们已经进行了SQL跟踪,并发现SQL甚至没有接收到写入命令的10%。
因此,在saveChanges和SQL Server之间似乎存在某个问题。我想知道这个调用是如何工作的。它使用线程池吗?排队?我们可能正在超出的某个缓冲区?也许由于写入的数量而默默失败?
MSDN对解释这些东西的实际工作原理几乎没有用处。
SaveChanges()
中花费大部分时间的是数据验证(DataAnnotations)。 - jrummell