網絡是數據庫基礎架構的主要部分。但是，通常性能基準測試是在本地計算機上完成的，客戶端和服務器并置在一起。這樣做是為了簡化結構并排除一個以上的變量(網絡部分)，但是我們也忽略了網絡對性能的影響。

[[274257]]

對于像 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%)，但對于高并發工作負載，它不會擴展。