jmeter连接数据库

Jmeter连接数据库

1 —oracle—
驱动：oracle.jdbc.driver.OracleDriver
URL：jdbc:oracle:thin:@ip:port:dbname
注：machine_name：数据库所在的机器的名称；

port：端口号，默认是1521

2 —MySQL—
驱动：com.mysql.jdbc.Driver
URL：jdbc:mysql://ip:port/dbname（数据库名称）
注：machine_name：数据库所在的机器的名称；
port：端口号，默认3306

3 —SQL Server—
驱动：com.microsoft.jdbc.sqlserver.SQLServerDriver
URL：jdbc:microsoft:sqlserver://<:port>;DatabaseName=
注：machine_name：数据库所在的机器的名称；

port：端口号，默认是1433

可能遇到的问题：
Cannot create PoolableConnectionFactory (The server time zone value ‘CST’ is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.)
1
解决时区问题：

方法一：修改驱动：
jdbc:mysql://localhost:3306/test?
useUnicode=true&characterEncoding=gbk&useSSL=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=Hongkong

方法二：修改数据的时区：
select now(); 查看mysql系统时间。和当前时间做对比

set global time_zone = ‘+8:00’;设置时区更改为东八区

flush privileges; 刷新权限

解决中文乱码

如下图；如果MySQL对应的表中含有中文 需要设置编码
?useUnicode=true&characterEncoding=UTF-8

Database Url :jdbc:mysql://xxx.xxx.xxx.xxx:3306/test?allowMultiQueries=true&serverTimezone=UTC&characterEncoding=UTF-8
JDBC driver com.mysql.jdbc.Driver

性能测试常用图表：
jp@gc - Active Threads Over Time

监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数）
Transactions Throughput vs Threads

吞吐量的评估值，X轴是线程数，评估值是不准的。线程数急剧变化的时候（比如线程数108到120时间，有个突然上升到4000的点，是不准的），吞吐量评估值都是不太准的。
50到70个线程数时，吞吐量是比较准的。
65个线程数时，吞吐量最大：

结合Active Threads Over time, 知道65个线程数大概时间是在40到43秒之间：

Transactions per Second

每秒的事务量。这是实际的吞吐量。如果写测试报告，要写吞吐量的话，要从多个维度分析。主要看Transactions per Second，不能只看聚合报告的最终吞吐量。（这是不准的）

这和通过Transactions Throughput vs Threads和Active Threads Over time2者结合分析出来的时间是吻合的（40到43秒，吞吐量最大）。

Response Latencies Over Time/Response Times Over Time

响应延迟时间和响应时间基本上是一样的。
响应延迟时间：发起请求到接口开始响应的时间。

是因为这段时间线程数增加比较快
3 Server Hits per Seconds
每秒测试计划所产生的点击服务器的次数

4 Bytes Throughput Over Time
在压力测试期间接收和发送的 bytes 数

5 Composite Timeline Graph
将你的测试计划中的所有的图表集合在同一张图标中以方便查看

6 Bytes Throughput Over Time
每秒传输字节吞吐量，表明 Jmeter 在测试时，随着时间推移发送和接受的字节数

7 Response Codes per Second
每秒返回的响应码，表明 Jmeter 测试期间，随着时间的推移返回的响应码，从中我们可 看到测试期间在哪个时间段内出现了错误。就可以分析在该时间内系统的什么环境因素， 导致的错误。

8 Response Latencies Over Time
每秒钟的响应等待时间， 表明 Jmeter 测试期间，随着时间的推移系统的响应等待时间的 变化，也是系统随着时间推移，系统效率的变化。

9 Response Times Distribution
响应时间分布， X 轴表示的是响应时间，Y 轴表示的是响应次数，F(X,Y)表示系统在某 种响应时间内的响应次数是多少，如果在响应时间短的地方，响应次数多，说明系统的效 率比较高。
10 Response Times Over Time
每秒钟响应时间，X 轴表示的是系统运行的时刻，Y 轴表示的是响应时间，F(X,Y)表示系 统随着时间的推移，系统的响应时间的变化，可以看出响应时间稳定性。
11 Response Times Percentiles
响应时间百分比，X 轴表示的是百分比，Y 轴表示的是响应时间，F(X,Y)表示低于某个百 分比的响应时间，比如有 80%的响应低于 400ms。
12 Response Times vs Threads
响应时间用户数， X 轴表示的是活动线程数，也就是并发访问的用户数，Y 轴表示的是 响应时间，F(X,Y)表示在某种并发量的情况下，系统的响应时间是多少。
13 Transaction Throughput Over Time
每秒处理的事务吞吐量 统计随着时间推移每秒可能的事务吞吐量 这里的事务吞吐量计算 公式是： 活动线程数1 秒/一个线程的响应时间，比如当一个用户向服务器发出一个请 求，在 100ms 后得到响应，那么事务数等于 11000ms/100ms = 10 transcation/s，得到每秒 钟可以处理是个事务数的结果。
14 Transaction Throughput vs Threads
每活动线程数可能的事务吞吐量，途中 X 轴表示的是活动线程数，Y 轴表示的是事务吞 吐量，F(X,Y)的含义是当系统处于某个活动线程数时，系统当时的事务 吞吐量是多少。 比如当有 10 个活动线程时，事务吞吐量是 100/s，而当有 20 个活动线程时，事务吞吐量 是 50/s，说明随着用户访问的增加，系统的处理 效率开始下降了。从这个图中我们可以 找到一个临界点，在多大的活动线程数时，系统达到最大的吞吐量。
15 Transactions per Second
每秒的事务数，X 轴表示访问结束的时刻，Y 轴表示访问量，F(X,Y)表示在某个结束时 刻，一共有多少的访问量结束访问。
16 Active Threads Over Time
每秒的活动线程数， X 轴表示访问的时刻，Y 轴表示活动线程数，F(X,Y)表示某个时刻 的活动线程数

功能测试主要根据产品业务需求、产品行业特征、模拟用户操作方式来测试一个产品的特性以确定它们是否满足用户需求。
　性能测试则是通过某种特定的方式对被测试系统按照一定的测试策略进行施压，获取该系统的响应时间、运行效率、资源利用情况等各项性能指标，来评价系统是否满足用户性能需求的过程。
　　通俗地说，功能测试用于确保软件系统做了正确的事情，性能测试则用于确保软件系统快速地完成了任务。

基准测试是
一种测量和评估软件性能指标的活动,用于建立某个时刻的性能标准,以便当系统发生软硬件变化时重新进行基本测试以评估变化对性能的影响

在jmeter中，只要提到并发，99%的同学立马想到线程组。需要多少并发就启动多少线程组，这已经成了大部分人的共识。这种理解方式很明显是把并发数和线程数的概念混淆了。线程组中不光有线程数，也有循环次数。然而大家在负载测试中都主动的忽略了循环的作用。jmeter中的循环和lr中的迭代是一样的，都是为了模拟出压力，不要选择性无视它

实验

先列出下面两个需求，大家可以思考一下这两个需求在jmeter里面如何设置场景

需求1：我有一个页面，需要测试一下最大支持多少用户并发？

此时要计算的是最大用户并发数，强调的是同时操作，也可以理解为同时发起请求针对需求1我们可以通过RPS 定时器或者阶梯加压线程组测试每秒最大的请求数(压测实战分析性能拐点)

需求2：查询功能，需要系统能够在5分钟内能完成5000笔查询业务，同时90%的用户响应时间不超过3s。最大并发是多少？

此时不强调同时操作，而是强调业务量。也就是说不限制用户的操作时序，不考虑人的效率。把人当做机器，只要在5分钟内查询数满足5000笔即可。但是具体有多少用户才能在5分钟内查询5000次？它是由单次响应时间来决定的。这时就引入了一个经常被人讨论的公式：最大并发数= (单次响应时间*业务量)/总的业务时间。我的单次响应时间越快，用户每秒可点击的次数就越多，那么需求就越容易满足。

线程数和并发数

针对需求2，我们如何在jmeter中设置场景？由上面的描述可以知道，我们可以计算出最大并发数。那么这个最大并发数对应的就是jmeter中的线程数。光有线程数不行，此时又引入了一个迭代的概念。假设单线程下，单次请求的平均响应时间是200ms，那么这个单线程的请求1s内可以迭代5次。如果有100个线程，那么1s内就可以完成500笔业务。5分钟内完成的业务数就是560500=15万笔。回到我们需求2，是不是远远超纲了？把线程数缩小，其实只需要4个线程，就可以在5分钟内超额完成5000笔业务了。455*60=6000

1-1如图1-1，勾选循环永远的意思就是不限制单位时间内的迭代次数，以此加载最大压力。
注：如果循环次数设置了固定值，那么下发那个持续时间的设置是无效的。线程组会优先根据你的固定循环次数去执行迭代。也就是说，固定循环次数的执行顺序优于持续时间！但是如果循环次数设置为永远，再设置持续的时间，那么就会根据你的持续时间去加载最大的压力。

事物完成线程组(TPS线程组)

针对需求2，jmeter额外提供了一个线程组去满足它— Arrivals Thread Group。在这个线程组中我们给予预期的业务量和业务时间，系统会自动启动线程去满足业务需求。

1-2如图1-2，表示我的预期tps是50/s，在2s内达到预期值，同时保持这个tps运行20s，那么22s内我的业务量是2250=1100

*1-3如图1-2，最大的系统并发数(启动的线程数)是319