[翻译]编写高性能 .NET 代码 第一章：性能测试与工具 -- 平均值 vs 百分比

平均值 vs 百分比

在考虑要性能测试的目标值时，我们需要考虑用什么统计口径。大多数人都会首选平均值，但在大多数情况下，这个正确的，但你也应该适当的考虑百分数。但你有可用性的要求，作为性能测试的目标里肯定会有用百分比作的要求。举个栗子：“数据库请求的平均延迟必须小于10ms，95%是请求必须小于100ms”
。。。（这里我省略了对“95%是请求必须小于100ms”的翻译说明，我觉得中国的程序猿应该看得懂我翻译的那句话）

1，2，2，4，5，5，8，10，10，11，11，11，15，23，24，25，50，87

举个栗子，上面有18个测试下来的值（已经过排序了的），的平均耗是17ms，但有5%的访问超过50ms。如果你刚好只看平均值，你一定会认为一切正常。但当你用了百分比作为指标，你就会知道一些偶发的GC操作会影响到你的访问质量。
百分比是高可用性的最重要指标。如果你需要更高的可靠性，就需要提出一个更高的百分数指标。通常来说99%已经很好了，但你还会可能有99.99% 99.999%，甚至更高的指标，但通常来说，决定采用这些指标数字取决于业务，而不是开发。

这里作为翻译的我，来补一些关于百分比的数据
99% 允许每年服务器挂 3.65 天（多让人尴尬的数据啊，但我相信很多公司服务器不一定达能到这个要求）
99.9% 允许每年挂 8.76 小时（1年出了一次较大的事故，基本就用完额度了）
99.99% 允许每年挂 52.6 分钟（1年只能出一次小的事故，还得是能立即解决的）
99.999% 允许每年挂 5.26 分钟（如果真的发生小于这个时间的事故，对于用户来说一般很难有感知，但是在淘宝双十一零点之后的一个小时内碰上的话 (=@__@=) ）
99.9999% 允许每年挂 31 秒（写一个程序在一年的时间里只往控制台输出 hello world的同时还得祈求上帝保证机房不要断电 O(∩_∩)O！）

百分比是一个重要的指标，是因为他可以帮助你了解你的系统，即使通过平均值观察到，你的系统一切正常，但是只有90%的用户访问满足了目标，也会意味着，你还有10%的用户访问还有可以改进的空间。要解决这这部分请求问题，需要的更多是商业上的考量，因为这里会存在一个递减回报的问题，因为提升最后的1%要花的时间不是一般的多。
对于上面的例子“有95%的访问请求满足了50ms以内的需求”，但数据源来说，不符合统计学上对样本数量的要求，至少要要相同数量级的样本才行。要描述 99% 需要统计100个样本，要描述 99.9% 则至少要1000个样本，并以此类推。

再举一个作为翻译我的栗子
话说当年做的页游上线，在开服到了几百人（>500）的时候玩家会觉得比较卡，登陆服务器看了一下cpu和网络情况都不是很高（<30%)，内存占也没啥问题。经过后来多方努力，发现是用户首次进入游戏时，为了数据安全，这时候初始化数据库的操作是同步的，而不是异步的。再加上dogse引擎的限定，主逻辑是跑在单线程的队列上，这就导致开服时主线程的阻塞会比较严重。每个玩家卡个200ms，同时有3个玩家进入，剩下的玩家自然会觉得卡了。

对于本书最重要的，而起是要重复说三遍的观点是：
测量，测量，测量
你要知道，如果没有准确的测量，在解决性能相关问题时，你只能按照自己的经验和感觉来判断那里有性能问题。这会存在2个问题：
首先：假设你的感觉是对的，找到了一个性能问题的地方，但你不知道当你修改了这里后，对性能提升了多少
其次：我也不可能告诉你那里经常犯错了。举个栗子（这个栗子我没看懂）：在分析一个应用占用里很多非托管内存的问题，我们最初假设是认为在某处加载了一个很大的数据。随后安排开发人员做排查工作，通过禁止某些组件的加载，还调试了转储过程（dump)里堆的数据。结果让我们很吃惊，大部分内存的开销来自于组件（Assembly）加载，而不是我们之前所想的数据加载
如果没有工具做测量，那么性能优化就是没意义的。性能优化是一个连续的过程，你需要有自己的工具来对这个过程做记录。下面的章节将介绍一些常见的工具。恩大部分是免费的，有一款收费的，但是是vs专业版附带的，所以你懂的。
相关文章：
[翻译]编写高性能 .NET 代码 第一章：性能测试与工具 -- 选择什么来衡量

原文地址：http://www.cnblogs.com/yahle/p/6530827.html

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注