Merge pull request #2613 from spidernet-io/robot/cherrypick/pr2601/re…

…lease-v0.8 docs: fix performance value units
spidernet-io · Nov 16, 2023 · f80262a · f80262a
2 parents 09d2681 + bf5df0b
commit f80262a
Show file tree

Hide file tree

Showing 4 changed files with 51 additions and 53 deletions.
diff --git a/docs/concepts/io-performance-zh_CN.md b/docs/concepts/io-performance-zh_CN.md
@@ -65,25 +65,25 @@ netperf 是一种广泛使用的网络性能测试工具，可让您测量网络
 
   通过 `netperf -H <Pod IP> -l 10  -c -t TCP_RR -- -r100,100` 测试跨节点 Pod 访问 Pod IP 的吞吐量，数据如下。
 
-  | 测试对象                                     |       Throughput     |
-  | ------------------------------------------ | --------------------- |
-  | 基于 iptables datapath 和 无隧道 的 Calico    |       9985.7 sec      |
-  | 基于全量 eBPF 加速 和 无隧道 的 cilium         |       17571.3 sec     |
-  | 基于 macvlan 的同子网的 Spiderpool Pod        |       19793.9 sec     |
-  | 基于 macvlan 的跨子网的 Spiderpool Pod        |       19215.2 sec     |
-  | 节点到节点                                   |       47560.5 sec     |
+  | 测试对象                                     |  Throughput (rps) |
+  | ------------------------------------------ | ------------------ |
+  | 基于 iptables datapath 和 无隧道 的 Calico    |       9985.7      |
+  | 基于全量 eBPF 加速 和 无隧道 的 cilium         |       17571.3     |
+  | 基于 macvlan 的同子网的 Spiderpool Pod        |       19793.9     |
+  | 基于 macvlan 的跨子网的 Spiderpool Pod        |       19215.2     |
+  | 节点到节点                                   |       47560.5     |
 
 - 以 cluster IP 为目的的跨节点 Pod 的 netperf 测试。
 
   通过 `netperf -H <cluster IP> -l 10  -c -t TCP_RR -- -r100,100` 测试跨节点 Pod 访问 cluster IP 的吞吐量，数据如下。
 
-  | 测试对象                                              |      Throughput     |
-  | --------------------------------------------------- | -------------------- |
-  | 基于 iptables datapath 和 无隧道 的 Calico             |      9782.2 sec     |
-  | 基于全量 eBPF 加速 和 无隧道 的 cilium                  |      17236.5 sec    |
-  | 基于 macvlan 的同子网和 kube-proxy 的 Spiderpool Pod   |      16002.3 sec    |
-  | 基于 macvlan 的同子网且全量 eBPF 加速的 Spiderpool Pod   |     18992.9 sec    |
-  | 节点到节点                                            |      47560.5 sec    |
+  | 测试对象                                              |  Throughput (rps) |
+  | --------------------------------------------------- | ------------------ |
+  | 基于 iptables datapath 和 无隧道 的 Calico             |     9782.2 rps    |
+  | 基于全量 eBPF 加速 和 无隧道 的 cilium                  |     17236.5 rps   |
+  | 基于 macvlan 的同子网和 kube-proxy 的 Spiderpool Pod   |     16002.3 rps   |
+  | 基于 macvlan 的同子网且全量 eBPF 加速的 Spiderpool Pod   |    18992.9 rps   |
+  | 节点到节点                                            |     47560.5 rps   |
 
 ## iperf 网络性能测试
 
@@ -123,21 +123,21 @@ redis-benchmark 旨在通过模拟多个客户端并执行各种 Redis 命令来
 
   | 测试对象                                 |        get           |        set           |
   | --------------------------------------- | -------------------- | -------------------- |
-  | 基于 iptables datapath 和 无隧道 的 Calico |      45682.96 sec   |      46992.48 sec    |
-  | 基于全量 eBPF 加速 和 无隧道 的 cilium      |      59737.16 sec    |      59988.00 sec   |
-  | 基于 macvlan 的同子网的 Spiderpool Pod     |      66357.00 sec    |      66800.27 sec   |
-  | 基于 macvlan 的跨子网的 Spiderpool Pod     |      67444.45 sec    |      67783.67 sec   |
+  | 基于 iptables datapath 和 无隧道 的 Calico |      45682.96 rps   |      46992.48 rps    |
+  | 基于全量 eBPF 加速 和 无隧道 的 cilium      |      59737.16 rps    |      59988.00 rps   |
+  | 基于 macvlan 的同子网的 Spiderpool Pod     |      66357.00 rps    |      66800.27 rps   |
+  | 基于 macvlan 的跨子网的 Spiderpool Pod     |      67444.45 rps    |      67783.67 rps   |
 
 - 以 cluster IP 为目的的跨节点 Pod 的 redis-benchmark 测试。
 
   通过 `redis-benchmark -h <cluster IP> -p 6379 -d 1000 -t get,set` 测试跨节点 Pod 访问 cluster IP 的性能，数据如下。
 
   | 测试对象                                            |        get            |        set           |
   | -------------------------------------------------- | --------------------- | -------------------- |
-  | 基于 iptables datapath 和 无隧道 的 Calico           |       46082.95 sec     |      46728.97 sec    |
-  | 基于全量 eBPF 加速 和 无隧道 的 cilium                 |       60496.07 sec    |      58927.52 sec    |
-  | 基于 macvlan 的同子网和 kube-proxy 的 Spiderpool Pod  |       45578.85 sec    |      46274.87 sec    |
-  | 基于 macvlan 的同子网且全量 eBPF 加速的 Spiderpool Pod  |       63211.12 sec    |      64061.50 sec    |
+  | 基于 iptables datapath 和 无隧道 的 Calico           |       46082.95 rps     |      46728.97 rps    |
+  | 基于全量 eBPF 加速 和 无隧道 的 cilium                 |       60496.07 rps    |      58927.52 rps    |
+  | 基于 macvlan 的同子网和 kube-proxy 的 Spiderpool Pod  |       45578.85 rps    |      46274.87 rps    |
+  | 基于 macvlan 的同子网且全量 eBPF 加速的 Spiderpool Pod  |       63211.12 rps    |      64061.50 rps    |
 
 ## 总结
 

diff --git a/docs/concepts/io-performance.md b/docs/concepts/io-performance.md
@@ -65,25 +65,25 @@ netperf is a widely used network performance testing tool that allows you to mea
 
   Use `netperf -H <Pod IP> -l 10 -c -t TCP_RR -- -r100,100` to test the throughput of cross-node Pod access to Pod IP. The data is as follows.
 
-  | Test object                                              |     Throughput      |
-  | -------------------------------------------------------- | ------------------- |
-  | Calico based on iptables datapath and tunnelless         |     9985.7 sec      |
-  | Cilium based on full eBPF acceleration and no tunneling  |     17571.3 sec     |
-  | Spiderpool Pod on the same subnet based on macvlan       |     19793.9 sec     |
-  | Spiderpool Pod across subnets based on macvlan           |     19215.2 sec     |
-  | node to node                                             |     47560.5 sec     |
+  | Test object                                              |  Throughput (rps) |
+  | -------------------------------------------------------- | ----------------- |
+  | Calico based on iptables datapath and tunnelless         |     9985.7        |
+  | Cilium based on full eBPF acceleration and no tunneling  |     17571.3       |
+  | Spiderpool Pod on the same subnet based on macvlan       |     19793.9       |
+  | Spiderpool Pod across subnets based on macvlan           |     19215.2       |
+  | node to node                                             |     47560.5       |
 
 - Netperf testing across node Pods for cluster IP purposes.
 
   Use `netperf -H <cluster IP> -l 10 -c -t TCP_RR -- -r100,100` to test the throughput of cross-node Pods accessing the cluster IP. The data is as follows.
 
-  | Test object                                                                    |      Throughput    |
-  | ------------------------------------------------------------------------------ | ------------------ |
-  | Calico based on iptables datapath and tunnelless                               |     9782.2 sec     |
-  | Cilium based on full eBPF acceleration and no tunneling                        |     17236.5 sec    |
-  | Spiderpool Pod based on macvlan on the same subnet and kube-proxy              |     16002.3 sec    |
-  | Spiderpool Pod based on macvlan on the same subnet and fully eBPF accelerated  |     18992.9 sec    |
-  | node to node                                                                   |     47560.5 sec    |
+  | Test object                                                                    | Throughput (rps) |
+  | ------------------------------------------------------------------------------ | ---------------- |
+  | Calico based on iptables datapath and tunnelless                               |     9782.2       |
+  | Cilium based on full eBPF acceleration and no tunneling                        |     17236.5      |
+  | Spiderpool Pod based on macvlan on the same subnet and kube-proxy              |     16002.3      |
+  | Spiderpool Pod based on macvlan on the same subnet and fully eBPF accelerated  |     18992.9      |
+  | node to node                                                                   |     47560.5      |
 
 ## iperf network performance test
 
@@ -123,21 +123,21 @@ redis-benchmark is designed to measure the performance and throughput of a Redis
 
   | Test object                                               |         get          |        set         |
   | --------------------------------------------------------- | -------------------- | ------------------ |
-  | Calico based on iptables datapath and tunnelless          |      45682.96 sec    |     46992.48 sec   |
-  | Cilium based on full eBPF acceleration and no tunneling   |      59737.16 sec    |     59988.00 sec   |
-  | Spiderpool Pod on the same subnet based on macvlan        |      66357.00 sec    |     66800.27 sec   |
-  | Spiderpool Pod across subnets based on macvlan            |      67444.45 sec    |     67783.67 sec   |
+  | Calico based on iptables datapath and tunnelless          |      45682.96 rps    |     46992.48 rps   |
+  | Cilium based on full eBPF acceleration and no tunneling   |      59737.16 rps    |     59988.00 rps   |
+  | Spiderpool Pod on the same subnet based on macvlan        |      66357.00 rps    |     66800.27 rps   |
+  | Spiderpool Pod across subnets based on macvlan            |      67444.45 rps    |     67783.67 rps   |
 
 - Cross-node Pod redis-benchmark testing for cluster IP purposes.
 
   Use `redis-benchmark -h <cluster IP> -p 6379 -d 1000 -t get,set` to test the performance of cross-node Pod access to cluster IP. The data is as follows.
 
   | Test object                                                                    |        get            |        set           |
   | ------------------------------------------------------------------------------ | --------------------- | -------------------- |
-  | Calico based on iptables datapath and tunnelless                               |       46082.95 sec    |      46728.97 sec    |
-  | Cilium based on full eBPF acceleration and no tunneling                        |       60496.07 sec    |      58927.52 sec    |
-  | Spiderpool Pod based on macvlan on the same subnet and kube-proxy              |       45578.85 sec    |      46274.87 sec    |
-  | Spiderpool Pod based on macvlan on the same subnet and fully eBPF accelerated  |       63211.12 sec    |      64061.50 sec    |
+  | Calico based on iptables datapath and tunnelless                               |       46082.95 rps    |      46728.97 rps    |
+  | Cilium based on full eBPF acceleration and no tunneling                        |       60496.07 rps    |      58927.52 rps    |
+  | Spiderpool Pod based on macvlan on the same subnet and kube-proxy              |       45578.85 rps    |      46274.87 rps    |
+  | Spiderpool Pod based on macvlan on the same subnet and fully eBPF accelerated  |       63211.12 rps    |      64061.50 rps    |
 
 ## Summary
 

diff --git a/docs/usage/underlay_cni_service-zh_CN.md b/docs/usage/underlay_cni_service-zh_CN.md
@@ -295,9 +295,8 @@ tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 byt
 | with kube-proxy | 36.763 | 72254.34 |
 | without kube-proxy | 27.743 | 107066.38 |
 
-根据结果显示，经过 Cilium kube-proxy replacement 之后，访问 Service 大约加速 30%。
+根据结果显示，经过 Cilium kube-proxy replacement 之后，访问 Service 大约加速 30%。更多测试数据参考[网络 IO 性能](../concepts/io-performance-zh_CN.md)
 
 ## 结论
 
-Underlay CNI 访问 Service 有以上两种方案解决。kube-proxy 的方式更加常用稳定，大部分环境都可以稳定使用。 Cilium Without Kube-Proxy 为 Underlay CNI 访问 Service 提供了另一种可选方案，并且加速了 Service 访问，
-尽管这有一定使用限制及门槛，但在特定场景下能够满足用户的需求。
+Underlay CNI 访问 Service 有以上两种方案解决。kube-proxy 的方式更加常用稳定，大部分环境都可以稳定使用。 Cilium Without Kube-Proxy 为 Underlay CNI 访问 Service 提供了另一种可选方案，并且加速了 Service 访问，尽管这有一定使用限制及门槛，但在特定场景下能够满足用户的需求。
diff --git a/docs/usage/underlay_cni_service.md b/docs/usage/underlay_cni_service.md
@@ -57,12 +57,12 @@ default via 10.6.0.1 dev eth0
 - **10.6.212.101 dev veth0 scope link**: `10.6.212.101` is the node's IP, which ensure where the Pod access the same node via `veth0`.
 - **10.233.64.0/18 via 10.6.212.101 dev veth0**: 10.233.64.0/18 is cluster service subnet, which ensure the Pod access ClusterIP via `veth0`.
 
-This solution heavily relies on the `MASQUERADE` of kube-proxy, otherwise the reply packets will be directly forwarded to the source Pod, 
-and if they pass through some security devices, the packets will be dropped. Therefore, in some special scenarios, we need to set `masqueradeAll` 
+This solution heavily relies on the `MASQUERADE` of kube-proxy, otherwise the reply packets will be directly forwarded to the source Pod,
+and if they pass through some security devices, the packets will be dropped. Therefore, in some special scenarios, we need to set `masqueradeAll`
 of kube-proxy to true.
 
 > By default, the underlay subnet of a Pod is different from the clusterCIDR of the cluster, so there is no need to enable `masqueradeAll`, and access between them will be SNATed.
-> 
+>
 > If the underlay subnet of a Pod is the same as the clusterCIDR of the cluster, then we must set `masqueradeAll` to true.
 
 ### coordinator run in overlay
@@ -300,9 +300,8 @@ tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 byt
 | with kube-proxy | 36.763 | 72254.34 |
 | without kube-proxy | 27.743 | 107066.38 |
 
-According to the results, after Cilium kube-proxy replacement, access to the service is accelerated by about 30%.
+According to the results, after Cilium kube-proxy replacement, access to the service is accelerated by about 30%. For more test data, please refer to [Network I/O Performance](../concepts/io-performance.md)
 
 ## Conclusion
 
-There are two solutions to the Underlay CNI Access Service. The kube-proxy method is more commonly used and stable, and can be used stably in most environments. Cilium Without Kube-Proxy provides an alternative option for Underlay CNI to access the Service, 
-and accelerates Service access. Although there are certain restrictions and thresholds for use, it can meet the needs of users in specific scenarios.
+There are two solutions to the Underlay CNI Access Service. The kube-proxy method is more commonly used and stable, and can be used stably in most environments. Cilium Without Kube-Proxy provides an alternative option for Underlay CNI to access the Service and accelerates Service access. Although there are certain restrictions and thresholds for use, it can meet the needs of users in specific scenarios.