摘要：如果站点有单独的应用程序池，它们的流量是否可以通过“NIC teaming”避免争用？
（（让我知道这是否更好地发布在http://networkengineering.stackexchange.com上））
详细信息：我们的托管服务提供商已经定价了可以在托管我们网站的服务器和托管我们数据库的服务器之间进行 NIC 组合的方案。
技术细节（以防万一）：
(1) 网站托管在运行 Windows Server 2008 和 IIS 7.0 的服务器上。
(2) 数据库托管在运行 Windows Server 2003 和 SQL Server 2005 的服务器上。
(3) 他们描述的 NIC 组合方案将涉及两台服务器中的每一个都具有 10GBE 双端口 NIC 卡，并且在它们之间使用交叉电缆。
(4) 每个站点都有自己的web.config，在IIS中有自己的应用程序池。
(5) 目前，每个网站到 SQL Server 的连接字符串看起来都完全相同，但我们可以让每个网站使用不同的连接字符串。
但是，托管服务提供商告诉我们，如果（A）我们的应用程序被编码为使用 NIC 组合（不是），或者
（B）我们的通信通过多个 TCP 流，我们只会看到“带宽聚合” 。
所以，这是我的前 2 个问题......称之为“计划 A”——
（I）因为我们的站点都有单独的应用程序池（上面的细节 #4——导致“w3wp.exe”在任务中出现超过 10 次经理），这是否意味着我们有多个 TCP 流？
(II) 网络争用能否有效减少——也就是说，来自不同站点/不同应用程序池的流量能否在不同的 tNIC 上传输？
我的第三个问题......称之为“计划 B”：（
III）如果上述两个问题的答案都是“否”，那么我仍然认为有可能给我们的一个站点一个单独的 SQL Server 连接字符串，给它单独的 NIC 或单独的 tNIC。这有意义吗？
听起来确实如此，如果我在 StackOverflow 上理解另一篇文章：
.NET SqlConnection NIC 使用情况
但我仍然更喜欢计划——基于单独的应用程序池自动减少争用——因为我相信 NIC 组合解决方案能够根据不同的需求以更智能的方式引导流量将一个端口专门用于一个站点的 SQL Server。
如果这是 TMI，请原谅...欢迎反馈。
感谢您的关注...