-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
评测方法不具有实际意义 #4
Comments
我知道你可能不会看完整个测试报告,所以我把其中两句话在此引用出来 更多详情在 #2 中有大量地、重复地进行讨论过了,基本情况和你说的一致,这个项目一直以来就按照这种思维进行测试的 |
首先,理论性能不用实验室理想环境测试还应该怎么测试. 你的这个说法是没错的,但测试方法全部做到了,甚至做的更好. @SekiBetu 说的很精准.整个试验中就是刻意制造了瓶颈的低算力硬件(所有测试中满负荷),并且是客户端瓶颈(更具实际意义如硬路由),而其他部分均不会成为瓶颈(包括AD的数据制造接收能力,网络带宽等等),然后算出的不同软件的满载带宽. 所以这个测试成为了相同算力下,选用不同软件,产生实际性能差异的对比. 因此,评测方法很具有实际意义 另外关于你其他说法的补充,我文档里也有说明
|
其实测试方式中第一句我就说了 要测试协议之间性能差距,那么必然是硬件CPU负荷满的情况下,其他变量不变,仅有协议组合差别下测试的情况才是有意义的。 然后下面的方式都是围绕这个构建的测试模式 |
测试通过合理的方式测试得出了不同软件/协议组合的性能差异. 测试的对于开发者和用户实际意义在于
这也是我在文档中第一句就提到了的. |
首先cgroup限制CPU使用时间只能是一种极不准确的模拟,cgroup可以限制cache使用吗,可以限制内存带宽吗,可以限制指令集特性吗,可以限制TDP吗?而且cgroup在x86上模拟出来的性能跟用户目标硬件的arm和mips怎么比较?用cgroup限制出来的硬件反而不代表任何实际硬件。 帮助开发者开发当然没问题,具有实验室意义。但是所谓实际意义就是用户实际工况下产生的效果,如果你的测试不能代表实际工况,那用评测指标来引导用户便是一种误导行为。 就现在的评测结果来看,绝大多数人根本没有大于100Mbps的国际线路,也不是将代理软件运行到cgroup限制的Xeon服务器上,所以具体的评测结果与实际工况并没有相关性。 我的推测是大多数用户的硬件算力要大于他的国际线路的带宽,这种情况下选用哪种软件都不会产生性能上的实际区别。如果要用这个评测去证明选用软件会产生性能差异,就要证明有用户实际使用的常用硬件会导致算力瓶颈低于线路带宽,而不是你人为弄残废的一个模拟环境。 |
严格来说,很多基于实验室环境的测试都可以这么说:这个结论只有实验室意义不具有用户环境意义,因为实验室环境只能模拟用户实际环境。但是总要有近似的办法,变量可控且可比较的办法去测试性能才行。 |
实际状况下的实际硬件情况千千万,本来就不可能被代表,协议或软件调用的资源和效能也不近相同,这时使CPU满负荷不恰好是实际意义吗?代表软件在当前情况下的最大性能,而是不是cgroup不重要。
我不知道你在哪看到的结果,但你这句话肯定错的,现在美西的vps卖最多吧,大多数都不止100Mpbs,搬瓦工美西差不多都是1G共享,跑个几百Mpbs没问题,难道你说的绝大部分人用的都是香港小水管?你要说本地带宽我还认为有可能。
除了桌面端,我不敢赞同你的推测,而我也有个推测与你恰恰结论相反,大多数用户根本跑不满本地带宽,硬件算力、不同软件的性能差异有时候是很大影响因素,要不然为啥软路由这么火?大家都是吃饱了撑买性能好的CPU来翻墙?为啥都说SS和trojan-go快,说到v2ray就嫌慢? |
Xtls和splice是实实在在的巨大提升,测试也只是反应了这一事实而已。 |
何不食肉糜 |
测试结果用的千兆IPLC(大误); |
已经解释过了,测试验证的是,同样的环境下不同软件/协议组合的性能高低,并不表示绝对差异,也不是每个人使用后的实际性能提升.
准确的说,测试可以代表实际工况的理论表现,只是不能代表每一个用户实际工况的具体的精确差异.但,重要的是,测试可以证明相同的实际工作环境下,不同软件/协议组合的性能有差异.
PS: 我喜欢上面回复中的一句话. 开发者是车头,应该去追求性能和优化,尽力给所有人带来更好的体验. |
据我所知CN2-GIA-E虽然标称2.5Gbps,但这这是网口指标,实际性能远低于标称,高峰期实测甚至低到10Mbps,然而这些瓶颈都不在本地可控范围内,也许是太多人开始使用KCP这类环境污染协议。我很奇怪,以CN2-GIA-E线路高昂费用,然后接上一个廉价低算力的软路由,造成软路由因廉价成为瓶颈,如果用户在这里有经济理性的话,这应该是不会发生的事情。 那么所谓用户实际情况有三种情况:
优化当然是好事。假如性能优化了十倍二十倍,但优化的只是整个系统里占据10%的部分,那整个系统也就提升了10%。这就是这类microbenchmark常见脱离实际的问题所在。 |
你用不到不等于别人用不到.
任何优化都不一定所有人都能享受到,觉得优化能服务到的用户不是全部就不做了吗? |
行了行了,已经知道你不懂什么叫性能测试了,李说是,辣就是,你就当我们这群人自娱自乐行了吧😅 @badO1a5A90 下次把文档里类似以下内容的字体放大点然后加粗,有必要的话写三遍,以免某些眼瞎的人来指责说误导路人
|
他说不具有实际意义,那就是不具有实际意义,为什么你们知道吗,因为他这个位置很尴尬,他说的话就像是一位癌症晚期患者说的话。 咋那个项目的赞都挺多的,开发者一到这就拉了胯呢 |
楼上在干嘛????? |
请大家友善讨论,勿搞人身攻击. |
也罢,为了避免无谓的骂战,此贴终结. |
人身攻击,没必要吧? |
虽然测试结果符合预期,但测试环境不能代表典型用户环境。一是在算力上,Xeon很少有用户使用。二是在带宽上,没有用户具有10Gb国际专线。实验室环境测试指标再高,并不会直接转化为用户实际效果。
用户实际环境中,如果是高算力低带宽,那么TLS开销便不成为瓶颈,这个吞吐指标便没有意义。如果是低算力高带宽,TLS开销才可能成为瓶颈。但是考虑到国际线路高带宽的成本远高于提高用户设备算力的成本,第二种情况是罕见的。
所以这个评测如果要具有实际意义,必须在TLS开销可能成为瓶颈的低算力硬件上,定位不同软件的满载带宽。如果用户的可用国际带宽高于测得的满算力带宽,选用不同软件才可能产生实际性能差异。
The text was updated successfully, but these errors were encountered: