Loadrunner测试web服务性能

一、测试工具

1. 环境

• windows7
• 8核 3.4G主频
• 8G内存

2. Loadrunner 11

• 模拟单sql查询请求，50虚拟用户并发（2/15秒 进入），每个用户请求5次(2/30s 退出)，
• 检测事务提交，成功和失败的数量

二、被测对象

1. 环境

• windows7
• 4核 2.67GHz
• 8G 内存

2.中间件 tomcat

• 采用JMC监控其 java heap memory和cpu占用情况
• 观察多少并发的时候达到最大heap memory允许值（tomcat9 默认2G内存）

3.连接池 proxool

• 采用proxool servlet控制台监控连接池延迟情况
• 连接池最大允许连接300，10 idle

4.数据库 postgres

• 采用pgAdmin4监控数据库吞吐、会话工作状态、事务提交情况
• postgres默认最大6个会话，其中5个idle

三、测试情况

1. 无条件查询不分页查询一个2W条数据的数据表

lr只能完成2-4个事务的时候，tomcat即java heap space out of memory。
优化：

• 调高tomcat 的 java heap memory，能够允许更多的事务成功

设置Tomcat启动的初始内存：
其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置
参考文章

将Xmx调到4096后，最大的heap space大概在3.5g, 持续增加事务请求，首先出现的错误是数据库关闭链接，随之pgadmin4中监控到postgres自动增加了最大连接数从6到30，一直加到45左右。
但是loadrunner中的事务成功数不再增长，后来的事务持续都是fail，loadrunner关闭已经运行完毕的user开始报120s(估计是http请求超时)超时错误。

本次测试分析：调高heap space到4G后，tomcat没有成为瓶颈，但是由于增加了loadrunner用户增加的间隔（由10s增加到默认的15s），所以这也为tomcat减轻了压力。不过总之，调高tomcat的max heap space的效果非常明显。本次的主要瓶颈就是postgres。

• 根据上次的测试，怀疑是postgres的连接数增加速度更不上导致。但是为了统一调用负荷，修改loadrunner参数后重试，改为50user，2user/10s start and run 5 min then 5user/30s stop, 查询的数据表大小依然为2W行。
  估计这次先挂的应该是tomcat，因为50个用户最高并发50个请求，同时请求2W行数据，假设一个查询结果是15.76M（包含空间字段），则50个并发的内存占用大概在800M，如果数据库扛得住的话，应该还行。但是如果考虑之前没有结束的请求，以及没有来得及GC的垃圾，那么内存需求猜测在3G以上，不过咱们有3.5G heap space，应该还是够用吧，这时候就看CPU能不能给力别让GC来不及了。
  好，看看到底是tomcat先挂，还是postgres先扛不住吧。
  经测试的确是postgres挂了，原因其实是因为查询2W的大表，速度太慢导致postgres速度跟不上，不写这种脑残的sql的话，其实50用户大约每秒20的并发量，单机部署完全没问题，而且还是tomcat和postgres在同一台电脑上面。