标签：处理 hit user 能力 set 最好 工程 延长 分布
Q: 经常遇到这样的问题，就是我想知道这个网站到底能承受多少个用户，假设我模拟100个用户，按照10%的比例，设置10个用户并发操作。如果平均响应时间（当然现在通过学习你的文章学会了如何使用90%用户的概念）在用户接受的范围内，我就认为该系统能够承受100个用户使用。
因为用户要求支持100个用户，那么我会设置100个用户登录，但是在各个操作中都会设置10个用户并发。
因为我觉得如果要支持100个用户的话，那么这100个用户中有可能会有一些用户存在并发的可能性，我一般把这个可能的并发操作设置为总用户数的10%，如果这种情况下的响应时间满足客户要求，那么就算测试通过。
A: 我觉得你这里要先进一步明确你的性能需求。用户要求支持100个用户，但是这个100用户是什么概念呢？同时在线人数？同时执行某个操作的人数？平均负载？峰值负载？
举个例子，假如说用户要求系统每秒最大可以处理100个登陆请求，那么你需要验证系统的响应能力是否可以达到这个要求。怎么验证呢？你可以使用上面这篇文章中的方法，使用不同的负载来观察系统的响应情况，例如分别使用 10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。
在实际执行时，你会发现随着并发用户数量的逐渐增加，先是每秒事务数增加，而响应时间变化不大； 但当到达某个点时，例如 50 并发用户时，每秒事务数不再随负载的增加而增加，而响应时间的值开始变大，硬件资源和软件资源使用已经饱和；
当负载继续增大，例如到达 75 或 100 并发用户时，响应时间开始明显延长，并且每秒事务数开始下降，硬件资源和软件资源使用完全饱和。
如果根据上面的描述，你可能会发现登陆模块最大能支持的并发用户数只有75。当然，如果考虑到响应时间的要求，可能会只有 50。
你可以按照上面的思路来执行测试，并应用文中提到的方法来对系统的响应能力进行分析，最终得到你的结论。
如果客户只是笼统的提到“想要这个系统能够支持200个用户”，那么你还需要进一步跟客户明确，系统的负载在各个模块之间是如何分布的。然后确认每个模块的性能都是符合要求的，然后再进行多业务的集成测试。
Q: 那么如何测试“用户要求系统每秒最大可以处理100个登陆请求”呢，
是在设置场景的时候在一个场景中设定100个用户，然后每隔多长时间增加几个用户还是在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户……？
A: "在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户"——你可以直接设计一个 100 用户的场景，但是不能只有这一个场景。至于其他场景如何设计，要结合测试的结果来考虑。例如，如果你发现 100 个并发用户的时候平均事务响应时间只有0.2秒，那么系统还可以承受更大的负载，你可以考虑再增加 200/300/400/500 等场景的测试；而如果发现系统在 100 并发用户的情况下响应时间已经是 5 秒，那么应该增加 15/25/50/75 等场景的测试。
没有足够多的数据和样本，单凭一个场景的测试是很难进行分析和得出结论的。
说白了性能测试跟做试验很相似。
A: 性能测试案例中的并发用户数怎么计算得到？
例如：某公司的OA系统，注册用户5000，在线用户2000。
那么，我做性能测试时，设定并发用户为多少呢？
有些固定的经验公式，还是要根据什么得到？
Q:
1.性能需求需要进一步明确：在线用户数量不等于并发用户数量；“在线用户2000”是指的整个系统的负载，那么单个业务模块的负载是多少？要明确系统的平均负载和峰值负载；
2.如果你要验证系统的性能，就不单单是测试系统是否可以承受某个并发量，而是测试系统在各种不同级别的负载下的性能表现，包括吞吐量、响应时间以及资源占用情况，并根据测试的结果找到系统的最佳并发用户数和最大并发用户数——需要参考性能需求；而如果没有或者无法确定性能需求，那么需要根据测试结果来评价系统的性能表现是否可以接受。
就像本文中提到的，分别测试了 10/25/50/75/100 不同级别的负载，假如根据测试结果来看，确定平均事务响应时间必需小于 3 秒，那么根据测试结果可以发现只有并发量为 10 的时候才能满足要求。如果这个并发量明显小于实际负载，那么需要进行性能优化；反过来也是一样，假如明确了系统的平均负载为 50，根据测试结果可以发现，当并发量为 50 时，平均事务响应时间已经超过了 11 秒，如果这个响应时间已经远远大于用户可以忍受的时间，那么同样也需要对系统的性能进行优化。
Q: 单个业务模块的负载是多少？
————————————
这个也是我迫切需要得到的。
当然，如果能直接得到，那是最好。
很多情况下，一个系统初次上线，无法从日志或者别的途径得到准确的单业务负载。对于此类情况，我们应该通过何种分析办法呢？
或者，从另外一个角度讲。
加入现在的OA系统并发虚拟用户设置为100个，而且其它性能未超过要求。那么，是否就能说，这套OA系统支持且暂时只支持100个并发用户。
这里的虚拟用户，是否就可以等同于真正的用户？
，其实性能测试最关键的还是性能测试合理的场景设计和后期测试结果的分析。^_^我也的确存在和HNWPENG一样的问题，也就是如果我要测试一个系统，PM给出了8000最大在线用户/服务器的性能需求，那我该如何设计？是就简单的将目标人数逐步增加到8000人/服务器，还是要同时考虑测试大用户并发的情况，如果要测，那怎么推断在线8000人/服务器的时候，有多少并发用户是合理的呢？还是只是按照我理解你给HNWPENG的回复，就是给出到最大在线人数8000，看这个时候多少并发人数是最佳和最大的？（也就是不考虑测试单独的大并发情况，或者大并发的情况单独测试）
顺便我问一下，如果线下的测试服务器和实际上线的服务器有一定的硬件性能差距，我有点疑惑，该怎么进行相应的性能折算呢？比方线上有40台Xeon 3.0GHz 内存1G的服务器，而线xia只有4~5台Xeon 1,8GHz，内存1G的服务器，如果先进行线下测试的，该怎么折算？还是直接上线进行测试？这点还是比较困惑的，不过还是比较喜欢这种同行的探讨，现在这方面的计算统计还是资料比较少的^_^
A: 1.同意你的看法：性能测试最关键的还是性能测试合理的场景设计和后期测试结果的分析。
也顺便说一下我的想法：性能测试从本质上看也是一种实验，是通过小量的样本来了解总体特种和行为的一种实验。从这个角度来看，场景设计和结果的分析的本质就是“实验设计”和“实验数据的分析”，这其实是统计学研究的范畴。而且这两个方面在其他领域都有很多可参考的经验。所以我的看法是如果想做好性能测试，做好“场景设计和结果的分析”，统计学是一个突破口。
2.拜读过这位“理发师”的文章，他的文章的确在很多方面给人以启发，先赞一下 ^_^ 不过不知道你说的是哪些理论在国内是不是办得到？
3.PM给出了8000最大在线用户/服务器的性能需求……
这正是国内同行经常遇到的问题，无论是客户还是 PM，给出的所谓的性能需求都是这个一个没有太多实际意义的数字。
在继续讨论前，要先说说我对“性能”和“性能测试”的理解。
在我看来，所谓的“性能测试”是“了解系统在一个既定的环境和场景中的性能表现是否与期望的目标一致，并根据测试数据识别性能瓶颈，改善系统性能的过程”。
而“性能”本质上是“并发量与吞吐量（每秒事务数）、响应时间以及资源利用率之间的一种平衡”。
换句话说，性能测试是要去认识一个事物的特性——去了解被测系统在某个环境和场景中的性能如何，然后再比较这个性能是否与预期的目标一致；而不是简单的“验证能否支持某个并发量”。也就是说你的 PM 给出的是一个目标——当然，这个目标还不够明确，而你要做得是测试，并得出数据和结论。
另外，用户或 PM 提出的性能需求的真正目的是要了解“当8000用户/服务器的情况下系统的性能表现是怎样的”，就是说除了并发量还要考虑吞吐量、响应时间和资源利用率。但是对于性能测试工程师来说，也不能仅仅验证 8000 个用户，要验证在各种不同的负载下系统的表现如何——这就包括了 8000 以下的和 8000 以上的，当然，如果发现到了 1000 已经有大量的请求失败，或者响应时间已经到了不可忍受的情况就没有必要非做到 8000 了。
所以在这种情况下，你可以先跟 PM 进一步明确一下这个 8000 用户在线到底是一个什么概念，也可以先分别测试各业务模块，在了解了各个模块性能的基础上进行讨论。
4.如果测试环境与生产环境存在差距，首先应该尽可能的缩小差距。如果实在是无法缩小差距——例如客户那里是小型机，而你连 Server 都没有，那就要在报告中详细的注明你的测试环境和各项配置，说明测试结果在当前环境下有效。一个比较理想的方案是计算每个请求的处理成本，然后统计在并发量变化的情况下处理成本的变化，估算请求数量与软硬件资源利用率的关系——银行不就是计算了个什么查询和跨行交易的成本来向咱们收费的嘛 ^_^
5.哪些是重点可能存在性能瓶颈的模块，就更多的关照这些模块？
同意你的看法。不同的模块、不同的业务处理的确会存在差异，例如只负责提供一个静态页面的模块与需要计算大量数据并动态生成返回内容的模块，在同样的环境下所能提供的吞吐量肯定是有区别的。
Q: 感谢Jackei的回复，的确我遇到的问题可能并不一定是我个人的困惑，也可能是普遍的一种问题。先说说这个：
3.PM给出了8000最大在线用户/服务器的性能需求……
是不是我理解就是说并不一定对PM提出的要求进行一个验证，而是由性能测试工程师对整个系统的性能自行进行验证，以考察系统性能在什么情况下最佳，以及这个最佳是否满足PM提出的要求？至于PM提出的这个最大在线人数8000/服务器我该怎么将他详细化呢，能否光根据于这个数字详细到比方tps有多少，或者hits/second有多少呢？可能PM也不是非常了解这些概念，最多他能提出必须再多少秒内给出响应，那我该怎么进行自行的转化呢？有什么经验公式吗？
4.如果测试环境与生产环境存在差距……
我不是很理解你所说的处理成本的概念，是硬件处理速度的一个折算还是包括其他方面的？我能不能就可以理解为给出当前测试环境中的测试结果，然后根据处理成本从而进行推算在生产环境中的性能？好像有点难度哦，可能还是不知道处理成本的概念或是怎样计算这个处理成本吧^_^
至于Scott Barber的理论，我指的就是User Experience Not Metrix系列文章，他好像倡导的理论就是尽可能的模拟真实的测试环境，就好像用户在线上实际操作那样。我觉得这个挺不错的，也是趋势。不过当我进行实践的时候发现有好多的困难，不仅是模拟的困难（包括各种路径，随机量的模拟，所有用户操作的模拟以及各种情况发生的周全考虑），还包括人力和测试工具予以相应的实现。而现在看了一些同行的文章和数据，似乎都是主要针对重点模块，而没有完全实现Scott Barber所倡导的理论，是不是出于人力和测试成本的考虑以外，还是实现起来的确有难度？或者还没有较为成熟的一种运用？
A: @watercloset
1.完全真实的模拟用户的真实场景是很困难的，至少在目前来看，在绝大多数情况下，我们只能是尽可能的无限接近用户的真实场景。
2.由性能测试工程师对整个系统的性能自行进行验证，以考察系统性能在什么情况下最佳，以及这个最佳是否满足PM提出的要求
——》对，这是我的理解。
3.至于PM提出的这个最大在线人数8000/服务器我该怎么将他详细化呢
——》我所指的细化是：
●如果有多个业务模块，这8000用户是如何分布在不同的业务模块的；
●如果是 A 模块1000，B模块3000，C模块4000，那么针对每个模块的并发用户数会有多少，不同业务模块的响应时间要求是多少——响应时间限制是评判最大并发用户数的一个关键指标
4.有一种算法是 并发用户数＝注册用户数×5％
5.对于处理成本，有一种方法是计算每个请求所消耗的 CPU 时间、内存、磁盘 I/O 时间以及网络带宽，如果有兴趣的话，可以看一下下面这篇文章
标签：处理 hit user 能力 set 最好 工程 延长 分布
原文地址：http://www.cnblogs.com/zi-yao/p/7340906.html
