服务器性能测试-增加了请求数，但是tps上不去，反而下降了

最新推荐文章于 2024-05-18 14:30:11 发布
最新推荐文章于 2024-05-18 14:30:11 发布
阅读量6.9k 收藏 6
点赞数 1
分类专栏： jmeter 服务端性能测试
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_40308101/article/details/108825109
版权

一个系统吞吐量通常有QPS(TPS),并发数两个因素决定，每套系统这个两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换，内存等等其他消耗导致系统性能下降。

 

QPS

QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。

TPS

TPS Transactions Per Second 也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

萌翻天
关注
  • 1
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
服务器并发量与那些因素有关
W_Kenneth的博客
09-16 2122
带宽与下载速度 带宽单位：比特（bit）b:比特 下载速度：字节（Byte）B:字节 1Byte = 8 bit 所以带宽和实际下载速度峰值有个8倍的关系 eg: 1M宽带 = 1024Kb/s = (1024/8)KB/s = 128KB/s 我们常说的50M、100M的宽带，下载速度峰值只有八分之一，也就是 6.25M/s、12.5M/s。这还是峰值，实际下载的速度可能只有70%-80%。 并发量和带宽的关系（不考虑硬件的承受能力和程序的相应时间） 1M带宽，下载速度128KB/s，假设一个网页30KB
性能测试线程阻塞导致加并发TPS上不去的问题定位和分析【杭州多测师】【杭州多测师_王sir】...
多测师_王sir的博客
10-04 1371
1、在Linux通过jmeter -n -t test.jmx脚本设置50-100-150并发、点击调度器、持续压测300秒 2、发现TPS在50并发的时候就已经可以达到3000/sec、但是分别设置并发为100和150的时候、此时的TPS还是3000/sec 3、但是通过dstat -tcmnd --disk-util 命令去监控的时候发现CPU的使用率始终没有很大的波动、空闲95%左右、只占...
性能测试：压测中TPS上不去的几种原因分析&案例分析
喵酱
03-08 2万+
性能测试：压测中TPS上不去的几种原因分析
Jmeter 性能-TPS上不去原因分析
最新发布
nhb687095的博客
05-18 825
1、TPS上不去的原因①网络带宽当你模拟大量用户发起请求的时候，单位时间内传递的数据包过大，超过了带宽的传输能力，造成网络资源竞争间接的就导致了服务器接收的请求数达不到服务器的处理能力上限，tps值自然就不会上升。②连接池连接池一般主要有两种，应用服务器连接池配置 和 数据库连接池配置配置太小，连接数被占满了，新的连接只能等待，tps值也就自然不会再上升。③垃圾回收机制JVM的垃圾回收GC都是基于算法的，如果新生代的Eden和Survivor区频繁的进行Minor GC。
关于TPS与CPU的性能综合分析
qq_38484679的博客
12-26 1476
短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接。原因解析：常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。原因：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁。线程池问题：修改服务节点中容器的server.xml文件中的配置参数。使用jstack -l {PID}查看线程死锁情况。
压测中TPS上不去的几大原因及解决办法
zhangzhen02的博客
04-13 1万+
压测中TPS上不去的原因： 1、网络带宽 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。 （关于连接池的具体内容，可参考之前的博...
结合“性能监视器” 排查、处理性能瓶颈导致应用吞吐率等指标上不去的问题...
asxza28042的专栏
08-25 779
双11备战前夕，总绕不过性能压测环节，TPS 一直上不去 / 不达标，除了代码上的问题外，服务器环境、配置、网络、磁盘、CPU 亦是导致性能瓶颈的重要一环，本文旨在分享最近项目性能压测过程中的排查经验，文中的表单你可以作为排查手册保存，如有不对之处，还请在评论区分享、交流你的经验和观点：） 原文地址（样式排版上更好点） ：https://blog.zhuliang.ltd/2019/08...
jmeter压测期间tps骤降（jvm参数）
小小董的博客
06-28 1188
1、jmeter压测期间出现tps骤降，压测执行几分钟以后，tps从1300将到850左右，经分析，是由于jvm日志参数设置太小导致tps出现骤降。
系统吞吐量、TPS（QPS）、用户并发量、性能测试概念和公式
freespace
11-11 1110
         系统吞吐量、TPS（QPS）、用户并发量、性能测试概念和公式 分类： 软件工程 2013-02-21 19:47 1865人阅读 评论(0) 收藏 举报   PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素：   一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对C...
TPS死活上不去，为啥？
qq_28569939的博客
04-12 1389
接到了这个任务，发现这个接口在容量测试过程中，发现无论并发用户数有多大，TPS无增长，响应时间随着用户数的增加而增加，服务器资源消耗较小，并在逐渐增加并发用户数的过程中，出现大量超时报错。处于受阻塞状态的某一线程正在等待监视器锁，以便进入一个同步的块/方法，或者在调用 Object.wait 之后再次进入同步的块/方法。从整个应用来看，原本线程应该执行业务代码并快速返回结果的，但是现在线程被挂起等待了，因此相应的我们的RT也就增加了。线程正在JVM中执行，有可能在等待操作系统中的其他资源，比如处理器。
性能测试脚本运行一段时间后TPS突然下降，过段时间后又恢复正常的原因
haoluojie的博客
01-11 1万+
现象： 1并发运行5分钟，脚本全部执行成功，所有指标正常，并发设置为20脚本运行一段时间后TPS突然下降为0，响应时间线条无打点记录，过段时间后相关指标又恢复正常，查看报错信息为连接不上服务器，如图所示： Error信息：连接服务器失败： 定位分析： 根据图中曲线走势和报错信息，“连接不上服务器，连接超时”，查看应用服务器的资源使用情况，内存，CPU，NET几乎没任
请求量突增一下，系统有效QPS为何下降很多？
fm18771120556的博客
01-16 246
最近我观察到一个现象，当服务的请求量突发的增长一下时，服务的有效QPS会下降很多，有时甚至会降到0。
性能测试实战分享1---TPS上升后下降
qq_23150755的博客
05-08 3086
性能测试实战分享1—TPS上升后下降 场景：30个并发，单台jmeter压测；客户端-Windows系统，服务端-linux系统； 问题：TPS上升后下降，且下降为高峰TPS的四分之一左右； 原因：压测机tcp连接端口占用过多超2万7千多，且大部分TCP连接都是time_wait状态，顾tcp连接端口不足； 解决方案：采用分布式压测，增加端口号； 分析思路： *第一步：*分析客户端和服务端的性能，看是否有性能瓶颈（CPU，内存，磁盘，网络） *第二步：*再分析客户端和服务端的端口是否用尽 *第三步：*最后分
吞吐量、响应时间以及并发数的关系及相互影响
chuixue24的博客
08-17 2562
以高速公路距离： 吞吐量：每天通过高速公路的车辆数据（也可以理解为收到的高速费） 响应时间：高速公路上正在行驶的车辆数 并发数：车辆 当并发数较小时，也就是高速上行驶的车不多时，这是车速是快的，即响应时间是很快速的，此时的吞吐量不会很大。 当并发数提升时，也就是高速上行驶的车变多时，车速会变慢，即响应时间会变慢，此时的吞吐量处于上升期。 当并发数越来越多时，也就是高速上行驶的车变的越来越多时，车速会进一步变慢，即响应时间会再次变慢，此时的吞吐量会受到影响而变小。 当并发数超级多时，也就是高
LR多用户并发时tps一直下降直至最后稳定
winnerzou的博客
06-11 2612
压测过程服务器资源正常，从最开始的20多tps下降到5tps左右。。求助各路大神压测tps如下：压测机资源如下：服务器JVM如下：
jmeter压测时持续并发但是吞吐量和服务器CPU并未上来
热门推荐
潜行100的博客
01-11 4万+
在jmeter并发压力测试时，设置的线程数比较高，且持续并发中，但是Throughput始终没有上升，一直保持在不到3/sec，并且服务CPU一直保持在1%以下，压力并没有上来。 解决办法： 在请求下面设置固定QPS。 1、在请求中添加定时器Constant Throughput Timer 2、设置Constant Throughput Timer（每s固定向服务器发送指定数
性能测试-tps上不去的原因【杭州多测师_王sir】
多测师_王sir的博客
04-20 1892
tps上不去，到底有哪些方面的原因呢，我这里大概给大家整理了一下，有以下10个方面的可能原因。 1、网络带宽：当你模拟大量用户发起请求的时候，单位时间内传递的数据包过大，超过了带宽的传输能力，造成网络资源竞争，间接的就导致了服务器接收的请求数达不到服务器的处理能力上限，tps值自然就不会上升。2、连接池：连接池一般主要有两种，应用服务器连接池配置和数据库连接池配置，配置太小，连接数被占满了...
性能测试：最强悍的工具终于上场了arthas，解答无论给服务器多大压力，服务器的CPU利用率始终很低，吞吐量一直上不去？如果瓶颈是由于代码问题导致的，请问如何定位？
zzhangsiwei的博客
09-26 2625
面试性能岗位必问知识点： 最最常见的性能瓶颈话题： 无论给服务器多大压力，服务器的CPU利用率始终很低，吞吐量一直上不去？如果瓶颈是由于代码问题导致的，请问如何定位？ 1、压测服务器 单场景压测被测系统的登录接口，压力曲线模型如下： 压测策略： 施压20个线程，每30秒增加2个线程，重点关注压力增加的这段。 监控平台： grafana+prometheus+node_exporter+influxdb 2、性能指标监控 Jmeter性能指标 基本分析：压力在不断增大（上图右侧曲线），但吞吐量却始终保持在
【流量发起】吞吐量上不去的问题
sysu_lluozh
10-08 1万+
在做一个项目的性能测试，发现增大并发用户数的时候，响应时间没有增加，但tps并没有提升，这并不符合“逻辑” 线程数：300+100 线程数：750+250 一、被测服务带宽等原因引起 将被测服务扩容且分布不同但宿主机，得到的数据和改变后无差别，且此时的被测服务的cpu、网络等指标均正常，故可以排除该可能性 二、是否是客户端肉鸡出现了时间误差导致 线程数：100 同步所有肉鸡的时间后 故排除...
压力测试中TPS一直上不去，是什么原因？
05-25
TPS（Transactions Per Second）能否达到预期值受到多个因素的影响，例如系统架构、硬件配置、网络带宽、数据库性能等等。以下是可能导致TPS上不去的一些原因： 1. 硬件资源不足：如果服务器的CPU、内存、磁盘等硬件资源不足，会导致系统负载过高，从而限制TPS的上限。 2. 网络带宽不足：如果系统需要大量的网络传输，但是网络带宽不足，会导致请求响应变慢，从而限制TPS的上限。 3. 数据库性能问题：如果数据库的性能没有经过优化，或者出现了性能问题，会导致TPS下降。 4. 代码实现问题：如果系统代码实现存在问题，例如代码中存在死循环、内存泄漏等问题，会导致系统运行缓慢，从而限制TPS的上限。 针对上述问题，可以通过优化系统架构、增加硬件资源、优化网络配置、优化数据库性能、检查代码实现等方式来提高TPS。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

萌翻天

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值