SNIReadSyncOverAsync和WaitForSingleObject的阻塞EF表现？ [英] SNIReadSyncOverAsync and WaitForSingleObject blocking EF performance?
问题描述
我做的，使用EF（System.Data.Entities）从SQL数据库读取WCF服务的一些分析。当我旋转起来的多个并行客户端打的服务，所有的CPU达到100％，业绩一般的坦克，一切都停滞不前。
I am doing some profiling on a WCF service that uses EF (System.Data.Entities) to read from a sql DB. When I spin up multiple parallel clients that hit the service, the CPUs all go to 100%, performance generally tanks, and everything bogs down.
在与并发分析器分析，我发现85％的时间都花在了同步，只有约4％是实际code执行。展望更深的堆栈跟踪，大多数同步似乎是从System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync调用WaitForSingleObject的。堆栈显示，呼叫转到一个本地方法的包装，然后缠在kernel32.dll中！_WaitForSingleObject。
In profiling this with the concurrency profiler, I found 85% of the time is spent in synchronization, with only about 4% being actual code execution. Looking deeper into the stack trace, most of the synchronization seems to be from a call to WaitForSingleObject in System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync. The stack shows that call goes to a native method wrapper, and then winds up at kernel32.dll!_WaitForSingleObject.
有没有人遇到过这个？有没有什么办法可以做些什么呢？我真的不抛出荒谬的负荷这个，只有约20条并行的客户，这一切都只读的，所以我很惊讶的线程甚至会打扰同步。
Has anyone experienced this before? Is there any way to do something about this? I'm not really throwing absurd load at this, only about 20 parallel clients, and it's all read-only, so I'm surprised the threads would even bother to synchronize.
我一直在争取这个一个星期了，我只是无法解释。任何帮助将是AP preciated！
I've been fighting with this for a week now and I just can't explain it. Any help would be appreciated!
推荐答案
您能提炼出这小code样品能重现问题？您使用的是什么版本的EF的？
Are you able to distill this to a small code sample that reproduces the problem? What version of EF are you using?
下面是基于您到目前为止已经给信息的一些看法。
Here are a few observations based on the information you've given so far.
任何低于EF 6的总是的同步。随着EF 6，你必须使用异步方法，而不是的选项。不过，不这样做，除非你的WCF服务也使用了异步模式。
Anything less than EF 6 is always synchronous. With EF 6 you have the option to use async methods instead. However, don't do this unless your WCF service also uses the async pattern.
您可以编写一个WCF服务，它的实现是异步的。请参阅<一href="http://blogs.msdn.com/b/endpoint/archive/2010/11/13/simplified-asynchronous-programming-model-in-wcf-with-async-await.aspx"相对=nofollow>有关详细信息，此文档。
You can write a WCF service whose implementation is asynchronous. See this documentation for more information.
如果您使用的一个的上述方法，但不能同时，您的code不会是异步的，但会导致不必要的同步开销。尤其要避免 Task.Run（）或等价物，因为这些东西会干脆转移工作到另一个线程，而无需实际提高吞吐量。
If you use one of the above methods, but not both, your code will not be asynchronous but will incur unnecessary synchronization overhead. Especially avoid Task.Run() or equivalents, since these will simply move work to another thread without actually improving throughput.
最后，另一个不相关的想法。请问您的问题涉及到EF初始化？当EF建立的元数据模型，它每个连接字符串做一次。如果多个线程试图使用相同的模型和该模型尚未初始化，所有线程将阻塞，直到初始化完成。要看到，如果这是你的问题，打一个电话到服务，并允许它完成。然后提交您的20并行请求。难道他们还是最大程度的发挥CPU？
Finally, another unrelated idea. Could your issue be related to EF initialization? When EF builds the metadata for a model it does this once per connection string. If multiple threads attempt to use the same model and that model has not yet been initialized, all threads will block until initialization is complete. To see if this is your issue, make one call to the service and allow it to complete. Then submit your 20 parallel requests. Do they still max out the CPU?
这篇关于SNIReadSyncOverAsync和WaitForSingleObject的阻塞EF表现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
