方法论-1：
　　同时在线用户数：
　　平均并发数：
　　并发用户数峰值：
　　在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。
　　（1）  计算平均的并发用户数： C = nL/T
　　即：平均并发数＝总用户数*用户在线时长/总工作时间
　　（2）  并发用户数峰值： C’ ≈ C+3*SQRT（C）
　　即：峰值并发数＝平均并发数+3*（平均并发数^1/2）
　　公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。
　　公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
　　实例：
　　假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，之内用户从登录到退出该系统的平均时间为4小时，在的时间内，用户只在8小时内使用该系统。
　　则根据公式（1）和公式（2），可以得到：
　　C = 400*4/8 = 200
　　C’≈200+3*根号200 = 2421
　　估算处理能力，通常用TPCC值，即每分钟处理请求。每个服务器也把TPCC值作为指标。这与以下因素有关：
　　1，并发用户数？（U1）
　　2，用户访问模式：每分钟每个用户发出的业务请求个数，例如0.2个（N1）
　　3，这些业务请求中，
　　如果是数据库服务器，统计查询、更新、统计占比，
　　如果是Web服务器，可统计，例如连接跳转、添加操作、删除操作、更新操作，查询操作除各占1/5
　　4，业务请求引起的事务数量
　　例如， 平均每次页面跳转操作产生6个事务（T1），平均每次添加操作产生8个事务（T2）；平均每次删除操作产生8个事务（T3）；平均每次更新操作产生14个事务（T4）； 平均每次查询操作产生10个事务（T5）；
　　5，忙时数量是平均值几倍，例如5倍
　　6，经验系数，例如1.8
　　7，服务器保留多少冗余，一般是30%
　　TPC-C=U1*N1*（T1+T2+T3+ T4+ T5）/5*3*经验系数/冗余系数
　　方法论-2：
　　并发用户数
　　大家都知道我们的性能测试通过工具模拟多用户对系统进行操作，对系统造成压力，来验证系统的性能（不太标准的解释）。好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时，很难对系统构成压力；没有多个用户，同时的概念也自然不存在了
　　并发的两种情况
　　一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。
　　另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。
　　从服务器的角度来看并发
　　前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。
　　如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个是所谓的服务器所承受的大并发访问数。
　　真正意义上的并发不存在
　　上面试谈了这么多并发，现在又说真正意义上的并发不存在。何解？学操作系统原理的同学都知道，CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影，边打字，边语音。因为CPU很快很快，他可以处理一下电影，再处理一下打字，再处理一下语音。因为它很快，所以，它可以在多个程序之间快速瞬间的切换，给你造成的假象是它在同时做这些事情。（现在的双核、四核的CPU另说）
　　那么我们的系统在接到用户的请求后也要调用CPU来完成某些处理，然后返回给用户。那么我们对系统有做并发测试是测什么呢？举个简单的例子。假如有一位神医，他的看病速度非常快，假设他的看病速度是不变的；然后有一群接待人员来接待看病的客人，有成千上万的病人来看病，接待人员要想各种办法来做好接待工作，使病人更快的看到病。比如，可以事先咨询病人得的什么病，然后将病人进行分类，比如可以扩大接待室，让更多的病人可以进到医院来看病等。
　　神医是我们的CPU，接待人员是我们的系统，病人用户，我们做性能测试的目的是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人，医院的看病速度与服务很好。一下子来十万个病人各种问题出来了。接待人员的服务态度下降，多余的人员跟本进不到医院去，医院的洗手间不够用，造成病人无法上则所而离开，这些都属于系统问题。所以，我们一般测试的目的是看医院的接待能力。
　　系统用户数与同时在线人数
　　在实际的性能测试中，经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。
　　假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这是说有20万用户可以使用这个网站的所有功能，20万是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的高记录是2万，是有2万人同时用浏览器打开着这个网站。2万是“同时在线人数”
　　那么系统的并发用户数是多少呢?2万么？NO!这2万只表示在系统高峰时有这么多用户登录了网站，并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器日志的分析得到。
　　求并发用户数公式
　　在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也是从业务的角度关注应该设置多少个并发数比较合理。
　　下面找一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
　　C=1000*5/30=166.7
　　C表示平均并发用户数，那么对这个签到系统每秒的平均并发用户数为166
　　当然，在性能测试上，任何公式都不是严谨的，重要的是对系统做出有效正确的分析。
　　方法论-3：
　　一个系统的大并发用户数为1100，怎么能推算出该系统的支持大用户数。 其中用户性能要求如下：支持100万注册用户 性能需求分析： 1、根据用户的要求，本系统要支持100万用户，其中性能机器配置如何？高峰值是多少？带宽？等 2、如果都是采用公司的测试环境，那么本次性能应该做哪几种性能？性能评测、负载测试、强度测试？ 3、怎么算出并发用户数？响应时间？ 性能指标确定： 因为用户的性能需求太广，没有定到具体的数值。那么我怎么开展后继的工作？1、确定采用公司测试环境，不用考虑环境问题。也是说，客户端、服务端以及带宽等一系统都可以不用考虑，这是固定。 2、考虑此项目组以前开发过的系统性能情况，能否做为一个参考值。解决方案：找出本项目组以并发过二个项目，其性能个项指标进行求权。其中浏览功能：并发数为1100，平均响应时间363秒；每用户平均响应时间为0.33秒。每秒中并发3个用户。其中一系统用户已达500万，另一系统用户为320万。并且二系统一直运行正常，但目前的二系统的服务器各为3台。可以得出一台服务器为载166万，甚至更多。（因为服务器中有求权的关系） 3、100万用户，那么怎么计算出他的每小时峰值活动用户数？ 解决方案：采用80?20原则计算得到每小时峰值活动用户数 6.667万/小时；那么每秒中的同一功能点点击并发数应该是18.5。 4、怎么得其并发数？ 解决方案：本系统有多少个功能点？功能点为153个；也是本系统在高峰值时一功能将被点击1258次，每秒点击0.35次。（不考虑间隔时间）考虑以前本项目组的数值。初步设置并发数为1100，主要以浏览功能为主、其次是查询和新增。 5、应该测试那种性能类型经再三考虑，三种性能都进行测试。 执行性能： 评测，依据性能指标确定中的第三点，将用户的并发设置为300-350，看其情况。负载测试，以1100为起点强度测试，为15小时和24小时为准 性能测试结果： 发现本系统大用户支持为1100.失败用户高为209，响应时间为315。可以判断此系统大并发数为1100左右。也说此系统在一台服务器上可支持150万用户数。 根据上述情况，可以得出： 1100用户并发时，用户一共响应时间为315秒（即每用户平均响应时间0.005秒），其中高产生209个失败用户，但成功用户基本上可以完成后续操作，符合现系统要求的大稳定用户数。由此可得出本系统在新增功能点中支持大用户并发数为1100。按照1*100比例，计算得到每小时峰值活动用户数11万/小时；采用80?20原则计算得出本系统支持注册用户数约为165万。而本系统性能需求大规模支持100万注册用户，由上述的数据我们的系统已达到本系统性能需求。 注：100万，采用80?20原则计算得到每小时峰值活动用户数6.667万/小时。