在 SQL Server 2008 中压缩 TCP [关闭]答案

【问题标题】：Compressing TCP in SQL Server 2008 [closed]在 SQL Server 2008 中压缩 TCP [关闭]
【发布时间】：2011-08-21 22:04:29
【问题描述】：

我们有使用实体框架的 .NET 4.0 应用程序。应用程序通过 TCP 远程连接到 SQL Server。在局域网上，速度很快，但在互联网上，流量非常高。

我们想做的只是打开一些TCP compression，但看起来SQL Server 2008 不提供此功能。

压缩 TCP 通信最简单的解决方案是什么？

【问题讨论】：

提示——侮辱帮助你的人不会让你在这个网站上走得更远。
另外，如果您在 LAN 上没有看到问题，但在 WAN 上看到了问题，则问题与延迟有关 - 您正在建立许多小型连接，并且运行速度很慢广域网。压缩对这个问题没有帮助（实际上它可能会使情况变得更糟。）在你的程序上运行一个配置文件，看看 Entity 在后台到底做了什么。它会让你哭泣。
这个问题大喊“错误的架构选择”，遗憾的是没有简单的解决方案。有几个人试图告诉你，简单地忽略他们的建议不会让问题消失

标签： c# .net sql-server-2008 entity-framework-4

【解决方案1】：

您试图在错误的级别/层上解决问题。分析您与 SQL Server 的通信并开始考虑优化。这是唯一有效的起点。 EF 的不正确使用会导致与 SQL 服务器的通信很糟糕和缓慢，这是任何压缩都无法解决的问题，因为冗长的顺序通信意味着多次不必要的数据库往返，其中每次往返都会增加处理的持续时间。潜伏。我已经看到了解决方案（其中一些是我自己做的），其中不正确地使用 EF 在单个请求处理中创建了数千个延迟加载查询。

是的，它最终可能会用存储过程和自定义查询替换部分 EF 代码，在最坏的情况下会放弃整个 EF。

如果您的问题是传输的数据量，那么又是时候考虑优化并将传输的数据量减少到仅需要的子集，或者可能在存储过程或视图中在 SQL Server 上使用一些预处理。顺便提一句。这种思考应该在应用程序设计期间进行，您应该考虑应用程序将运行的目标环境。

编辑：

还有一个注意事项。通过 WAN 与数据库通信并不常见。通常，这样的要求会导致使用 SQL 服务器在 LAN 中的服务器上实现另一层业务逻辑。此业务逻辑层向 WAN 上的客户端公开 Web 服务。这种架构可以在与数据库进行大量通信时减少延迟，同时客户端和服务之间消息交换的正确架构可以带来额外的改进。

【讨论】：

+1 不错，经过深思熟虑的答案
正是我想说的！

【解决方案2】：

SQL Server 使用 TDS 协议。

不管你是使用 TCP 还是命名管道还是“强制”从 A 到 B 获取数据

您需要启用或设置某种compression（Google 搜索）：

在操作系统级别
接口/硬件级别
网络级别

【讨论】：

太笼统了。对不起，但没用。
@James：我会用简单的术语为您说明：“这不是 SQL Server 问题”。投票关闭和-1
@James - gbn 答案完全正确。您的问题与 sql server 或实体框架无关（除了实体框架是错误的平台，因为它总是有这样的问题）-如果您想回答这个问题，请将其带到硬件和系统管理站点- - 超级用户或服务器故障。在这里你不会得到太多帮助。