接口压测性能分析及调优手段建议_接口并发测试cpu过高是为什么_老城根的博客

1 接口名称: 获取列表

1.1 压测现象:单台tps700多，应用cpu高负载

1.1.1 问题分析:

旧框架，平均响应时间长，应用CPU高，程序内部有大量的bean到map到json之间的转换，修改数据库连接数后，tps没有提升。

1.1.2 改进措施:

重构系统，用mybatis替代之前的dao操作，减少bean-map-json之间的内部数据转换，减少程序内部的无用操作。

1.1.3 改进效果:

tps改进后能到3000左右，有较大提升，但压测时应用cpu几乎跑满，还有改善空间。

1.2 压测现象：数据库资源利用率高

1.2.1 问题分析:

单台应用，数据库资源cpu都能到50%，10台tomcat在1万并发下数据库cpu跑满，load值700多，但db的qps也不过11554，并不算多，因此怀疑是sql执行耗费了cpu，可能是某条sql没有按索引查找或者索引失效。

1.2.2 改进措施:

查看SQL文件发现如下sql：select count(1) from orders where order_status_id !=40 ，将其改为select order_id from orders 然后通过程序把order_status_id!=40的过滤掉。通过list.size()来获取。order_status_id即使加了索引，由于是！=比较，所以不会去按索引查找，导致cpu高

1.2.3 改进效果:

相同环境下(1台nginx，10台tomcat，1000并发)，tps由3000变成3727，略有增长，但是db的cpu明显下降，变为30%，效果明显

1.3 压测现象:1N15T ,tps4552;10N15T,tps9608

1.3.1 问题分析:

后端都是15台tomcat，前端1台nginx时tps为4552,通过lvs挂10台nginx时为9608，增长不明显，其nginx和tomcat都压力不大，集群结果不合理，怀疑是nginx转发配置的问题；

1.3.2 改进措施:

未进一步改进：可能是需要调整nginx的参数，之前发现过nginx不同的配置对后端集群环境的tps影响很大

1.3.3 改进效果:

2 接口名称: 信息查询接口

2.1 压测现象:单台tps2000多，应用cpu高，db的qps15000左右

2.1.1 问题分析:

旧框架，程序内部有很多Bo-map-json相互的转换

2.1.2 改进措施:

删除冗余代码、更换连接池包，使用mybatis

2.1.3 改进效果:

Tps由2000多增长为8000多，db的qps为9000左右，优化后压测应用的cpu占用高，几乎跑满。

2.2 压测现象：数据库无压力，应用增加多台后tps不变

2.2.1 问题分析:

1N1T和1N10T的tps一样，都为5000，增大并发时错误数增多，应用cpu耗费70%，db无压力，nginx单台通过ss –s 发现端口占满，即nginx到tomcat之间转发的连接端口time-wait状态6万多。Nginx存在瓶颈。

2.2.2 改进措施:

调优nginx参数，将短连接改为长连接

2.2.3 改进效果:

1N3T的tps能到17376，tomat的cpu压力84%，db的qps18000，cpu69%，应用的资源基本使用到量。

3 接口名称: 获取详情

3.1 压测现象:单台应用tps2600，10台tomcat才3700

3.1.1 问题分析:

增加应用服务器，tps增长不明显，且nginx、tomcat、db的负载都不高，说明服务器本身不是瓶颈，考虑是不是网络的问题，通过监控网卡包流量发现网络数据跑满，因为此接口会有大量数据的输出，因此瓶颈在网络上。另外，测试过程中发现redis有报错，redis服务器是虚机，可能服务能力有限。

3.1.2 改进措施:

开启tomcat的gzip压缩。

3.1.3 改进效果:

同等并发下(1台nginx，10台tomcat，1000并发)，tps由3727增长到10022，增长了近3倍，效果显著。

3.2 压测现象:1N10T集群下nginx参数调优对tps提升效果明显

3.2.1 问题分析:

经过tomcat的启用gzip后，1N10T下tps为10022，需进一步提升。

3.2.2 改进措施:

优化nginx：

l nginx日志关闭

l nginx进程数量worker，由24改为16

l nginx keepalive数量由256改为2048

3.2.3 改进效果:

Tps由10022提升为13270。

3.1 压测现象:1N5T和1N10T的tps相差不大

3.1.1 问题分析:

1N10T的tps为1万3千多，1N5T的tps为1万2千多，相差不大，应用的tomcat资源利用没满，cpu为65%，Db的QPS已经到2万多了，单台服务器db基本上到量了，因此再增加应用也没效果，只会导致响应的时间变长。

3.1.2 改进措施:

单台db已经无法改进了，要不提升服务器硬件，要不读写分离。

3.1.3 改进效果:

4 接口名称: 促销

4.1 压测现象:通过redis存取数据，tps才1000多，CPU 有压力

4.1.1 问题分析:

此接口通过redis取数据，tps不高才1000多，但cpu占用了80%，说明程序内部有大量序列化反序列化的操作，可能是json序列化的问题。

4.1.2 改进措施:

将net.sf.json改成alibaba的fastjson。

4.1.3 改进效果:

同等并发条件下tps由1000多提升为5000多，提高了近5倍。

4.1 压测现象:参数多时tps下降明显

4.1.1 问题分析:

此接口根据参数从redis中获取数据，每个参数与redis交互一次，当一组参数时tps5133，五组参数时tps1169，多次交互影响了处理性能。

4.1.2 改进措施:

将从redis获取数据的get改为mget，减少交互次数。

4.1.3 改进效果:

五组参数时1N3T压测TPS9707，据此估算即使是单台tomcat，tps也能有三四千，性能比单次get的调用方式提升了3,4倍。

4.2 压测现象:1N3T tps1万多，在增大tomcat可能tps增长不会明显

4.2.1 问题分析:

此处说的是可能，因为nginx服务器的cpu虽然不高，但pps已经800多k，此时应该是nginx的服务器网络流量成为了瓶颈。(只是猜测)

4.2.2 改进措施:

可以增加多台nginx负载，前端加lvs

4.2.3 改进效果:

5 接口名称: 追踪接口

5.1 压测现象:1N10T的tps低于1N3T的tps

5.1.1 问题分析:

1N3T在2000并发下tps为9849，此时db的qps为90000，CPU80%，将tomcat增到10台，5000并发下,tps为7813，db的qps为19000，cpu75%，load 1，说明压力增大情况下db的压力反而下来了，注意到nginx服务器的网卡流量达到885M，说明是压力过大情况下，网络满了，发生丢包，导致db端压力反而下来了。

5.1.2 改进措施:

注意压测情况下部分接口由于数据量传输较大，会出现网络瓶颈。

5.1.3 改进效果:

6 接口名称: 回填接口

6.1 压测现象:tps不到500，db的qps3500

6.1.1 问题分析:

虽然缺少应用的cpu及db的cpu利用率数据，较低的tps应该是应用的瓶颈，且需要关注是不是db在处理查询的时候缓慢。

6.1.2 改进措施:

1.连接池由dbcp改为hikar；

2.减少了日志打印输出

3.sql优化，将部分条件过滤改为在java代码中执行

前言：前几天在用jmeter做性能测试的时候，遇到一个响应时间长的性能问题，简单总结一下，分享给大家，希望能给大家在性能测试过程中类似问题提供一个性能问题分析定位的思路。现象如下图，响应时间很长，达到了18秒左右，tps也只有20。根据经验，直奔oracle数据库服务器，top命令一看，负载高，用户 cpu 将近100%， cpu 已经达到性能瓶颈了，shift+p，或者键盘大写状态下按P，将所有进程按 cpu 使用率从高到低排序，这样，我们关注消耗 cpu 最多的进程即可。直接选取上图第一个进程ID27087，

对于某些不长更新的数据，并且修改了不需要立即生效，可以容忍短暂的延迟的数据可以做一个缓存。使用的到缓存有三种： a. 使用第三方的缓存但是只能缓存可以序列化和反序列化的数据，不能缓存带有泛型的数据，带有泛型的数据序列化后，暂时还没有找到反序列化的方法。 b. 使用直接缓存在内存中比如使用ConcurrentHashMap，因为要设置超时时间，所以存一个值需要两个key，一个保存值一

记一次年前，性能测试组人员，给我测试出的bug吧，说实话，这种bug也只有在高并发情况下才会出现。说下业务背景，我的程序中有一段逻辑是这样设计的：用户第一次请求，我会根据用户的请求条件，用哈希算法算出一个哈希值，再将用户的请求条件插入的到一张表里；然后拿查询条件去请求其他系统（耗时较长）和查询本地数据库里的业务表（数据量较大），这样查询完后，会将两部分的数据汇总到一张结果表里，然后再从结果表中将数据统一查出返回给调用系统。原本这也没啥问题，测试几轮下来，除了数据质量问题（与程序无关），没有出现过其他状

文章目录压测是什么压测的目的压测的要求压测的分类压测的过程明确压测目的梳理压测链路准备压测数据构造压测环境执行压测压测的保护机制清理数据总结复盘压测常见问题压测是什么压测是一种测试方式，通过不断对被压服务施加压力的来测试服务的性能极限，寻找瓶颈。压测的目的压测的目标关系到压测方案的确定和实施。一是压测的场景（接口，接口组），二是压测的目标探寻服务的性能上限，可通过压测结论进行限流，保护自身的服务大促前，判断目前的机器配置、服务逻辑是否能满足业务的要求，如果不满足需要进行优化（加机器，加缓存，代

首先，您需要安装 JMeter 工具，并在工具中创建一个测试计划。然后，您需要添加一个 HTTP 请求默认值配置元件，以便设置服务器的主机名和端口号。接下来，您需要添加一个 HTTP 请求元件，并设置请求的路径和方法。在请求元件中，您可以设置一些参数，例如请求头、请求体、Cookie 等。最后，您需要添加一个聚合报告元件，以便查看测试结果。在压测过程中，您可以通过调整以下参数来优化测试性能： 1. 线程数：可以增加线程数来模拟更多的并发请求。 2. 请求延迟：可以设置请求之间的延迟时间，以便模拟真实的用户行为。 3. 断言：可以添加断言来验证服务器的响应是否符合预期。 4. 监控：可以使用 JMeter 的监控工具来监控服务器的性能指标，例如 CPU 使用率、内存使用率等。需要注意的是，压测过程中需要合理设置参数，以避免对服务器造成过大的负载。同时，也需要注意保护服务器的安全性和稳定性。

ContextLoader.getCurrentWebApplicationContext().publishEvent（）获取不到会空指针异常啊 [/code][code=java] [/code] layui 报错： Uncaught ReferenceError: layer is not defined 一样的错，666 设计六大原则纲要（一）陈镇坤27: 《设计模式之禅》

接口压测性能分析及调优手段建议测试道路成长点滴: