诚实村和谎言村
总览
读取供应商提供的性能结果本身就是一项技能。 公平地比较来自不同供应商的数字可能很困难,甚至更难估计产品在系统中的行为。
谎言与统计
最高性能–制造商保证不超过给定等级
—计算机体系结构,一种定量方法。 (第一版)
为什么这么难给出一个可靠的表现数字?
- 延迟和吞吐量不遵循正态分布,这是数学上严格的统计信息的基础。 这意味着您正在建模的东西不是公认的数学模型。
- 您可以做出许多不同的假设,测试解决方案的方法以及表示结果的方法。
- 您需要使用基准来衡量某些指标,但是这些基准要么是a)不标准,b)不代表您的用例,要么c)可以以无济于事的方式进行优化。
- 供应商了解他们的产品,并明智地为其产品选择最佳的硬件。 如果您只考虑一种产品,则此方法效果最佳。 即使您的组织允许您购买可选的硬件,多产品系统也不是所有产品的最佳硬件解决方案。
- 报告最理想的测试结果很容易,并且不包括效果不佳的结果。
任何体面的供应商都将使用其基准来优化其解决方案。 不利的一面是,与供应商尚未测试的用例(例如您的用例)相比,该解决方案针对其报告的基准进行了更多优化。
顺便说一句:看到供应商在对解决方案进行基准测试时想到了哪些用例,我经常觉得很有趣。 这可以很好地表明a)这样做的好处,b)在设计解决方案时所做的假设,以及c)一般已经使用了它。
我们应该忽略所有基准吗?
延迟百分比
百分位 | N分之一 | 规模 | 笔记 |
---|---|---|---|
50% | “典型” |
1倍
| 这很好地表明了可能性。 这是您可以使用的最乐观的数字 |
90% | 一入 十 |
2x-3x
| 这更好地表明了性能 如果在真实,复杂的系统上进行了测试。 |
99% | 一入 100 |
4x-10x
| 对于简化系统的基准,这是一个更好的选择 表明您可以实际实现的目标 |
99.9% | 一入 1,000 |
10x-30x
| 对于简化系统的基准,这是保守的 表明您可以期望的结果。 |
99.99% | 一入 10,000 | 20x-100x | 这个数字很好,但很难复制, 即使是相同的基准测试,更不用说其他用例了。 见下文 |
99.999% | 一入 100,000 |
变化
| 这个数字几乎不可能在系统之间重现。 见下文 |
可重复编号所需样品数量的指南
Java还有一个附加功能,即在预热时变得更快。 过去,我曾提倡删除这些热身指标,但是鉴于微观基准指标过于乐观,如果没有其他原因,我更倾向于将其包括在内。 对于可重现的百分位数,我的经验法则是:对于N分之一,对于简单的微基准,您需要N ^ 1.5个样本,对于复杂的系统,您需要N ^ 2个样本。
百分位 | N分之一 | 简单测试 样本 | 复杂测试 样本 |
---|---|---|---|
90% | 十分之一 | 〜30 | 〜100 |
99% | 十分之一 | 〜300 | 〜10,000 |
99.9% | 千分之一 | 〜30,000 | 约一百万 |
99.99% | 十分之一 | 约一百万 | 约一亿 |
99.999% | 十万分之一 | 约三千万 | 〜100亿 |
99.9999% | 1,000,000分之一 | 约十亿 | 约一万亿 |
最高或100% |
决不
|
无限的
|
无限的
|
基于这个经验法则,我认为不能凭经验来衡量实际的最大值。 即便如此,不报告一切也不令人满意。 一些基准测试报告什么是“样本中最差”,总比没有好,但很难复制。 为了减轻实际系统中的预热成本,我建议应预先加载对延迟至关重要的类,如果在应用程序启动时未预热它们,则应预先加载。
综上所述
如果您正在寻找可以使用的性能指标,我建议使用99%作为对实际系统中期望值的良好指示。 如果要谨慎,请使用99.9%。 如果未给出此数字,我假设您可能会获得平均或典型延迟的10倍左右,以及供应商在理想条件下可获得的吞吐量的1/10倍。 通常,这仍然绰绰有余。 如果供应商报价的性能指标接近您的要求,或者更糟糕的是根本没有报价,请当心! 令我惊讶的是,有多少供应商会说他们快速,快速,快速,高效,高性能,但根本没有引用任何数字。
参考: Vanilla Java博客上来自我们的JCG合作伙伴 Peter Lawrey的谎言,统计数据和供应商 。
翻译自: https://www.javacodegeeks.com/2013/04/lies-statistics-and-vendors-2.html
诚实村和谎言村