实际测速XTLS和TLS相差不大

[dhshfv]

相同机器，xray 1.0.0 xtls-rprx-direct和v2ray-core 4.33.0 vless-tcp-tls，速度相差并没有此处所述的那么大https://github.com/badO1a5A90/v2ray-doc/blob/main/performance_test/Xray/speed_test_20201124.md

[badO1a5A90]

看起来像是网口最高速率到了上限，所以一致，所以不能看出性能体现的差异。

[badO1a5A90]

建议调整控制硬件性能，不使网络速度上限成为瓶颈，然后对比性能差异。

[badO1a5A90]

性能对比测试不是吞吐量上限测试。
一定要注意控制瓶颈和变量。
首先保证足够的稳定的基础网络带宽（比如10G）
然后控制硬件性能，使基础网络带宽不成为瓶颈，不然测试出来都只是带宽上限而已。

也需要确定产生原始数据的网站的性能和到你服务器的带宽不是瓶颈（比如用speedtest时你选择的server／用iperf做测试时自己的生成初始数据流的硬件），不然测试出来就是他们的上限而已。

在瓶颈仅仅是你的测试软件的客户端或服务端硬件时，才能对比出相应的不同工具或协议组合的客户端性能或服务端性能差异。

[dhshfv]

同一机器，且客户端和服务端网络都没跑满。服务端运行speedtest结果：https://www.speedtest.net/result/c/65f43ec1-c18b-4751-b85d-16b6c9bdfa99

这差别不是挺大的吗？500mbps耶，有20%了

[badO1a5A90]

这个测试有很多可能限制在2.5G到3G的原因。

如果客户端和服务端的硬件的CPU都没有跑满。
那么100%你的速率限制来自别的影响。
这是无法测试协议之间性能差异的。

也可能影响来自比如你服务端到客户端之间的网络速度限制。（可能性较小

即使跑满，也有一些影响因素，比如你的客户端设备在处理多种事情。
也可能是没有用core而是用了客户端程序带来的影响（这个我不确定）

要测试协议之间性能差距，那么必然是硬件CPU负荷满的情况下，其他变量不变，仅有协议组合差别下测试的情况才是有意义的。

尽量把所有环节拆开，比如你的测试现在客户端同时跑v2core，客户端程序和浏览器网页处理TLS测速数据，可能还有一些其他系统开销（未知系统是什么系统），客户端程序本身也会带来干扰，那么即便CPU拉满，也未知其中CPU占用的互相影响。（可能正是因为如此才卡在3Gbps）

因为是测试性能的实验环境对比，精确的环境很重要。

建议把v2服务端和客户端，浏览器，分开成三台完全独立设备，直接使用core测试而不是其他客户端，关闭不必要的设置，并且控制性能使测速时v2或xray满负荷其中一台CPU（建议是客户端，因为实用场景中客户端情况限制较多）来对比。

[badO1a5A90]

他想达到200%的差距，而不是20%，这需要对硬件进行限制才能达到的，因为本身这个项目的测速就是有目的地测试性能，而不是普通使用时的网速

至于有没有200%确实也不尽然。
这确实不是一个固定比例。
设备性能越低，XTLS性能影响越大，尤其是没有AES指令的硬件设备上，会有更多倍数相差。

但因为有和没有readV存在的区别。即便高性能设备，性能差距也应该不会只有20%。
（注意到似乎是用Windows系统，windows系统下readV对性能影响是否有Linux那么大倒确实未知）

（另外不知道客户端本身，以及一些设置是否会有影响，建议直接core比较好）

[badO1a5A90]

还有一个原因，如果测试时是服务端的设备CPU满负荷
（你都没有提及负荷状态）
那么readV的影响将变小（因为瓶颈变成了服务器发送数据的性能限制，当然实际真实正常上网情形不太可能存在这种情况），
并且在高性能情况下，TLS加密解密影响也变小，那么提升可能确实会进一步缩小。

[badO1a5A90]

以上 @dhshfv
感谢测试。

[badO1a5A90]

测试的主要目的是给开发做参考，帮助他们优化，比如可以看到我仓库中有针对ds/统计/以及xtls一路开发过程中，各个流控模式各种TLSrecord大小的各种针对测试。

当然测试同时也可以告诉用户在不同使用模式下，或不同程序版本下性能有差异（并不是一定差多少）。

因此测试实验需要尽量细分和精确。
在尽量接近实际使用情况下,细分各个环节到独立硬件（产生原始数据流，工具服务端，工具客户端，接受处理原始数据流）
尽量排除各种因素相互干扰（比如把接受和处理原始数据的流程独立出去）。
然后控制不一样的对速率产生影响的瓶颈（主要指发送数据端/接受数据端硬件性能，这两项有意义），控制数据流向等等。
从而对比各种程序版本/协议组合或者某些设定和参数不一样时，在不同硬件瓶颈下的性能差异，给开发者做参考，或者找出问题（比如统计带来的影响，在另外几篇针对性测试中）。

这本身也确实代表实验环境下的差异，并不表示绝对差异，也更不是每个人使用后的性能提升。
比如TG群中一些硬路由器用户也可以说我的数据与他实际体验不符，因为他可能提升了三倍性能。

XTLS的性能提升，或其他一些优化/参数设置带来的性能影响或提升，本来就是不是定值。
尤其对于XTLS来说，硬件性能越低相对提升越大，硬件有没有AES指令相差更大。

[dhshfv]

降低客户端硬件配置再测，xray 1.0.0 xtls-rprx-direct和v2ray-core 4.33.0 vless-tcp-tls，还是相差不大

[badO1a5A90]

建议直接使用core去掉第三方客户端的影响

你客户端一侧的浏览器,core,第三方客户端，全在同一硬件，浏览器处理测速数据TLS就会吃掉很大一部分资源，变成瓶颈和关键因素,
因此建议把浏览器测速部分拆开至独立硬件减少影响。

最后，最好确认整个测试中瓶颈在哪里，看一下各部分的CPU负荷是否满，哪一部分满。

[dhshfv]

用三个机器拆开测试，使用speedtest cli避免浏览器大量占有资源，速度上已无差异，仅CPU占用差异，且下载无法跑满，上传已经跑满
xray 1.0.0 xtls-rprx-direct


v2ray-core 4.33.0 vless-tcp-tls

[badO1a5A90]

客户端和服务端都未能跑满cpu,又未能跑满网速...
应该是有别的原因限制了速度了,所以性能看起来一直一致.

从两个图中,xray和v2ray的CPU占用率来看,似乎xray明显占用低很多(网速相同的情况下)
但他们都没有利用满cpu,如果cpu满负荷那么两者的速率都肯定可以高于现在的3.5Gbps(且根据现在的CPU使用率来推测的话,xray会更高)

所以感觉还是因为某些原因导致瓶颈,限制在了3.5Gbps...这个暂时猜测不出什么端倪.

话说你浏览器/speedtest cli 这端的机器cpu跑满了吗?(是不是这里的瓶颈)

[dhshfv]

speedtest-cli占用50%CPU，机器直接speedtest结果https://www.speedtest.net/my-result/d/47414aaa-a300-4e09-b693-43ef83409159
上传能够基本跑满网速，下载似乎到了瓶颈