网络是数据库基础设施的主要部分。然而，通常情况下，性能基准测试是在本地机器上完成的，客户端和服务器并置。这样做是为了简化结构并排除多个变量（网络部分），但我们也忽略了网络对性能的影响。网络对于像MySQLGroupReplication这样的生产集群来说更为重要。在这篇文章中，我将介绍网络设置。这些简单而微不足道，但却是构建块，使我们能够更好地理解复杂网络设置的影响。对于安装，我将使用通过专用10Gb网络连接的两台裸机服务器。我将通过使用ethtool-seth1speed1000duplexfullautonegoff命令更改网络接口速度来模拟1Gb网络。我将运行一个简单的基准测试：sysbencholtp_read_only--mysql-ssl=on--mysql-host=172.16.0.1--tables=20--table-size=10000000--mysql-user=sbtest--mysql-password=sbtest--threads=$i--time=300--report-interval=1--rand-type=pareto以从1到2048的线程运行。所有数据都适合内存-innodb_buffer_pool_size足够大。所以工作负载在内存中是CPU密集型的：没有IO开销。操作系统：Ubuntu16.04N1基准-网络带宽在第一个实验中，我将比较1Gb网络和10Gb网络。显然，1Gb网络性能是这里的瓶颈，如果我们迁移到10Gb网络，我们可以显着改善我们的结果。要看出1Gb网络是瓶颈，我们可以在PMM（percona的数据库监控和管理开源工具）中查看网络流量图：可以看到我们的吞吐量达到了116MiB/s（或928Mb/s），这是非常近似的网络带宽。但是，如果我们的网络基础设施仅限于1Gb，我们该怎么办？N2Benchmark-协议压缩MySQL协议中有一项功能，您可以在其中看到客户端和服务器之间的网络交换压缩：--mysql-compression=on。让我们看看它将如何影响我们的结果。这是一个有趣的结果。当我们使用所有可用的网络带宽时，协议压缩实际上有助于改善结果。但这不是10Gb网络的情况。压缩/解压缩所需的CPU资源是一个限制因素，压缩后的吞吐量实际上只有没有压缩时的一半。现在我们来谈谈协议加密以及使用SSL如何影响我们的结果。N3基准-网络加密对于1Gb网络，SSL加密显示出一些损失-单个线程大约10%-但否则我们再次达到带宽限制。我们还看到大量线程的可扩展性，这在10Gb网络案例中更为明显。对于10Gb，SSL协议不会在32个线程后扩展。事实上，这似乎是MySQL当前使用的OpenSSL1.0中的可伸缩性问题。在我们的实验中，我们看到OpenSSL1.1.1提供了更好的可扩展性，但是您需要从链接到OpenSSL1.1.1的源代码构建一个特殊的MySQL来实现这一点。我没有在这里展示它们，因为我们没有生产二进制文件。结论1.网络性能和利用率会影响一般的应用程序吞吐量。2.检查是否已达到网络带宽限制。3.如果您受到网络带宽的限制，协议压缩可以改善结果，但如果您不受网络带宽的限制，则会使事情变得更糟。4.SSL加密在线程数较少时会遭受一些损失（大约10%），但它不会针对高并发工作负载进行扩展。
