近来发现一个很有意思的文字：

       以前做性能测试时总是需要自己想当然的设计性能测试的并发数及持续时间，其实这块一直都是没怎么搞清楚，然后每次出来的结果也是信服度不高，而且在测试过程中根本没有任何依据可循，所以也没有啥说服力。然则进行调优时也没啥依据，只能凭自己单方面想象并发的数量。然后就随便糊弄糊弄就过去了，那时候其实一直都想深入研究可是

      近来又接到了一个性能测试的任务，手头也一直都有事情脱不开身，然则上头交代的事情也必须要给出点什么，然后一周后就然后忙里偷闲的做了一份计划方案还是沿用以前的那种方式，其实最初想要是再不发出点什么给上头孔上头又跟之前一样在大会上说我办事效率底下，，然后想直接发送出去，交个差，在发送邮件起初将该邮件内容发送给自己领导审核审核，意识重视，结果被领导各种问题一问，发现就不大对劲儿，自己领导这层已经糊弄不过去就更别提其他人了然后我抽个双休翻阅了很多资料。果不其然周一一上班上头就开始催了，没得办法，幸好之前有翻阅的资料在无须太折腾然后就搞定了，最后再发给自己的领导审阅审阅，完美通过，然后邮件CC出去。完事。

以上是题外话：下面将计算并发数的方法列出（假定知道一天的访问量）

2.测试并发用户数量计算公式(以首页的并发数举例说明)

并发数=业务量（pv量）/（时间段(小时单位)3600秒/每人每笔业务的处理时间）

例如首页访问业务量期望在0:00-24:00这一时间段内达到100万的访问量。根据这样的业务量，首先统计出单用户单次访问首页时服务器的响应时间（可包括用户的思考时间，但统计性能结果时需排除），然后再进行计算。考虑到场景的运行时间如果是24个小时（8:00-22:00）的话，可能时间段过长，增加测试难度，这里采用二八原则进行业务量与业务时间段的重新规划，即为80%的业务量在20%的时间内完成。那么100万首页访问量的80%即为80万，而24个小时的20%即为4.8小时。故本次测试，如果性能满足4.8小时内完成80万的业务访问量，为测试通过。

利用LoadRunner录制访问首页的脚本，在Controller中不设置持续时间运行一次，然后在Analysis中统计出单用户单次访问首页所需要的时间。假设此时得到的响应时间为t秒/次，则根据预期计算得出业务高峰大概出现在T小时内。那么单用户在T个小时内可访问首页的次数C=T*60分钟*60秒/t（秒/次），那么T个小时内PV_Count（页面访问量）大概需要Total_Vuser=PV_Count/C个Vuser来完成。此处的Total_Vuser即为测试时所用的并发数。

示例：

假设单用户单次访问首页，服务器的响应时间t=3秒/次，那么T（4.8小时）内单用户可访问4.8小时*60分钟*60秒/3（秒/次）=5760次，则初步估计的并发数Total_Vuser为100万/5760次/人=人，即大约为174个Vuser。而在实际使用中并发数不得超过200，则实际的并发数及运行时间如下：

174*4.8/200=4小时

即认为200的并发量持续4小时