转自：http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html
这个帖子的内容比较典型，大家有兴趣可以也思考一下。
先是楼主提出问题：
最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本)还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案?
后面跟着大家的回复：
网友 xingcyx 的回复：
1、找10台电脑也没用，license仍然只支持10000个。2、找HP支持。当然，前提是你有足够的钱。3、测到10000用户并发。我认为，通常情况下10000用户并发，支持100000用户在线，没有问题的。
网友 jackloo 的回复：
总的来说这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求。如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；那么，你只要集群的服务器足够多，10万并发数当然可以达到了。通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。
楼主的回复：
谢谢jackloo !再请问如果我想测试10000个用户同时在线做常用操作的话(每两秒加一个用户,一直加到10000),对服务器的要求有多高?网友 jackloo 的回复：
套用1句经典台词“高，实在是高”呵呵。另外暴寒1下，你的设置光全部进入运行状态就需要接近6个小时。具体的你可以拿1个系统来压一下看看，可能会出现以下情况：1。服务器宕机；2。客户端宕机；3。从某个时间开始服务器拒绝请求，客户端上显示的全是错误；4。勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如数据库、中间件等。我从没遇到你说的这样的性能需求过，也只好凭感觉随便掰掰：1。服务器方面：上面说的那样的PC SERVER需要50台；2。网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；3。如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器；4。如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。网友 mybasswood 的回复：
如果是10万用户的话要看做些什么哈.比如对于voip来说,假设有10万用户的话,服务器规定每个client至少要在3600秒内到服务器成功报到一次,否则就被服务器cancel掉.client是每隔60秒注册一次.所以就要推算在3600秒内,每一个client至少成功报到一次是最少的标准.要10万用户在3600秒内被服务器吃掉才可以---这是最低要求.最高要求是: 在60秒内所有的10万用户去注册,如果服务器在60秒可以都吃掉的话,每秒种的平均并发差不多是3334.最低要求是:在3600秒内所有的10用户去注册,如果服务器在3600秒内都可以吃掉的话,每秒钟的平均并发用户差不多是60个.还有一过问题是客户端要在3600秒内发送至少60次,至少有一次成功.再加上这些用户分布在全球各地的话,这样数值应该还会有变化的.下面是偶的看法：
给楼主一个建议吧。你在公司中的测试环境是一定的，你需要做得是现在这个环境中确认一下系统在当前环境下的实际处理能力。如果还有资源，再做一下可伸缩性的测试。然后对测试结果进行分析，对系统的处理能力和可伸缩性做一个描述。当然，要在报告中说明你的测试环境。
另外一位网友robust 的留言：
你的意思是否想用10000个用户测试结果来推测一下10万个用户?还是如有些老兄说的,测试一下什么伸缩性测试.然后也来个报告,无非也是想用1万个来推测10万个的情况?(评注:那样的话要你做什么性能测试,只要计算一下就可以得性能结果了.)还是如有些老兄说的,这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求?(评注:那样的话要你做什么性能测试,做什么性能调优,只要计算一下,添加硬件就可以了.)实际上,"实践是检验真理的唯一标准!"这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,并不能反映真实的情况.至于性能测试工具,LR只是普及率高(市场占有率高),并不是在性能指标上有优势.世界上比它厉害的工具有不少,举个例子siprent通信公司的avalanche2500,大型计算机实验室配备的性能测试工具.支持录制/回放,测试结果分析等.它可以模拟从数据层到应用层的协议,(当然也包含http-web),单个支持100万并发连接.拿它也可以测试100万级的并发性能.又是偶的回复：
楼上的提到的见解不错，不过对性能测试的理解有些偏差。先抛开性能测试工具不谈，其实这个问题是讨论到一个性能测试到底该怎么做。简单举个例子，如果你想知道一种新的疫苗对人的作用，是不是要把所有的地球人全部找来每个人打一针试试呢？当然不是，只能是通过试验和抽样，然后通过统计学的方法来计算出一个模型，通过样本的表现来估算总体的特征。这就是统计学研究的领域，。不过请注意，统计学所包含的内容并不是像楼上的老兄所说的一样：只要计算一下就可以得性能结果了。性能测试也同样如此。楼主提到的性能需求应该是系统上线以后可能要面临的压力，先不讨论这个需求是否准确和有效，我们先假定它是有效的。那么，既然要验证的是系统在上线以后是否有能力应对10万用户同时在线的情况，那么自然要用生产环境来测试。如果有，那么 OK，可以作这个测试。至于工具，其实可以由开发人员帮忙写一些简单的脚本负责加压，再通过其他第三方工具收集测试数据就是了。但是如果没有生产环境，只有一台双CPU，3G内存的 2850 服务器，怎么办？这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试，并根据测试数据获得系统在这种环境下的最佳负载和最大负载，并根据测试数据对负载和资源消耗的情况进行估算，找到它们之间的关系。一般来说，大型的门户网站不会只用一台超级超级的服务器来承担所有的负载，因为采用负载均衡和集群技术可以更好的解决这个问题，一定是多台服务器分布在不同的地方，内容通过内容分发网络同步到各台服务器上。用户在访问时，其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时，对于可伸缩性的测试是必需的，一定要了解到 cluster 数量增加时，系统的响应能力是否可以线性的增加，也就是说是否可以承受更大的压力，为更多的用户提供服务。最后总结一下，对于性能测试，要作的是确认系统的响应能力，然后看系统是否可以满足性能需求。如果大家有不同的见解，欢迎 PK 讨论 继续偶的回复：
to jackloo你所提到的对于硬件资源和软件资源的要求并不完全准确。因为实际的资源消耗要根据网站所提供的业务类型来推算。对于大多数门户网站来说，可供访问的大多是静态页面。在用户访问时，系统只是返回一个静态页面给用户，并不需要保持 session，而且这种情况下负载主要集中在I/O和网络流量方面——这也是为什么大型门户网站都会采用分布式的方式来部署服务器。当然，如果使用了 cache，内存的使用会随着服务器运行时间的延长而增加，但是 CPU 通常不会成为关键资源。这是门户网站同企业应用或者在线游戏的区别。还是偶：
to 楼主上面我也提到了，你需要进一步的明确你的测试需求是否有效，合理。性能需求需要根据网站具体提供的业务类型来作为依据进行衡量。就如同上面提到的，是只提供了静态页面的访问？还是有其他的业务？要区分清楚注册用户、在线用户和并发用户的区别。另外，你最迫切需要担心的并不应该是 LR 的 license 问题，而是被测的系统能否支持的了几百或者几千并发用户，如果连这个都支持不了，就更不用考虑上万的并发访问了。希望大家有不同的看法和意见都可以写下来，大家一起讨论，共同进步。
Feedback
一般大型网站的采用负载均衡，比如一个购物网站30台服务器分为WWW部分，SSL部分，WWW部分12台，SSL部分18台，这样可以保证WWW页面能够承受500-600万用户访问，SSL部分可以承受最大2000-3000个用户同时下订单。
同时数据库服务器要达到一定的规模。
同时数据库服务器要达到一定的规模。
继续跟进
网友 robust 的回复：
QUOTE:原帖由 jackei 于 2006-11-16 11:00 发表在医学、生物工程等领域，很多实验获取样本极为困难，使用几百份样本来获得对更大总体的特征的估算也是合理的。 
没有错，因为前提是他们的取样的方法是科学的，合理的。象这种工程领域的取样，他们的样本会是均匀分布的，如果取样的方法是错误的，那他们的结果也是错误的。反观这个例子，10000个里取样，推测10万这样的结果，你认为取的样本分布是什么分布，是正确的，科学的吗？网友 jackloo 的回复：
呵呵。精彩。向jackie和robust学习哦。不过对于LZ说的这样的门户系统，由于有用户权限，所以并不象jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过1台机器的测试结果来计算多台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在1台机器上变化，那我们只能做一些指标上的计算，可以从这些指标上简单判断一下是否不可行，比如10万并发用户却只有1根百兆带宽，那我们可以计算出每个用户只有1K带宽，这显然是不可行的。但实际的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。另外我也解释一下为什么说“这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求”。这一类是指最大并发数、最大在线用户数量等。因为用户操作不同功能，对系统的压力就不同，而在实际使用过程中常常会出现因为时间不同或者发生突发事件导致整体用户操作上功能的变化。所以没有统一的功能使用的标准导致了这一类的指标成了个噱头。所有的软件厂商都是自说自话，把自己的软件安装在一个极端的环境中，做一些没有实际意义的操作，得出一个你永远都不可能达到的性能指标出来。就如同汽车厂商的汽车油耗一样，反正你就听听罢了，真正使用中是不算数的。另外这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大（当然不完全排除后期针对某些代码和配置进行优化后性能的进一步提高），更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器等。偶的回复：
HI. robust, 真的很高兴有人可以这样一起讨论问题 ^_^我说说我的看法吧。首先，对于响应时间之类的这种连续性正态分布，只要样本数量够多，通常都是均匀分布的，也就是说是具有统计学意义的。——什么叫样本量够多？例如 100 个并发用户执行一次迭代是不够的，可以考虑每个虚拟用户执行 100 次迭代，来尽量减少抽样的随机性对数据真实性的影响。当然，我们必需了解，抽样的数量是收到时间和相关资源的限制的，个人理解是应该在资源限制的范围内获得尽可能多的样本数据。第二，其实上面我们在讨论的是两个问题，一个是涉及到性能测试本身，另外一个是如何通过可伸缩性测试(scalability testing)，或者说通过容量的规划来对系统的性能做出预期。应该说性能测试本身也是一个实验，但是总体并不是上面提到的 10 万用户，而是从这个系统第一个用户访问开始到系统下线前的最后一个用户。通常大家都会用平均响应时间来评估系统性能，但是如果要获得最准确的平均响应时间，就要记录这个系统第一个用户访问开始到系统下线前的最后一个用户，每个用户的响应时间，然后平均。但明显这是不现实的，就好像我上面提到的那个疫苗的例子。我们只能通过性能测试，通过不同级别的压力（并发量）来获取实验数据，并通过对这些实验数据的分析获得对系统真实性能的估算。这里涉及到 Std.（标准差）和置信区间等统计学方法，我将会在我的“《LoadRunner没有告诉你的》之Std.在性能分析中的应用”一文中详细讨论。而对于可伸缩性测试，对于很多大型网站或运营商级的系统来说是必需的，因为要考虑到用户的增长，所以必需要了解系统在将来是否可以通过一些简单有效的方法（例如增加 cluster）来提高系统的处理能力，以及在当前的阶段是否需要投入巨大的资金来购买硬件和各种软件的 license。通常来说是要根据并发量、系统的性能表现以及软硬件资源的消耗情况来进行分析，并使用数学建模的方式获得一个容量模型。这方面可以通过 google 找到更多的资料。希望这个讨论可以继续下去 ^_^还是偶的回复，to 网友 jackloo
呵呵，很高兴看到大家都回来继续讨论这个话题，感觉现在我们的讨论已经很有深度了，希望可以继续。另外，说点个人的看法。首先，如果验证使用集群时系统响应能力的变化，只有一台 cluster 的数据是不够的，一定需要继续做 2/3/4 台或者更多（如果有足够的资源的话）测试，得到的数据和分析的结果才更接近真实情况。第二，我也同意你提到的“这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求”。因为一方面可以看到 楼主 的性能需求本身还是值得商榷的。不过我们也可以反过来想，就是可以验证在某个环境下，系统所能支持的并发量是多少。例如目前的带宽是 100 M ，可以支持的并发量是多少，当升级到 1000 M 时，又如何？可以通过以现有环境为基础的测试来了解系统在不同压力下可能出现的瓶颈，作为将来部署的一个参考。