在SQL Server 2008中压缩TCP

-7

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

所有我们想要做的是把一些TCP compression，但它看起来像SQL Server 2008不提供此功能。

什么，使TCP通信压缩的简单的解决方案？

2011-08-21 Cartesius00

提示 - 侮辱的人谁是帮助你不会让你拥有这个网站上。 – Hogan

此外，如果您在LAN上看不到问题，但在WAN上看到问题，则问题与延迟有关 - 您正在进行大量小型连接，并且在WAN上运行缓慢。压缩不会帮助解决这个问题（事实上它可能会使情况变得更糟）。在你的程序上运行一个配置文件，看看实体真的在做什么。它会让你哭泣。 – Hogan

这个问题尖叫'错误的建筑选择'，不幸的是没有一个简单的解决方案。有几个人试图告诉你，已经和简单地驳回他们的建议不会使问题消失 – Eddy

SQL Server使用TDS protocal。

它并不关心你是否使用TCP或命名管道“力”。从获取数据到B

你需要启用或设立某种compression（谷歌搜索）的：

在OS级
接口/硬件级
网络级

来源

2011-08-21 11:37:25 gbn

太通用了。对不起，但没用。 – Cartesius00

@James：我会用简单的语言为你解释：“这不是SQL Server问题”。投票结束并且-1 – gbn

@James - gbn答案完全是关键。你的问题与SQL服务器或实体框架无关（除了实体框架是错误的平台使用，因为它总是有这样的问题） - 如果你想回答这个问题，把它带到硬件和系统管理站点 - - 超级用户或服务器故障。你在这里得不到多少帮助。 – Hogan

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

而且是它可以与存储过程和自定义查询，并与整个放弃EF最坏的情况下更换你的EF代码部分结束。

如果你的问题是传输的数据量再次是时间去想优化和传输的数据量减少到只需要子集，或使用存储过程或视图SQL服务器上的一些预处理。顺便说一句。这种思考应该在应用程序设计期间完成，您应该考虑应用程序运行的目标环境。

编辑：

还有一点需要注意。通过WAN与数据库进行通信并不常见。通常这样的需求导致实现另一个层次，其中业务逻辑坐在具有SQL服务器的局域网服务器上。此业务逻辑层向WAN上的客户端公开Web服务。此架构可以减少与数据库进行大量通信时的等待时间，同时，客户端和服务之间正确的消息交换架构可以带来额外的改进。

来源

2011-08-21 12:35:35

+1不错，考虑周到的答案 – gbn

正是我想说的！ – Hogan

在SQL Server 2008中压缩TCP

回答

相关问题