实际测速XTLS和TLS相差不大
dhshfv opened this issue · comments
相同机器，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
看起来像是网口最高速率到了上限，所以一致，所以不能看出性能体现的差异。
建议调整控制硬件性能，不使网络速度上限成为瓶颈，然后对比性能差异。
性能对比测试不是吞吐量上限测试。
一定要注意控制瓶颈和变量。
首先保证足够的稳定的基础网络带宽（比如10G）
然后控制硬件性能，使基础网络带宽不成为瓶颈，不然测试出来都只是带宽上限而已。
也需要确定产生原始数据的网站的性能和到你服务器的带宽不是瓶颈（比如用speedtest时你选择的server／用iperf做测试时自己的生成初始数据流的硬件），不然测试出来就是他们的上限而已。
在瓶颈仅仅是你的测试软件的客户端或服务端硬件时，才能对比出相应的不同工具或协议组合的客户端性能或服务端性能差异。
同一机器，且客户端和服务端网络都没跑满。服务端运行speedtest结果：https://www.speedtest.net/result/c/65f43ec1-c18b-4751-b85d-16b6c9bdfa99
这差别不是挺大的吗？500mbps耶，有20%了
这个测试有很多可能限制在2.5G到3G的原因。
如果客户端和服务端的硬件的CPU都没有跑满。
那么100%你的速率限制来自别的影响。
这是无法测试协议之间性能差异的。
也可能影响来自比如你服务端到客户端之间的网络速度限制。（可能性较小
即使跑满，也有一些影响因素，比如你的客户端设备在处理多种事情。
也可能是没有用core而是用了客户端程序带来的影响（这个我不确定）
要测试协议之间性能差距，那么必然是硬件CPU负荷满的情况下，其他变量不变，仅有协议组合差别下测试的情况才是有意义的。
尽量把所有环节拆开，比如你的测试现在客户端同时跑v2core，客户端程序和浏览器网页处理TLS测速数据，可能还有一些其他系统开销（未知系统是什么系统），客户端程序本身也会带来干扰，那么即便CPU拉满，也未知其中CPU占用的互相影响。（可能正是因为如此才卡在3Gbps）
因为是测试性能的实验环境对比，精确的环境很重要。
建议把v2服务端和客户端，浏览器，分开成三台完全独立设备，直接使用core测试而不是其他客户端，关闭不必要的设置，并且控制性能使测速时v2或xray满负荷其中一台CPU（建议是客户端，因为实用场景中客户端情况限制较多）来对比。
他想达到200%的差距，而不是20%，这需要对硬件进行限制才能达到的，因为本身这个项目的测速就是有目的地测试性能，而不是普通使用时的网速
至于有没有200%确实也不尽然。
这确实不是一个固定比例。
设备性能越低，XTLS性能影响越大，尤其是没有AES指令的硬件设备上，会有更多倍数相差。
但因为有和没有readV存在的区别。即便高性能设备，性能差距也应该不会只有20%。
（注意到似乎是用Windows系统，windows系统下readV对性能影响是否有Linux那么大倒确实未知）
（另外不知道客户端本身，以及一些设置是否会有影响，建议直接core比较好）
还有一个原因，如果测试时是服务端的设备CPU满负荷
（你都没有提及负荷状态）
那么readV的影响将变小（因为瓶颈变成了服务器发送数据的性能限制，当然实际真实正常上网情形不太可能存在这种情况），
并且在高性能情况下，TLS加密解密影响也变小，那么提升可能确实会进一步缩小。
以上 @dhshfv
感谢测试。
测试的主要目的是给开发做参考，帮助他们优化，比如可以看到我仓库中有针对ds/统计/以及xtls一路开发过程中，各个流控模式各种TLSrecord大小的各种针对测试。
当然测试同时也可以告诉用户在不同使用模式下，或不同程序版本下性能有差异（并不是一定差多少）。
因此测试实验需要尽量细分和精确。
在尽量接近实际使用情况下,细分各个环节到独立硬件（产生原始数据流，工具服务端，工具客户端，接受处理原始数据流）
尽量排除各种因素相互干扰（比如把接受和处理原始数据的流程独立出去）。
然后控制不一样的对速率产生影响的瓶颈（主要指发送数据端/接受数据端硬件性能，这两项有意义），控制数据流向等等。
从而对比各种程序版本/协议组合或者某些设定和参数不一样时，在不同硬件瓶颈下的性能差异，给开发者做参考，或者找出问题（比如统计带来的影响，在另外几篇针对性测试中）。
这本身也确实代表实验环境下的差异，并不表示绝对差异，也更不是每个人使用后的性能提升。
比如TG群中一些硬路由器用户也可以说我的数据与他实际体验不符，因为他可能提升了三倍性能。
XTLS的性能提升，或其他一些优化/参数设置带来的性能影响或提升，本来就是不是定值。
尤其对于XTLS来说，硬件性能越低相对提升越大，硬件有没有AES指令相差更大。
降低客户端硬件配置再测，xray 1.0.0 xtls-rprx-direct和v2ray-core 4.33.0 vless-tcp-tls，还是相差不大
建议直接使用core去掉第三方客户端的影响
你客户端一侧的浏览器,core,第三方客户端，全在同一硬件，浏览器处理测速数据TLS就会吃掉很大一部分资源，变成瓶颈和关键因素,
因此建议把浏览器测速部分拆开至独立硬件减少影响。
最后，最好确认整个测试中瓶颈在哪里，看一下各部分的CPU负荷是否满，哪一部分满。
用三个机器拆开测试，使用speedtest cli避免浏览器大量占有资源，速度上已无差异，仅CPU占用差异，且下载无法跑满，上传已经跑满
xray 1.0.0 xtls-rprx-direct
v2ray-core 4.33.0 vless-tcp-tls
客户端和服务端都未能跑满cpu,又未能跑满网速...
应该是有别的原因限制了速度了,所以性能看起来一直一致.
从两个图中,xray和v2ray的CPU占用率来看,似乎xray明显占用低很多(网速相同的情况下)
但他们都没有利用满cpu,如果cpu满负荷那么两者的速率都肯定可以高于现在的3.5Gbps(且根据现在的CPU使用率来推测的话,xray会更高)
所以感觉还是因为某些原因导致瓶颈,限制在了3.5Gbps...这个暂时猜测不出什么端倪.
话说你浏览器/speedtest cli 这端的机器cpu跑满了吗?(是不是这里的瓶颈)
speedtest-cli占用50%CPU，机器直接speedtest结果https://www.speedtest.net/my-result/d/47414aaa-a300-4e09-b693-43ef83409159
上传能够基本跑满网速，下载似乎到了瓶颈
speedtest-cli占用50%CPU，机器直接speedtest结果https://www.speedtest.net/my-result/d/47414aaa-a300-4e09-b693-43ef83409159
上传能够基本跑满网速，下载似乎到了瓶颈
下载这个瓶颈比较奇怪...我暂时不太能想到是什么造成的
因为CPU也没跑满(xray和v2ray都没跑满.speedtest-cli也没跑满.),网络上限应该也不只是3.5Gbps
截图的cpu占用率是服务端还是客户端的?确定两端都没跑满吗?
截图的cpu占用率是服务端还是客户端的?确定两端都没跑满吗?
截图是客户端，服务端和客户端是相同硬件的机器，服务端是Debian 10更不可能跑满
这确实有点奇怪,所有的硬件CPU都没跑满,网速也没跑满...所以产生瓶颈的是哪里呢.
emmm.上行测试倒是跑满了网速上限.
我觉得测试方式现在没什么问题,但造成下载瓶颈的原因暂时想不到.
ping @RPRX 看下还可能是什么原因.
speedtest-cli占用50%CPU，机器直接speedtest结果https://www.speedtest.net/my-result/d/47414aaa-a300-4e09-b693-43ef83409159
上传能够基本跑满网速，下载似乎到了瓶颈
想不出瓶颈原因.或者不用Qv2ray,客户端直接运行core再试一下?
截图的cpu占用率是服务端还是客户端的?确定两端都没跑满吗?
截图是客户端，服务端和客户端是相同硬件的机器，服务端是Debian 10更不可能跑满
非常感谢做了这么多的测试,现在我能想到的原因就是qv2ray,统计(但是direct理论上不受到统计的影响才对).
建议可以不用Qv2ray,客户端直接运行core,把服务端和客户端配置文件的统计关掉(删掉stats),再测试下.
感谢.
统计默认关闭，尝试直接运行core或用Linux作客户端，下载还是无法超过3.5G。
降低服务端配置，服务端CPU满载下的结果：
xray 1.0.0 xtls-rprx-direct
v2ray-core 4.33.0 vless-tcp-tls
我们来创造一个CPU能耗比的参数A，使A=下载速度/CPU资源，那么，
xtls-rprx-direct的A=2942/116=25，
vless-tcp-tls的A=2717/191=14
25＞14下载瓶颈的原因是复杂的，多元的，需要长时间进行摸索
CPU的使用率是测上传的时候，测下载的时候xray和v2ray都没满载
我们来创造一个CPU能耗比的参数A，使A=下载速度/CPU资源，那么，
xtls-rprx-direct的A=2942/116=25，
vless-tcp-tls的A=2717/191=14
同意你的观点,实际相同的网速
xtls-rprx-direct的CPU仅有vless-tcp-tls负载的一半
基本反推性能也是一倍左右.(如果网络速度没有瓶颈的话,那么就是约快一倍才对
测下载的时候xray和v2ray都没满载
这就说明别处有瓶颈,导致网速在这个限制,还没想到比较靠谱的可能.
测下载的时候xray和v2ray都没满载
因为都没满载,就说明有别的原因制造了这个速度瓶颈
而这个速度,xray和v2ray都轻松可以跑到(所以CPU未满,速度一致),这样就无法比较了.
(当然同样速度,但是CPU负载即便没满,但相差很大,也可以说明性能相差很大)
CPU的使用率是测上传的时候，测下载的时候xray和v2ray都没满载
你需要把服务端CPU使用一些技术限制到同一个使用率，比如本项目使用的cgroup，并且在客户端进行测速下载的时候，使限制的服务端CPU跑满，比如限制了xray只使用30%的CPU资源，这30%得跑满(这需要自己调整，可以先测一下xray下载一般占用多少CPU，再限制到更小的程度)，这样才能测出差距
或者逆向思维，你用IDM下载一个文件，限速，同样的网速，服务端CPU资源用了多少，这差距也是性能差距
我老暴躁老哥了，嗨呀，能不能先搞懂什么叫性能啊，你从头到尾都只有一搭建一测速，就说差距不大
对于性能差距已经测得很清楚了，2vCPU，下载都没满载就不看，上传xray116.9%没满载，v2ray191%等于满载。根据上传速度可得单位性能吞吐量分别为30.7, 16.3，两者相差明显，但还是与此处所述不同https://raw.githubusercontent.com/badO1a5A90/v2ray-doc/main/performance_test/Xray/img/xray20201202.png
CPU的使用率是测上传的时候，测下载的时候xray和v2ray都没满载
你需要把服务端CPU使用一些技术限制到同一个使用率，比如本项目使用的cgroup，并且在客户端进行测速下载的时候，使限制的服务端CPU跑满，比如限制了xray只使用30%的CPU资源，这30%得跑满(这需要自己调整，可以先测一下xray下载一般占用多少CPU，再限制到更小的程度)，这样才能测出差距
或者逆向思维，你用IDM下载一个文件，限速，同样的网速，服务端CPU资源用了多少，这差距也是性能差距
我老暴躁老哥了，嗨呀，能不能先搞懂什么叫性能啊，你从头到尾都只有一搭建一测速，就说差距不大对于性能差距已经测得很清楚了，2vCPU，下载都没满载就不看，上传xray116.9%没满载，v2ray191%等于满载。根据上传速度可得单位性能吞吐量分别为30.7, 16.3，两者相差明显，但还是与此处所述不同https://raw.githubusercontent.com/badO1a5A90/v2ray-doc/main/performance_test/Xray/img/xray20201202.png
这个问题我觉得我文档中的说明就给予了解释:
- 测试可以体现在不同使用模式下,或不同程序版本下性能有差异.
- 测试代表测试环境下的差异，并不表示绝对差异，也不是每个人使用后的实际性能提升.
- 通常情况下硬件性能越低,XTLS对性能影响越大,尤其是没有AES指令的硬件设备上，会有更多倍数相差.
并且,上传的话,客户端的readV不起作用,也可视作少了很多性能优化,readV大约性能可以提升2 ~ 3倍
纯粹的性能差距只是在于有没有TLS加密上面了,加上机器硬件性能差异.所以体现到最后可能只有一倍差距.
建议增加无aes硬件加速性能排行。那个更有看头
建议增加无aes硬件加速性能排行。那个更有看头
主要是没有设备搭建比较理想的测试环境.