描述性统计与性能结果分析（续）

有一点疑问：google的并发用户数支持到75个就已经慢成这样，但是在实际使用的时候基本都是很快能打开的，难道做为google，同一时间的并发访问量从来没有过75个？

在我自己的性能测试过程中，经常遇到这样的问题，就是我想知道这个网站到底能承受多少个用户，假设我模拟100个用户，按照10%的比例，设置10个用户并发操作。如果平均响应时间（当然现在通过学习你的文章学会了如何使用90%用户的概念）在用户接受的范围内，我就认为该系统能够承受100个用户使用。这样对吗？

@sunfy
有一点疑问：google的并发用户数支持到75个就已经慢成这样，但是在实际使用的时候基本都是很快能打开的，难道做为google，同一时间的并发访问量从来没有过75个？
——原因可能并不是 Google 的问题，也有可能是网络或者其他原因，而这个也正是需要在测试结束后需要分析的——响应时间在网络传输、Web server 以及 DB server 上的分布情况，然后根据实际的结果来识别瓶颈和调优。

不太明白你为什么“按照10%的比例，设置10个用户并发操作”，可以再详细说说吗？

因为用户要求支持100个用户，那么我会设置100个用户登录，但是在各个操作中都会设置10个用户并发。

因为我觉得如果要支持100个用户的话，那么这100个用户中有可能会有一些用户存在并发的可能性，我一般把这个可能的并发操作设置为总用户数的10%，如果这种情况下的响应时间满足客户要求，那么就算测试通过。

@sunfy
我觉得你这里要先进一步明确你的性能需求。用户要求支持100个用户，但是这个100用户是什么概念呢？同时在线人数？同时执行某个操作的人数？平均负载？峰值负载？

举个例子，假如说用户要求系统每秒最大可以处理100个登陆请求，那么你需要验证系统的响应能力是否可以达到这个要求。怎么验证呢？你可以使用上面这篇文章中的方法，使用不同的负载来观察系统的响应情况，例如分别使用 10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。

在实际执行时，你会发现随着并发用户数量的逐渐增加，先是每秒事务数增加，而响应时间变化不大；
但当到达某个点时，例如 50 并发用户时，每秒事务数不再随负载的增加而增加，而响应时间的值开始变大，硬件资源和软件资源使用已经饱和；
当负载继续增大，例如到达 75 或 100 并发用户时，响应时间开始明显延长，并且每秒事务数开始下降，硬件资源和软件资源使用完全饱和。

如果根据上面的描述，你可能会发现登陆模块最大能支持的并发用户数只有75。当然，如果考虑到响应时间的要求，可能会只有 50。
你可以按照上面的思路来执行测试，并应用文中提到的方法来对系统的响应能力进行分析，最终得到你的结论。

不知道能否理解我说的意思？

恩，看了您上面的回复，感觉功力又增进不少啊，哈哈。

其实我之所以那么做，是想要真实的模拟客户的操作，因为，我想，在客户使用B/S结构的系统的时候，可能会有100个人登录使用，而这100个人中，又有可能有10个，或者5个（根据某些操作的使用频率觉得并发数）用户在某些操作中可能存在并发的情况。

而我录制的脚本中，也通常都是具有一连串性的动作，比如用户登录、浏览公告、填写报表、查询等。

我觉得我的这种测试是不是包含了测试同时在线人数，同时执行某个操作的人数这两种情况？因为，客户往往只是说我想要这个系统能够支持200个用户，他说的这个用户数一般都是希望系统能够支持的最大在线用户数，而我根据他们的要求，考虑一些可能在系统中某些操作存在并发的情况，所以才会在操作中融入10%左右的并发情况。

@sunfy
如果客户只是笼统的提到“想要这个系统能够支持200个用户”，那么你还需要进一步跟客户明确，系统的负载在各个模块之间是如何分布的。然后确认每个模块的性能都是符合要求的，然后再进行多业务的集成测试。

那么如何测试“用户要求系统每秒最大可以处理100个登陆请求”呢，
是在设置场景的时候在一个场景中设定100个用户，然后每隔多长时间增加几个用户还是在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户……？

@sissy[匿名]
"每隔多长时间增加几个用户"——如果是要验证系统的响应能力，不赞成这种方法；

"在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户"——你可以直接设计一个 100 用户的场景，但是不能只有这一个场景。至于其他场景如何设计，要结合测试的结果来考虑。例如，如果你发现 100 个并发用户的时候平均事务响应时间只有0.2秒，那么系统还可以承受更大的负载，你可以考虑再增加 200/300/400/500 等场景的测试；而如果发现系统在 100 并发用户的情况下响应时间已经是 5 秒，那么应该增加 15/25/50/75 等场景的测试。

没有足够多的数据和样本，单凭一个场景的测试是很难进行分析和得出结论的。

说白了性能测试跟做试验很相似。

性能测试案例中的并发用户数怎么计算得到？
例如：某公司的OA系统，注册用户5000，在线用户2000。
那么，我做性能测试时，设定并发用户为多少呢？
有些固定的经验公式，还是要根据什么得到？
一直困扰。
想听听jackei的看法……

@HNWPENG
1.性能需求需要进一步明确：在线用户数量不等于并发用户数量；“在线用户2000”是指的整个系统的负载，那么单个业务模块的负载是多少？要明确系统的平均负载和峰值负载；
2.如果你要验证系统的性能，就不单单是测试系统是否可以承受某个并发量，而是测试系统在各种不同级别的负载下的性能表现，包括吞吐量、响应时间以及资源占用情况，并根据测试的结果找到系统的最佳并发用户数和最大并发用户数——需要参考性能需求；而如果没有或者无法确定性能需求，那么需要根据测试结果来评价系统的性能表现是否可以接受。

就像本文中提到的，分别测试了 10/25/50/75/100 不同级别的负载，假如根据测试结果来看，确定平均事务响应时间必需小于 3 秒，那么根据测试结果可以发现只有并发量为 10 的时候才能满足要求。如果这个并发量明显小于实际负载，那么需要进行性能优化；反过来也是一样，假如明确了系统的平均负载为 50，根据测试结果可以发现，当并发量为 50 时，平均事务响应时间已经超过了 11 秒，如果这个响应时间已经远远大于用户可以忍受的时间，那么同样也需要对系统的性能进行优化。

不知道上面说的够不够明白？

单个业务模块的负载是多少？
————————————
这个也是我迫切需要得到的。
当然，如果能直接得到，那是最好。
很多情况下，一个系统初次上线，无法从日志或者别的途径得到准确的单业务负载。对于此类情况，我们应该通过何种分析办法呢？

或者，从另外一个角度讲。
加入现在的OA系统并发虚拟用户设置为100个，而且其它性能未超过要求。那么，是否就能说，这套OA系统支持且暂时只支持100个并发用户。
这里的虚拟用户，是否就可以等同于真正的用户？

@sunfy
任何的测试都无法得出准确的数据，从测试中，我们只能把握大概。Jackei对google的测试实践，是在怎样的环境下进行的？得出的75的并发用户是在特定环境下的。整个环境中的并发用户肯定不止75个

首先先支持一下Jackei，其实性能测试最关键的还是性能测试合理的场景设计和后期测试结果的分析。^_^我也的确存在和HNWPENG一样的问题，也就是如果我要测试一个系统，PM给出了8000最大在线用户/服务器的性能需求，那我该如何设计？是就简单的将目标人数逐步增加到8000人/服务器，还是要同时考虑测试大用户并发的情况，如果要测，那怎么推断在线8000人/服务器的时候，有多少并发用户是合理的呢？还是只是按照我理解你给HNWPENG的回复，就是给出到最大在线人数8000，看这个时候多少并发人数是最佳和最大的？（也就是不考虑测试单独的大并发情况，或者大并发的情况单独测试）

顺便我问一下，如果线下的测试服务器和实际上线的服务器有一定的硬件性能差距，我有点疑惑，该怎么进行相应的性能折算呢？比方线上有40台Xeon 3.0GHz 内存1G的服务器，而线上只有4~5台Xeon 1,8GHz，内存1G的服务器，如果先进行线下测试的，该怎么折算？还是直接上线进行测试？这点还是比较困惑的，不过还是比较喜欢这种同行的探讨，现在这方面的计算统计还是资料比较少的^_^

对了，再补充一些，不好意思，呵呵。我看了Scott Barber关于性能测试的理论，不知道Jackei是否拜读过？感觉好像要做到他理论上面说的那样，好像以目前国内的情况是不是办得到？问题是有必要花如此的成本吗？国内给我的感觉还是比较实用的，就是哪些是重点可能存在性能瓶颈的模块，就更多的关照这些模块？Jackei你怎么认为的？^_^

@HNWPENG
抱歉，最近几天工作太繁忙，回到家就不愿动脑子想事情了，所以迟迟没有答复 ^_^
今天终于搞掂了 Report，就把你的问题和 watercloset 的问题一并答复了～


@watercloset
好多内容啊，要分解开来一个个讨论 ^_^

1.同意你的看法：性能测试最关键的还是性能测试合理的场景设计和后期测试结果的分析。
也顺便说一下我的想法：性能测试从本质上看也是一种实验，是通过小量的样本来了解总体特种和行为的一种实验。从这个角度来看，场景设计和结果的分析的本质就是“实验设计”和“实验数据的分析”，这其实是统计学研究的范畴。而且这两个方面在其他领域都有很多可参考的经验。所以我的看法是如果想做好性能测试，做好“场景设计和结果的分析”，统计学是一个突破口。

2.拜读过这位“理发师”的文章，他的文章的确在很多方面给人以启发，先赞一下 ^_^ 不过不知道你说的是哪些理论在国内是不是办得到？

3.PM给出了8000最大在线用户/服务器的性能需求……
这正是国内同行经常遇到的问题，无论是客户还是 PM，给出的所谓的性能需求都是这个一个没有太多实际意义的数字。

在继续讨论前，要先说说我对“性能”和“性能测试”的理解。

在我看来，所谓的“性能测试”是“了解系统在一个既定的环境和场景中的性能表现是否与期望的目标一致，并根据测试数据识别性能瓶颈，改善系统性能的过程”。
而“性能”本质上是“并发量与吞吐量（每秒事务数）、响应时间以及资源利用率之间的一种平衡”。

换句话说，性能测试是要去认识一个事物的特性——去了解被测系统在某个环境和场景中的性能如何，然后再比较这个性能是否与预期的目标一致；而不是简单的“验证能否支持某个并发量”。也就是说你的 PM 给出的是一个目标——当然，这个目标还不够明确，而你要做得是测试，并得出数据和结论。

另外，用户或 PM 提出的性能需求的真正目的是要了解“当8000用户/服务器的情况下系统的性能表现是怎样的”，就是说除了并发量还要考虑吞吐量、响应时间和资源利用率。但是对于性能测试工程师来说，也不能仅仅验证 8000 个用户，要验证在各种不同的负载下系统的表现如何——这就包括了 8000 以下的和 8000 以上的，当然，如果发现到了 1000 已经有大量的请求失败，或者响应时间已经到了不可忍受的情况就没有必要非做到 8000 了。

所以在这种情况下，你可以先跟 PM 进一步明确一下这个 8000 用户在线到底是一个什么概念，也可以先分别测试各业务模块，在了解了各个模块性能的基础上进行讨论。

4.如果测试环境与生产环境存在差距，首先应该尽可能的缩小差距。如果实在是无法缩小差距——例如客户那里是小型机，而你连 Server 都没有，那就要在报告中详细的注明你的测试环境和各项配置，说明测试结果在当前环境下有效。一个比较理想的方案是计算每个请求的处理成本，然后统计在并发量变化的情况下处理成本的变化，估算请求数量与软硬件资源利用率的关系——银行不就是计算了个什么查询和跨行交易的成本来向咱们收费的嘛 ^_^

5.哪些是重点可能存在性能瓶颈的模块，就更多的关照这些模块？
同意你的看法。不同的模块、不同的业务处理的确会存在差异，例如只负责提供一个静态页面的模块与需要计算大量数据并动态生成返回内容的模块，在同样的环境下所能提供的吞吐量肯定是有区别的。

嘿嘿，感谢Jackei的回复，的确我遇到的问题可能并不一定是我个人的困惑，也可能是普遍的一种问题。先说说这个：
3.PM给出了8000最大在线用户/服务器的性能需求……
是不是我理解就是说并不一定对PM提出的要求进行一个验证，而是由性能测试工程师对整个系统的性能自行进行验证，以考察系统性能在什么情况下最佳，以及这个最佳是否满足PM提出的要求？至于PM提出的这个最大在线人数8000/服务器我该怎么将他详细化呢，能否光根据于这个数字详细到比方tps有多少，或者hits/second有多少呢？可能PM也不是非常了解这些概念，最多他能提出必须再多少秒内给出响应，那我该怎么进行自行的转化呢？有什么经验公式吗？
4.如果测试环境与生产环境存在差距……
我不是很理解你所说的处理成本的概念，是硬件处理速度的一个折算还是包括其他方面的？我能不能就可以理解为给出当前测试环境中的测试结果，然后根据处理成本从而进行推算在生产环境中的性能？好像有点难度哦，可能还是不知道处理成本的概念或是怎样计算这个处理成本吧^_^

至于Scott Barber的理论，我指的就是User Experience Not Metrix系列文章，他好像倡导的理论就是尽可能的模拟真实的测试环境，就好像用户在线上实际操作那样。我觉得这个挺不错的，也是趋势。不过当我进行实践的时候发现有好多的困难，不仅是模拟的困难（包括各种路径，随机量的模拟，所有用户操作的模拟以及各种情况发生的周全考虑），还包括人力和测试工具予以相应的实现。而现在看了一些同行的文章和数据，似乎都是主要针对重点模块，而没有完全实现Scott Barber所倡导的理论，是不是出于人力和测试成本的考虑以外，还是实现起来的确有难度？或者还没有较为成熟的一种运用？

@watercloset
1.完全真实的模拟用户的真实场景是很困难的，至少在目前来看，在绝大多数情况下，我们只能是尽可能的无限接近用户的真实场景。

2.由性能测试工程师对整个系统的性能自行进行验证，以考察系统性能在什么情况下最佳，以及这个最佳是否满足PM提出的要求
——》对，这是我的理解。

3.至于PM提出的这个最大在线人数8000/服务器我该怎么将他详细化呢
——》我所指的细化是：
●如果有多个业务模块，这8000用户是如何分布在不同的业务模块的；
●如果是 A 模块1000，B模块3000，C模块4000，那么针对每个模块的并发用户数会有多少，不同业务模块的响应时间要求是多少——响应时间限制是评判最大并发用户数的一个关键指标

4.有一种算法是 并发用户数＝注册用户数×5％

5.对于处理成本，有一种方法是计算每个请求所消耗的 CPU 时间、内存、磁盘 I/O 时间以及网络带宽，如果有兴趣的话，可以看一下下面这篇文章

Using Transaction Cost Analysis for Site Capacity Planning
http://www.microsoft.com/technet/prodtechnol/comm/comm2002/plan/cs02tcas.mspx

呵呵，我基本理解了Jackei的思想，不少理论都是这样说的，看来还是要在实践中实际体会。不过还是Jackei的帮助，呵呵，毕竟这方面的东西相对较少，我会一直关注Jackei的Blog的，挺有趣的哈^_^

@watercloset
嗯，也感谢您参与讨论，如果有兴趣，这种讨论可以伴随这工作的不断开展继续下去 ^_^

收获太大了,基本上回应了一直困惑我的问题.
那个并发用户数和同时提交的集合点有什么区别.

@阿甘[匿名]

呵呵，你的看法呢？

最大用户数与注册用户数及最大并发用户数之间本身没有必然联系。一般根据特定时间段的峰值来进行计算。如注册用户数为2000，按照行业标准一般峰值使用人数为5％－10％，也可以通过前期项目进行统计后，得到较为准确的百分数。再根据Ramp-up增量加压的方式，确定最终的峰值使用人数。该性能的转折点，可以参考以下几个指标(吞吐量、点击率、磁盘I/O、cpu以及Memory等)
。通过loadrunner自带的anaysis分析器,生成的html在线性能测试报告，也可以直接导出Excel文档进行统计。根据以上指标，针对服务器发生性能瓶颈的转折点，可以倒推出实际的服务器所能承受的最大用户数目，该数码可为产品服务器选型提供参考依据，如：IBM的tpmc值推算方法。

问个弱弱的问题：那两张图表是通过什么工具生成出来的？别拍我~~^_^

@xingcyx

用 Excel 做的 ^_^

拜读了大作，想问几个问题：
1、response time 这个指标是怎么得来的。loadrunner里有两个指标和这个相关，分别是transcation response time 和 hits per second，transaction针对的是一个事务的概念，对用户的意义大，hits per second 是针对服务器而言，反除后得到response time，其实按照我理解和经验这个指标对客户的意义不大，2－5－10也不能作为分析的标准。
2、“响应时间在网络传输、Web server 以及 DB server 上的分布情况”这个是测试工程师查找问题很重要的前提条件，我现在进行分析的步骤是这样的：将transaction进行分解，区分出webserver的和dbserver的，例如静态，动态页面，访问数据库动作。但是这样得出的数据总感觉不是很准确而且基本是不考虑网络传输的（因为基本的理解是传输如果不超过阀值，我们就认为基本没什么影响），原因在哪却没找到，想请问您是怎么分析的？
3、您说了推断并发用户数的方法，但是我认为测试工程师应该严谨，而行业这些方法对于测试目标没有太大的意义，大概的意义可能在测试成本的估算上。测试工程师应该严谨，我做过很多的性能测试项目，我给pm的回答就是，要不对业务进行调研，要不就只能给出最大的和最优的性能指标。进行业务调研，最起码也要得到，该系统的每月访问量，数据预计膨胀速度，忙时闲时，峰值时间等等，最好还能得到那些事务是访问量大的，用户关心的等等，如果得不到这些指标，就只应该给出最大得和最优得性能指标，其实离开这些，最大和最优的意义也不是很大了。您认为呢？
4、不知您是否遇到性能曲线异常的情况，这是困扰我很久的一个问题，一般的性能曲线应该是上凸的，也就是说性能应该是随着用户数的提升，达到最优的性能，然后下降到最大性能并出现急剧下降的拐点，但是我遇到好几次，性能是下凸的，也就是性能曲线持续下降突然持续升高，然后回归正常。您知道问题所在吗？

@wufeiwufei
呵呵，挨个回复一下吧。

1.图中的 Response Time 在这里意味着 Transaction Response Time；您提到的“hits per second 是针对服务器而言，反除后得到response time”，不太明白您的意思 ^_^
对于“2－5－10也不能作为分析的标准”，上面我也说了：当然您也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。

2.您提到“得出的数据总感觉不是很准确而且基本是不考虑网络传输的”，我不太明白您为什么“总感觉不是很准确”，也想听听您具体的分析方法（最好有个实际的例子）。
另外，对于网络传输的时间，我的看法是：不是不考虑，而是避免这种非关键因素成为影响性能的因素——因为通常我们要测试的是系统的响应能力，而不是考察网络——当然，如果你的目的是在解决方案中作一个给用户的推荐网络配置，那就是另外一回事了。
简单说，如果您的测试环境是一个独立的局域网，并且所有的 Server 和测试用机都是使用 1000M 的网卡，并通过一台 1G 的交换机连接在一起，那么网络传输的影响应该可以忽略不计。

3.不知道您的留言中提到的“推断并发用户数的方法”是指的哪一段？看您后面的留言，似乎咱们的看法相差并不大，如果您有兴趣，也可以先看看“《LoadRunner没有告诉你的》之六——获取有效的性能需求”（http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html），如果觉得分歧比较大，咱们可以接着再讨论。^_^

4.您提到“性能应该是随着用户数的提升，达到最优的性能，然后下降到最大性能并出现急剧下降的拐点”，但是实际测试中未必是这样。当系统达到最佳负载后，随着并发用户数的继续增加，响应时间会一直平稳的增加直到超过用户可以忍受的最大范围。
对于您提到的这种情况，是否对同一被测对象重复多次测试得到的结果都是一样？每次测试是否都获取尽可能多的采样？另外，我想您需要提供更多的有关被测对象和您所用的测试方法的信息，以供分析和讨论。

@Jackei
1、hits per second ，是每秒的请求次数，用1除以这个值，得到每次请求的响应时间，也就是服务器的response time per hit 。我的意思是如果是这样得来的response time，那么2－5－10秒这个对用户的标准就没什么意义，当然您并不是这个意思。
2、我早几年用的是was，was有两个指标ttfb，ttlb。 ttfb是指平均收到服务器返回第一个字节的时间，ttlb是指平均收到服务器返回的最后一个字节的时间。根据这两个数据我可以很轻松排除网络的原因。为什么我这么在乎网络传输呢？由于直接进机房的测试手续很麻烦，我们很多项目进行性能测试的时候是利用专线或是internet网的，而我们公司的网络很有问题，几次测试下来结果差别很大，而通过网管检测流量，只能分析到不到阀值，因此我想知道在这种情况下应该如何分析。
3、我的意思是，推断用户数的方法其实很简单，就是有目标给目标，无目标给出调研数据，如果都没有那么性能测试只能给出目前系统在大概几个核心操作上最优和最大的性能指标，而过分的讨论如何根据行业经验进行推断，如何利用现有的一些公式进行推断，本身并没有意义也不符合严谨的原则，这点是测试工程师应该坚持的。我在工作中常遇到什么调研都没有的性能测试，项目经理经常会说你看这个系统应该到什么指标啊？如果我们用行业标准来推算了，那么只有助长项目经理或是需求分析人员这种不严谨的作风。
4、其实这个问题和我第二问题有点相似，在考虑网络影响之余，我只是想问问您有没有遇到过类似的情况。

看两位讨论得热烈，我也来凑个热闹~^_^
1、我还是没大看明白。hit per second应该是每秒点击数，而一次请求可能会包含很多个点击，所以response time per hit和transcation response time是不一样的，通常我们更关心的是后者。
2、我和wufeiwufei有同感，我在做很多性能测试的时候，经常遇到测试环境的网络问题，尤其是现在的网络上总是有很多病毒，而目前我又找不到可以精确划分各个传输时间段的工具，所以对于排除网络影响这个问题，我也常常很头疼。如果was真的能给出这么样的两个指标，那么我倒是很有兴趣研究一下。
3、依然赞同wufeiwufei的意见，不过现实总是让人很无奈。按照我的经验，要做相关的调研，毕竟不是那么容易的事情，会遇到很多困难，甚至可能比性能测试工作的本身还要难。
4、可能是网络的原因，也有可能是由于一些缓存的原因，第一次运行的程序，通常会比较慢。由于没有更多的信息，还是不好判断。

@wufeiwufei

1.只有在特定的情况下 hit 的数量才会等于 request 的数量，而很多时候是一个 request 会产生多个 hit。所以通常 Response Time 是以 request 或者 set of request 来度量的；
2.还是那个意见——避免网络的因素影响测试结果。另外，你提到的ttfb 和 ttlb 也只能区分最后从 Web 或者 App Server 返回结果所花费的时间，但是还不能区分开 Web/App Server 与 DB Server 的时间；
3.对于性能需求的确定，个人看法是关键在于：
- 明确，可以度量
- 有凭有据，合理，有实际意义
- 相关人员达成一致
而达成这一目标的手段是多样的，我更关注于现实可行的方法。另外，还有一点比较重要的时候在于对性能需求的分析和解读——客户给出一些性能指标，测试工程师如何理解这些指标，并正确的解读这些指标，最终把它们变成可以通过性能测试的方法来度量的性能需求，这都是很重要的。
4.对于这个问题，只能根据您给出的信息来提一下我的思路。
- 检查是否多次执行同样的测试都可以重现这种情况
- 检查是否跟测试方法有关
- 检查事务成功率
如果愿意进一步讨论，那么需要提供更多的信息，或者也可以先说一下您在现场进行分析的思路。

@xingcyx

非常高兴看到您留言参与讨论 ^_^

下面是今天在 QQ 上收到的一位网友的信息，据说是客户方提出的一些性能指标要求，大家有兴趣可以试着分析一下，看看该如何解读和分析这些指标，或者还有哪些东西需要进一步完善 ^_^

1、系统允许必须满足同时允许100人在线编辑文章的并发量。

2、发布保证在1分钟以内发布到前端。

3、文档提交保存必须在7秒以内，文档列表显示不能大于5秒。

4、系统必须保证在100万个文档数，和500万文档资源的情况下正常使用。

5、系统必须保证在10万个模板和50万个碎片的情况下正常使用。

6、系统日志保证在100万的情况下可以正常使用。

7、共享资源必须保证在500万的情况下正常使用。

8、外部资源在200万的情况下正常使用。

9、TAG要在20万的情况下正常使用。

10、文档发布要保证同时发布2万篇没有问题。

11、CMS最大站点数保证在100个以上时可以正常使用。

12、每个站点的频道数要保证在10000个以上可以正常使用。

Jackei 您好，刚刚拜读了您上面的两副图，及其说明，
您说第一副图和第二副图一样。
但我还是对
第一副图的50%，60%，70%，80%，90%等怎么在loadrunner下调整的，请详细的说明，好吗？
第二副图的那些百分比是怎么得出来的。也不明白
急切等待中。。。。。。。。。。。

@zuoning
你好 ^_^

50%，60%，70%，80%，90%等怎么在loadrunner下调整的
—> 打开 LR 的 Analysis 工具，选择 Tools -> Options -> General -> Summary Report -> Transaction Percentile.

第二副图的那些百分比是怎么得出来的
--> 是用 Excel 的频率累积函数算出来的。你可以查查 FREQUENCY 和 Excel 的其它统计函数。^_^