1、并发用户数的问题，LoadRunner虽然有集结点的概念，但由于网络传输和程序处理的原因，并不能达到真正意义上的并发，实际上是有计算公式，可以推算出需要模拟用户数才能达到并发用户数。

　　这块的影响点就是服务器的连接处理，当连接数达到服务器操作系统设定值时，有些服务器的操作系统能自适应，比如Aix，Solaris，HP则需要管理员手动修改配置参数的。同时建立连接也是比较消耗系统资源的，建议还是把这种情况考虑进去。

　　2、当系统运用了负载均衡、双机热备策略的时候，建议增加故障、可恢复性测试。

　　该测试能够保证系统在部分服务器宕机的情况下，不会丢失业务数据。

　　3、推荐使用IBM的tivoli监控软件，强调下不是专门的性能测试工具，是监控工具。

　　Tivoli也有很多产品，可以监控网络流量的，可以监控各个节点处理时间，可以监控数据库的处理等，推荐原因是该软件可以跟踪事物处理的整个流程，不像loadrunner只能监控一个点的处理情况。

　　谈论

　　A：监控服务器以前我们也是通过shell脚本，每隔三秒输出相应的系统参数，现在有专门监控服务器资源以及数据库资源的软件（免费的），并出曲线图的工具

　　B：每3秒获取一次系统数据频率太高了，在做性能测试的时候，机器的负载是很重的。可以写了一个shell专门监控系统资源的，10分钟获取一次系统资源

　　A：每3秒获取一次系统数据频率不高，因为出现问题有可能就那几秒钟，十分钟的话估计什么数据都记录不到，出现问题也不好定位，建议不要超过5秒。这种脚本占用的系统资源是极少的，可以忽略不记。Shell脚本获得系统资源的数据容易，主要是这些数据的统计分析。

　　B：一般来说，系统的性能问题不是几秒钟的问题，是一个较长时间数据分析的问题。获取系统信息的内容也可以很多，一般来需要把每个进程的 cpu，memory等占用情况都记录下来，以前我有碰到这样的情况，发现系统资源占用很厉害，以为是我们的service有问题，其实是另外的进程吃掉了大量的资源。在获取系统资源的时候，数据收集的多了，自然就会涉及到占用系统资源的问题。至于后期的数据处理，只要数据收集的比较全了，重新格式化一下数据，可以用的工具很多的，用excel也可以画出很丰富的图形的。

　　A：1）性能测试的确是一个较长时间数据分析的过程，问题是十分钟才记一次，中间的过程没有数据如何分析？

　　2）吃掉系统资源的不是shell脚本，而是其它进程或者应用。你可以测下你的shell脚本单独运行会占用多少系统资源。以前我们测性能的时候，几百个用户同时处理业务数据，处理能力达百万笔业务/小时，同时运行shell脚本都没问题，这个没有你想像的耗资源，这可是服务器，运行个命令记录数据就宕了，还不如用台式机。

　　3）数据收集全面，确实会得到很多数据，包括内存、cpu、IO、吞吐量等等（当然咱们项目的应用对磁盘IO参数不关心，以前的项目是经常做磁盘操作所以也需要监控）数据量是比较庞大的，问题是如何重新格式化？有比较好的方法？当时负责性能测试这块的人出这个报告是花了比较长的时间整理这些数据。

　　这是性能测试时模拟用户数的计算公式，仅供参考：

　　公式一：

　　C=nl/T     C^≈C+3√C

　　C是平均的并发用户数；n是login session的数量（一天当中基本有多少人登录系统）；l是login session的平均长度（登录系统后的时间长度）；T指考察的时间段长度（例如一天中登录系统的时间总数）。C^模拟用户数。

　　公式二：

　　C=n/10     C^≈r*C

　　C为平均的并发用户数，C^模拟用户数。r为调整因子，一般的取值为2至3之间。

　　说明：公式二不如公式一精确，但公式一需得到两个参数：l和T，如不能提供则采用公式二；C=3000/10=300  C^=3*300=900