Docker容器网络访问慢(Windows Server 2016容器)

Question

注意：Slow network performance in Docker container没有解决我的两个问题。Very slow network performance of Docker containers with host's network可能是相关的，但那里的一个响应肯定不是问题。

我运行的是windows server 2016集成版本的docker，带有microsoft/mssql-server-windows-developer镜像。(windows容器，linux不是终极目的的选择)。我的目标是将此映像用于临时SQL服务器，以进行重复的验收测试运行。

到目前为止，除了性能之外，一切都按照我需要的方式工作。作为性能度量，我有一组脚本(由powershell调用)，这些脚本将设置一个数据库，其中包含表、模式、角色等以及一些少量的初始数据。

当我与主机系统共享驱动器时，我可以连接到容器并在容器内运行此powershell脚本。需要30秒才能完成。没有错误，当我用SSMS检查数据库时，一切都是正确的。

当我从主机(通过暴露的端口1433)运行该脚本时，该脚本所用的时间大约增加了6000 %。(即约30分钟。)但是，它也可以正确运行并产生正确的结果。

上面的测量是使用默认的"nat“网络进行的，容器使用-p 1433:1433运行。我的主要问题是，当我从主机系统运行我的脚本时，如何获得远程合理的性能？(最终，不能从容器中运行测试中的任何内容。此外，最终必须解决同样的性能问题，才能使我们的容器部署计划变得现实。)

谢谢!

到目前为止我已经尝试过的东西。

首先，容器内部没有内部CPU或内存性能问题。因此，我已经尝试了--cpu相关选项和-m选项，并为容器提供了远远超过其实际需要的资源。内部性能不变。无论这些设置是什么，它都是非常快的。

我还研究了创建一个“透明”的网络。使用powershell cmdlet New-ContainerNetwork，我创建了一个透明网络，并使用"--net Trans“开关启动了容器。我从外部网络获得了一个有效的DHCP地址，并且可以连接到internet和intranet上的其他域计算机。使用netstat -a (和powershell Get-WMIObject win32_service)，我能够确定MSSQLSERVER实例正在端口1433上运行和侦听。我在容器中安装了telnet，并且可以使用命令"telnet ipaddressfromipconfig 1433“连接到该端口。

在主机命令提示符下，我可以ping容器的ip地址并获得响应，但是telnet命令(上面)不能从主机连接。因此，当我尝试SSMS时，它自然也无法连接。透明网络不支持-P或-p 1433:1433端口映射选项，但我一直在设想，如果我从主机访问，则透明网络不应该需要该选项。

我怀疑有防火墙以某种方式阻止了连接，所以我验证了容器中的防火墙服务甚至没有运行。我完全关闭了主机上的防火墙，但是，没有任何变化。我还是连接不上。我在docker运行中尝试了“--expose1433”参数，并在docker文件中使用expos1433行重新构建了图像。条件没有变化。

我不知道一个透明的网络是否能解决这个问题，但我想在这方面得到一些建议。

在合理的范围内，性能稍微慢一点是可以的，但6000 %的降级对于我的预期目的来说是一个问题。

Answer 1

事实证明，我不知道在这个问题上提供足够的信息。

我们用来创建和填充测试数据库的powershell代码向sql server发送了一系列328个script.sql文件。它正在使用Windows身份验证。这适用于容器，因为我们使用的是GSMA credential_spec，文档如下所示：

https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts

该身份验证方法可能与此相关，也可能不相关。使用Wireshark监视容器适配器时，我注意到一个连接只花了不到4秒的时间进行身份验证，但我没有其他方法可以提供作为比较。因此，我不能说这种身份验证方法是否比其他方法慢得多。绝对有意义的是，当我们的主要powershell代码发送特定的script.sql文件时，它没有使用Invoke-Sqlcmd。相反，它通过Invoke-Expression调用sqlcmd，类似于：

$args = "-v DBName = $dbName JobOwnerName = $jobOwnerName -E -i $fileName -S $server -V 1 -f 65001 -I";
if (!$skipDBFlag)
{
    $args += " -d $dbName";
}
Invoke-Expression "& sqlcmd --% $args";

在这种情况下，sqlcmd将重新连接到容器中的数据库，运行script.sql文件，然后断开连接。它不会像Invoke-Sqlcmd那样缓存连接。

因此，由于缺少连接池，身份验证发生了328次，每个script.sql文件一次。4秒* 328 / 60 = ~21分钟。这就是上述问题的来源。不存在于任何容器网络问题中。

我为最初不能提供所有相关信息而道歉。如果有人以这种方式使用容器时遇到类似的问题，以及在这种配置下使用SQL Server进行身份验证所需的时间长度，我希望这个答案能对他们有所帮助。