实体框架数据读取性能

Question

我有一个有趣的情况。 当我在Microsoft SQL Server Management Studio中的远程SQL服务器上运行查询时，它运行速度很快（12秒），但是当我使用DbContext.Database.SqlQuery<EntityType>(script)在Entity Framework中运行相同的查询时，需要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的网络流量。 我发现的interestig事情是由于某种原因有很多较小的数据包和EF版本的一些TLS数据包。 在SSMS版本中，数据包大小更稳定，并且没有TLS数据包。

所以问题是：是否可以加速EF版本？ 什么是TLS数据包，是否有可能摆脱它们？

更新
实体框架v6.1.3
.NET v4.5.1
SQL Server v10.50.2550.0
本地SQLExpress v12.0.4213.0
Windows 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数据包不会增加它们的大小。

我已经尝试过其他连接字符串选项，但没有收到任何明显的速度增加。