Entity Framework 数据读取性能

Question

我有一个有趣的情况。当我在 Microsoft SQL Server Management Studio 中的远程 SQL 服务器上运行查询时，它运行速度很快（12 秒），但是当我使用 DbContext.Database.SqlQuery<EntityType>(script) 在实体框架中运行相同的查询时，它需要 48 秒。

我尝试设置set arithabort on。该设置已应用，但并没有改变性能。我无法提供查询执行计划，因为我在 SQL 服务器上只有有限的权限。但我可以说 100% 这不是查询问题。

考虑这个查询：

declare @t table (...)
insert into @t
select <long query>

select top 1 * from @t

@t 变量包含大约 35k 行。 EF 和 SSMS 中的执行时间非常相似。但是当我删除top 1 时，奇怪的事情开始发生。在 SSMS 中我得到 10 秒，但在 EF 中大约 40 秒。

我想这个小实验可以排除 SQL Server 选择错误的执行计划而拖慢速度的可能性。

另一个兴趣点是 EF 完成的实体实现。我认为这也不是瓶颈，因为当我在本地 SQL Express 上运行具有相似大小结果集的类似查询时，我几乎可以立即在两种情况下得到结果。

所以我的下一个猜测是网络问题。我安装了 Microsoft Network Monitor 3.4 并监控了 SSMS 和 EF 的网络流量。我发现的有趣的事情是由于某种原因，EF 版本中有许多较小的数据包和一些 TLS 数据包。 SSMS 版本的数据包大小更稳定，没有 TLS 数据包。

那么问题来了：EF版能不能加速？那些 TLS 数据包是什么，有没有可能摆脱它们？

更新
实体框架 v6.1.3
.NET v4.5.1
SQL Server v10.50.2550.0
本地 SQLExpress v12.0.4213.0
视窗 7 专业版

更新

using (var connection = new SqlConnection(DbContext.Database.Connection.ConnectionString))
using (var cmd = new SqlCommand(script, connection))
{
    connection.Open();

    cmd.CommandType = CommandType.Text;
    using (SqlDataReader reader = cmd.ExecuteReader())
    {
        reader.Read();
        do
        {
        } while (reader.Read());
    }
}

此代码在时间上产生相同的结果。

Answer 1

我已经进行了一些研究和实验，似乎将packet size=32768（这是最大大小）选项添加到连接字符串往往会将速度提高到几乎 SSMS 级别。有趣的是，我收到的 TCP 数据包不会增加它们的大小。

我也尝试了其他连接字符串选项，但没有收到任何明显的速度提升。