網絡寬帶也會有所影響。
網絡是數據庫基礎架構的主要部分。但是，通常性能基準測試是在本地計算機上完成的，客戶端和服務器並置在壹起。這樣做是為了簡化結構並排除壹個以上的變量（網絡部分），但是我們也忽略了網絡對性能的影響。對於像 MySQL Group Replication 這樣的產品集群來說，網絡更為重要。在這篇文章中，我將介紹網絡設置。這些都是簡單而微不足道的，但卻是讓我們更了解復雜網絡設置效果的基石。
安裝我將使用兩臺裸機服務器，通過專用的 10Gb 網絡連接。我將通過使用 ethtool-s eth1 speed1000duplex full autoneg off 命令更改網絡接口速度來模擬 1Gb 網絡。
我將運行壹個簡單的基準：sysbench oltp_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 開銷。操作系統：Ubuntu 16.04
N1 基準-網絡帶寬在第壹個實驗中，我將比較 1Gb 網絡和 10Gb 網絡。顯然，1Gb 網絡性能是這裏的瓶頸，如果我們遷移到 10Gb 網絡，我們可以顯著改善我們的結果。要查看 1Gb 網絡是瓶頸，我們可以檢查 PMM（percona 的數據庫監控管理開源工具） 中的網絡流量圖表：
我們可以看到我們的吞吐量達到了 116 MiB/s（或 928 Mb/s)，這非常接近網絡帶寬。但是，如果我們的網絡基礎設施僅限於 1Gb，我們可以做些什麽？
N2 基準-協議壓縮MySQL 協議中有壹個功能，您可以看到客戶端和服務器之間的網絡交換壓縮：--mysql-compression=on。讓我們看看它將如何影響我們的結果。
這是壹個有趣的結果。當我們使用所有可用的網絡帶寬時，協議壓縮實際上有助於改善結果。
但是 10Gb 網絡不是這種情況。壓縮/解壓縮所需的 CPU 資源是壹個限制因素，通過壓縮，吞吐量實際上只達到我們沒有壓縮的壹半。現在讓我們談談協議加密，以及如何使用 SSL 影響我們的結果。
N3基準-網絡加密
對於 1Gb 網絡，SSL 加密顯示了壹些損失 - 單線程約為 10％ - 但是否則我們再次達到帶寬限制。我們還看到了大量線程的可擴展性，這在 10Gb 網絡案例中更為明顯。使用 10Gb 時，SSL 協議在 32 個線程後不會擴展。實際上，它似乎是 MySQL 目前使用的 OpenSSL 1.0 中的可伸縮性問題。在我們的實驗中，我們看到 OpenSSL 1.1.1 提供了更好的可伸縮性，但是您需要從鏈接到OpenSSL 1.1.1 的源代碼中獲得特殊的 MySQL 構建才能實現這壹點。我沒有在這裏展示它們，因為我們沒有生產二進制文件。
結論
1. 網絡性能和利用率將影響壹般應用程序吞吐量。
2. 檢查您是否達到了網絡帶寬限制。
3. 如果受到網絡帶寬的限制，協議壓縮可以改善結果，但如果不是，則可能會使事情變得更糟。
4. SSL 加密在線程數量較少的情況下會有壹些損失（約10％），但對於高並發工作負載，它不會擴展。