首页 > 其他分享 >SDK性能压测

SDK性能压测

时间：2023-04-03 19:33:45浏览次数：48  
标签：jmx 压测 性能 接口 并发 login jmeter SDK

https://gerzz-interactive.feishu.cn/docx/Rvx5dMPAaovtUZxArmDc5Mefnbg

 

一：搭建环境

  • jdk安装+设置环境变量+验证：11.0.18版本
  • jmeter安装+设置环境变量+验证：apache-jmeter-5.5
  • secureCRT9.3安装
  • 压测服务器配置：8核32G，网卡150兆   Host hssh505 HostName 180.184.138.70 Port 22   应用服务器配置：8核64G   Host hssh504 HostName 180.184.143.173 Port 22
mysql服务器配置：8核16G，硬盘200G，最大连接数8000

二：接口数据

2.1：http请求头默认值

  • 协议：Https
  • 测试环境IP：test-console.dubbing.tech
  • 生产环境IP：console.dubbing.tech
  • 服务器域名：load-console.dubbing.tech
  • 服务器新域名：180.184.143.173，port7777，协议http，路径无api
  • 请求方式：post/get
  • 登录/set specker激活音色（post）
  • Get SpeckerList音色列表/Ping心跳检测(get)
 

2.2：接口路径

 

2.3：http信息头管理器

2.3.1：四个接口都需添加，作用域为全局线程组

Authorization： DubbingSdk access_key="abcde",timestamp="111",nonce="aaa",id="520",signature="9HenOZWwiBKK6Jm25s6iog4r1f8=",avc="151-2522"  

2.3.2：setSpeaker选择激活音色，单独设置http信息头管理器

Content-Type：application/json    

2.4：请求入参

setSpeaker选择激活音色： { "speakerId": 189 }  

2.5：服务器运行前拷贝jmx

拷贝本地jmx文件至服务器：
  • 默认root
  • 进入目录 cd /home/sunlin/apache-jmeter-5.5/bin
  • Put *.jmx
  • ls验证拷贝结果
  • lcd C:\Users\Administrator\Downloads\apache-jmeter-5.5\apache-jmeter-5.5\bin 在linux服务器远程看本地
lpwd看本地路径 lls远程看本地详情
  • cd /home/sunlin/apache-jmeter-5.5/bin FTP窗口看本地linux服务器的路径
  • 更改文件拥有者权限   chown sunlin *.jmx   chown sunlin:sunlin *.jmx
 

三：测试环境

3.1：空跑基准压测

3.1.1：接口路径
/api/health /api/sdkra/pingpong（校验sign标签）
3.1.2：压测记录
随着负载并发增加，tps线性增加，符合预期    
3.1.3：达到瓶颈
由于nginx上限18000，所以压测最多到18000则达到瓶颈：出现错误率  

3.2：多接口压测

3.2.1：1并发，tps正常(音色列表优化前)
3.2.2：50并发，tps正常(音色列表优化前)
 
3.2.3：100并发(音色列表优化前)
 
3.2.4：100并发（音色列表优化后）响应时间明显增快
 
3.2.5：200并发，tps正常
 
3.2.6：300并发，tps降低，但由于响应时间增长，目前tps值属于正常现象
 
3.2.7：再次300并发，tps略微升高，考虑是由于网络原因导致tps小幅度波动，目前tps值均属正常
 
3.2.8：500并发，音色列表优化前
 
3.2.9：500并发，音色列表优化后，响应速度增快吞吐量增加，所以优化有明显效果
 
3.2.10：800并发出现异常并实行优化
查看结果树发现，响应数据报错：java.net.SocketException: Connection reset 解决方案：优化本地配置 新建txt,保存以下脚本修改后缀为reg文件，编辑值如下，保存后双击执行；重启电脑，再次压测即不会出现该报错。 解析中值为10进制，下方脚本已全转换为16进制。   Windows Registry Editor Version 5.00   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]   “MaxUserPort”=dword:fffe   “TcpTimedWaitDelay”=dword:1e   “TcpNumConnections”=dword:fffffe   “MaxFreeTcbs”=dword:7D0   “MaxHashTableSize”=dword:10000   内容解析： MaxUserPort：最大动态端口数（Default = 5000, Max = 65534） TcpTimedWaitDelay：TCP等待延迟时间（30） TcpNumConnections：TCP最大连接数（Default = 16,777,214） MaxFreeTcbs：最大TCP控制块（1000-2000） MaxHashTableSize：最大TCB Hash table数量（64-65536）  
3.2.11：回归800并发无异常，优化有效果
 
3.2.12：优化login接口后800并发，响应时间变快但tps降低
 
3.2.13：达到瓶颈
并发数高于1000后tps过低，由于测试环境系统上限1024M，目前最高只能压到1000，考虑转移至预生产环境压测  

四：预生产环境

同步定时器1000并发   3000并发出现异常，考虑单台电脑支撑不了大并发，准备分布式测试  

五：分布式压测

5.1：Jmeter分布式压测原理

总控机器的节点master会把压测脚本发送到 slave上面 执行时，slave上只需要把jmeter-server打开即可，无需启动jmeter 结束后，slave会把压测数据回传给master,最后master汇总输出报告

5.2：主从测试机环境

  • IP(Master):192.168.1.65 windows11
  • IP(slave) : 192.168.1.193 mac
  • 所有机器JDK版本：java version "11.0.18"
  • 所有机器jmeter版本：apache-jmeter-5.5
  • 网络环境：同一个局域网，有线网络
 

5.3：jmeter设置

5.3.1：步骤一

在IP(Master): 192.168.1.65 在jmeter.properties 中添加remote_hosts，添加内容如下两行：
  • remote_hosts=192.168.1.65:1099,192.168.1.193:1099
  • server_port=1099
 

5.3.2：步骤二

在IP(slave) :192.168.1.65 在jmeter.properties中添加 server_port 在IP(slave) :192.168.1.193在jmeter.properties中添加 server_port  

5.3.3：步骤三

在IP(Master) 和 IP(slave) 机器上在jmeter.properties文件中 #server.rmi.ssl.disable=false 改为 server.rmi.ssl.disable=true并保存（主从都改）  

5.3.4：步骤四

  • IP(Master) :192.168.1.65在jmeter-server 文件中：
  #RMI_HOST_DEF=-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx   改为 RMI_HOST_DEF=-Djava.rmi.server.hostname=192.168.1.65,并保存  
  • IP(slave) :192.168.1.193在jmeter-server 文件中：
  #RMI_HOST_DEF=-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx   改为 RMI_HOST_DEF=-Djava.rmi.server.hostname=192.168.1.193  

5.3.5：步骤五

  • IP(slave) :192.168.1.193，只需把jmeter-server打开即可，不用启动jmeter
  • IP(Master)：192.168.1.65如果也作为执行机，也需命令行打开jmeter-server
  • IP(slave) :192.168.1.193，关闭防火墙
  • IP(Master)：ping执行机的ip验证机器在同一网络环境
  • IP(Master)：192.168.1.65打开jmeter，点击运行选择远程启动。
压测过程中执行机的命令行窗口会出现如下内容，主机可在jmeter查看聚合报告  

六：分布式压测过程

6.1：远程启动

IP(Master)：192.168.1.65打开jmeter，点击运行选择远程启动 出现报错如下：Error in rconfigure() method java.rmi.ConnectException: Connection refused to host: 192.168.1.65; nested exception is: java.net.ConnectException: Connection refused: connect  
6.1.1：排查分析执行机
远程启动IP(slave)192.168.1.193 成功运行 telnet 192.168.1.193 1099，提示不是内部命令；由于win11默认未安装telnet，可以手动安装；再次连接无误。 ①、点击左下角的“搜索”图标，在弹出的对话框中输入“功能”，并进行搜索。系统会自动找到“启用或关闭windows功能”。     ②、点击“启用或关闭windows功能”，在功能复选列表中找到“telnet客户端”功能，并勾选他。最后点击确定，系统自动进行安装该组件。     装好后，再回到命令行执行telnet命令，则不会出错。若是较老版本的windows，需依次进入“控制面板>程序与功能>启用或关闭windows功能”进行操作。
6.1.12：排查分析调度机
IP(Master)：192.168.1.65作为调度机，也作为执行机，所以也需打开jmeter-server，再次运行无误  

6.2：负载压测记录

逐步增加线程数，关注响应时间和吞吐量        

6.3：结论

脚本运行通畅、性能压测方案已制定完毕，考虑环境和网络的不稳定因素，需转移至云服务器独立且高配置的环境压测

七：云服务器压测

7.1：服务器配置

一台应用请求服务器；服务器配置：8核32G 一台mysql服务器；服务器配置：8核16G  

7.2：压力机配置

 

7.2：接口数据

7.2.1：接口路径
登录：/api/sdkra/login 音色列表：/api/sdkra/getSpeakerList 激活音色：/api/sdkra/setSpeaker  
7.2.2：HTTP请求默认值
协议：https 服务器名称/ip地址：load-console.dubbing.tech  
7.2.3：HTTP信息头管理器
Authorization： DubbingSdk access_key="abcde",timestamp="111",nonce="aaa",id="520",signature="9HenOZWwiBKK6Jm25s6iog4r1f8=",avc="151-2522"    

7.3：压测数据

7.3.1：并发1，响应时间0.037s，登录tps27
 
7.3.2：并发100，响应时间0.042s，登录tps97.8
 
7.3.3：并发500，响应时间0.043s，登录tps482
 
7.3.4：并发600，响应时间0.041s，登录tps485
 
7.3.5：出现瓶颈
并发650，响应时间0.042s，登录tps488-485，低于并发600的tps  
7.3.6：验证瓶颈
并发2000登录tps389   验证瓶颈：并发3000，响应时间2.8s，登录tps415不符合预期；继续负载压测没有意义，考虑分布式压测
7.3.7：结论
连续多次3000并发，时而通过时而异常，出现不稳定状态 报错：500 Internal Server Error 初步判断由于测试机配置达到瓶颈，因为压测过程中，本机cpu高达100% 考虑先空跑health基准测试，利于对比分析数据  

八：health空跑基准压测

不符合预期，结果不稳定，考虑是外网原因，需部署内网验证 GUI压测本身耗费性能，考虑命令行压测，排除压力机的影响因素，利于精确分析数据    

九：命令行压测

9.1：命令行参数

命令行先进入jmeter的bin目录   命令行压测参数如下： jmeter -n -t test.jmx -l res.jtl -e -o result   再次更改线程数压测需要删除test.jmx,c:\result，否则会报错 win11命令如下： Notepad test.jmx del res.jtl rmdir /s c:\result jmeter -n -t test.jmx -l res.jtl -e -o c:\result

9.2：压测本机存在瓶颈

9.3：win11本机生成sshkey

下载安装secureCRT，命令行输入：ssh-keygen生成sshkey.pub  

十：新服务器压测

10.1：接口命令行参数

jmeter -n -t test.jmx -l view.jtl -e -o /home/sunlin/apache-jmeter-5.5/bin/summary  

10.2：拷贝本地jmx文件至linux服务器

  • lcd C:\Users\Administrator\Downloads\apache-jmeter-5.5\apache-jmeter-5.5\bin 在linux服务器远程看本地
lpwd看本地路径 lls远程看本地详情
  • cd /home/sunlin/apache-jmeter-5.5/bin FTP窗口看本地linux服务器的路径，直接put nginx即可
切换到linux服务器窗口验证，需要断开重连即可刷新文件拷贝成功

10.3：运行完后生成报告

cd summary/ cat statistics.json

10.4：nginx静态页面基准测试

10.4.1：基准命令行参数
jmeter -n -t nginx.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary   1100并发，RT2.6s，tps407   2000并发，RT7.2，tps382，两个指标都遇到瓶颈 3000并发，RT9.5s，tps282  

10.5：health基准测试

10.5.1：Health命令行参数
jmeter -n -t Health.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary 并发数900，RT1.7S，tps320 并发1200，性能极差
10.5.2：health1命令行参数
jmeter -n -t health1.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary 更改路径，端口号 服务器jvm内存泄漏 优化，jvm512m，内存32g后台有线程一直在运行导致内存泄漏;清理内存删除日志后 负载5000并发 负载10000并发，符合预期 负载20000，jvm内存泄漏，需要更改内存配置  

10.6：多接口测试

10.6.1：多接口命令行参数
jmeter -n -t test.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary
10.6.2：并发1200，RT6.7S，不符合预期
 
10.6.3：优化后并发1200，RT3.64S，优化有效果但仍不符合预期
  由于数据库连接数2000，所以目前是MySQL瓶颈，后续需要升级数据库  
10.6.4：排查分析两台服务器运行效果差异很大
服务器配置分别是8核32g，8核64g，但吞吐量相差十倍； 脚本相同，cpu相同，内存无影响，考虑是网络原因； 新申请的服务器默认网卡是5M，手动调整到150M，再次回归对比2台服务器效果一致。  
10.6.5：负载并发2000，login接口的RT和tps不符合预期
10.6.6：遇到瓶颈负载并发2500
响应7.6s，tps319越来越低；其他2个接口趋势良好 目前的瓶颈在login接口，由于mysql最大连接数2000，所以高于2000并发显然性能上不去  
10.6.7：数据库最大连接数由2000调整至4000
回归1200并发，优化有明显的效果   回归2000并发，和优化数据库连接数之前的效果一样，考虑是应用服务器的连接池问题   连接池1800调整到3000；回归2000没效果   并发2000 再次回归2000没效果 并发3000性能越来越差 需继续优化，寻查原因
10.6.8：连接池1800调整至3000
从低负载重新压测 500并发，响应4.2s，吞吐116 1000并发，响应4s，tps236 1500并发，响应3.1s，tps458   回归500并发,比第一次运行性能提升很多，考虑是第一次运行属于初始化动作启动耗费性能 回归1500，性能不符合预期
10.6.9：数据库最大连接数调整为8000
并发500,2s,tps243   并发1000，响应4.5s，tps降低，遇到瓶颈   并发100 并发300,1.7s，169tps     并发700，2.6s，255tps，数据库连接数用到413（因为用完的数据库连接会释放掉）
10.6.10：优化数据库删除一条sql
并发100 并发300   并发700 并发1000  

10.7：login单接口测试

alt+p切换到该窗口： lcd C:\Users\Administrator\Downloads\apache-jmeter-5.5\apache-jmeter-5.5\bin 在服务器远程查看本地文件 lpwd看本地路径 lls远程看本地文件详情 cd /home/sunlin/apache-jmeter-5.5/bin FTP窗口看本地linux服务器的路径，直接put login.jmx即可
10.7.1：命令行参数：
jmeter -n -t login.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary 并发100 并发100 并发800 并发100 并发1

10.8：login1更换路径端口

服务器名称\IP:180.184.143.173 端口：7777 协议：http 路径：/sdkra/login
10.8.1：命令行参数
jmeter -n -t login1.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary   1200并发2次对比   500并发 并发1200 1000并发

十一：多接口压测，有同步定时器

11.1：命令行参数

jmeter -n -t test.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary

11.2：并发1

11.2：并发10（由于初始化需要加载所以需再次回归）

回归10并发 并发100 并发500，响应时间和服务器日志相差太多 并发1000

11.2：目前阻塞节点

排在第一个的接口性能异常 “音色列表”为第一个接口，则响应变慢，tps变低   “激活音色”为第一个接口，则所有接口的性能都异常 “登录”为第一个接口，所有接口性能异常       100并发，循环100次，性能正常

十二：单接口压测

12.1：命令行参数

jmeter -n -t Health.jmx -l view.jtl -X -e -o /home/sunlin/apache-jmeter-5.5/bin/summary jmeter -n -t login.jmx -l view.jtl -e -o /home/sunlin/apache-jmeter-5.5/bin/summary jmeter -n -t LoginOldNone.jmx -l view.jtl -e -o /home/sunlin/apache-jmeter-5.5/bin/summary

12.2：Health单接口并发10000

12.2：login单接口，有同步定时器

100并发2次，结果一致 500并发  

12.3：login单接口，无同步定时器

GUI压测login单接口1000  

12.3.1：非GUI压测login单接口并发1000，两次

 

12.3.2：非GUI压测login单接口并发2000，两次

 

12.3.3：非GUI压测login单接口并发3000，两次

12.3.4：非GUI压测login单接口并发4000，两次

12.3.5：非GUI压测login单接口并发5000，两次

12.3.6：非GUI压测login单接口并发7000，两次

12.3.7：非GUI压测login单接口并发9000，三次

12.3.8：结论

login接口的并发数： 2000个线程数，运行时间3s 5000个线程数，运行时间6s  

十三：多接口压测，无同步定时器，不勾选keepAlive

13.1：命令行参数

jmeter -n -t testNone.jmx -l view.jtl -e -o /home/sunlin/apache-jmeter-5.5/bin/summary

13.2：并发100

13.3：并发500

13.4：并发1000

13.5：并发1200

13.6：并发1500

13.7：并发5000，出现丢请求数据现象

13.8：并发7000

13.9：并发9000

13.10：并发10000，login整体运行8s

13.11：并发12000，login整体运行9s

13.12：并发20000，时而请求通过时而报错

13.13：最大连接数达到瓶颈

时不时报错“too many openfile”，需排查分析： 应用程序（进程管理）最大连接数的限制（文件数的限制）之前是4096，所以跑到4000左右则时不时报错 “too many openfile”，或4000以上不报错的情况下会出现丢请求现象，现在将最大连接数更改至52w；再次回归验证： 9000并发，发现日志报错无权限，排查分析是SET SPECKER的请求参数非json格式，修改后重新压测：

13.14：入参格式优化

13.14.1：命令行参数

jmeter -n -t testno.jmx -l view.jtl -e -o /home/sunlin/apache-jmeter-5.5/bin/summary

13.14.2：优化请求参数后

1000并发，运行3s
3000并发，运行6s
4000并发，运行8s
5000并发，运行2s
 
9000并发
11000并发出现异常，后台显示只有3000多条数据，丢失大部分请求

十四：SDK性能压测结果（3.31日）

单台大饼应用服务器压测数据： keepalive关闭状态
并发数 login接口/响应时间 吞吐量 运行时间 cpu 备注      
1000 0.9s 311 3s 符合预期        
3500 0.271s 426 7s 符合预期        
5000 21ms 467 9s 符合预期        
7000 28ms 557 11s 30%符合预期        
9000 24ms 684 11s 50%符合预期        
11000 0.65s 750     出现丢请求现象 性能不符合要求    
15000 0.9s 244     tps大幅度下降 性能不符合要求    
 

十四：SDK性能压测结果（4.3日）

jmx：testno.jmx keepalive状态：关闭 循环运行次数：1次 疑问：为什么并发数越少响应时间越久？
并发数 login响应时间 login吞吐量   音色列表响应时间 音色列表 吞吐量 激活音色 响应时间 激活音色 吞吐量 备注  
1000 1.49s 269 35ms 417 0.169s 414    
2000 1.4s 380            
3000 0.52s 449 11ms 523 12ms 523    
5000 28ms 503 8ms 605 12ms 607    
7000 29ms 539 9ms 635 13ms 637    
9000 33ms 680 9ms 742 14ms 743 压测上限  
9500 46ms 626 10ms 745 16ms 755 出现瓶颈  
10000 2.2s 555 12ms 627 17ms 639 不符合  
11000 25s 270 11ms 279 15ms 281 不符合  
  jmx：keepalive.jmx keepalive状态：开启 循环运行次数：1次
并发数 login响应时间 login吞吐量   音色列表响应时间 音色列表 吞吐量 激活音色 响应时间 激活音色 吞吐量 备注  
1000 1.24s 335 9ms 535 8ms 544    
2000 1s 498 6ms 662 12ms 663    
2000 0.6s 504 4ms 634 6ms 635    
3000 2s 450 5ms 631 8ms 631    
3000 79ms 494 6ms 655 8ms 656    
5000 16ms 587 3ms 694 6 698    
5000 18ms 536 3ms 694 6 698    
7000 1.8s 112 0.24s 116 0.98 58 异常  
7000 26ms 654 5ms 765 8ms 765    
7000 55ms 636 4ms 775 7ms 776    
9000 66ms 734 4ms 876 8ms 876    
9000 60S 126 15ms 128 60s 69 异常  
9000 4.5s 576 4ms 610 8ms 611 异常  
9500 60s 133 16ms 135 4.9s 74 异常  
9500 1.7s 673 16ms 740 0.8s 688 不符合  
10000 29s 234 4ms 246 9ms 246 不符合  
  jmx：nokeepalive.jmx keepalive状态：关闭 循环运行次数：10次
并发数 循环次数 login响应时间 login吞吐量   音色列表响应时间 音色列表 吞吐量 激活音色 响应时间 激活音色 吞吐量 备注
100 10 94ms 517 68ms 730 79ms 730  
500 10 0.6s 611 0.3s 812 0.29 841  
1000 10 0.9s 638 0.6s 913 0.5 924  
1500 10 0.18s 884 0.15s 984 0.15s 985  
2000 10 0.11 1170 83ms 1313 86ms 1314  
2500 10 6s 363 8ms 370 60ms 371 不符合
3000 10 11s 261 8ms 265 86ms 265 不符合
5000 10             出现异常error
 

标签：jmx,压测,性能,接口,并发,login,jmeter,SDK
From： https://www.cnblogs.com/sunlin1107/p/17284108.html

相关文章

  • 前端Vue项目打包性能优化方案
    一.前言Vue框架通过数据双向绑定和虚拟DOM技术，帮我们处理了前端开发中最脏最累的DOM操作部分，我们不再需要去考虑如何操作DOM以及如何最高效地操作DOM；但Vue项目中仍然存在项目首屏优化、Webpack编译配置优化等问题，所以我们仍然需要去关注Vue项目性能方面的优化，使项......
  • 小程序SDK的发展趋势与未来展望
    随着移动互联网的发展和普及，小程序作为一种轻量级的应用形态，越来越受到开发者和用户的欢迎。为了满足不同行业和场景的需求，现在市面上也出现了许多以小程序开发为主要技术的应用开发解决方案，即将一个小程序SDK内嵌至App中，并引入已有的小程序作为App中场景的展现。什么是小程序S......
  • 性能分析之内核调试工具
    最近给自己定了些任务，把PPT重新编写一下，所有性能相关的话题都在计划的范围里。最近这几天在整理调试工具的培训PPT，本来是在7DGroup的云服务器上做实例的。结果发现有些数据显示不出来。看来现在的调试工具也是需要更新了，还要再出新版支持现在的云主机了。今天下午特地找了个物理机......
  • 性能分析之数据理解和数学基础
    PS：差不多完成了这一轮性能培训相关PPT的编写，一个最艰苦的部分也有了起色。对于每一个做性能分析的来说，不可跳过的一个提升阶段是对数据的理解。当初学者经历了工具的使用之后，下一步就面对了工具产出的数据，所以看得懂数据是必须的一个过程。性能分析中的数据理解：在数据理解上，有两个......
  • Spark视频王家林第119课： Spark Streaming性能优化：如何在生产环境下应对流数据峰值巨变
    Spark视频王家林第119课：SparkStreaming性能优化：如何在生产环境下应对流数据峰值巨变？本节讲解SparkStreaming性能优化：如何在生产环境下应对流数据峰值巨变？数据峰值及流量变化的不稳定有2个层面：1）第一个层面就是数据确实不稳定，例如晚上11点的时候访问流量特别高，相对其他时间而言表......
  • 从MLSQL性能设计到对架构师的重新思考
    从MLSQL性能设计到对架构师的重新思考五年前，我会认为，架构仅仅是针对一个可大可小的问题，把流程设计好，然后往里面填充合适的组件，从而最终解决这个问题。在这个过程中，区分架构师是否资深主要是在设计过程中对可扩展性，可维护性，以及成本权衡的把控能力。现在，我觉得架构不应该仅仅是这样......
  • 性能分析之调试工具——GDB之二
    由于上一个GDB的写的水份比较足，所以应看官们的要求，来写些具体的东西。其实网上有很多GDB的教程。我也搜索过。但是总是有那么一两个点缺少的。所以决定自己还是把工作中的记录一些下来。至少是具体工作中的实践操作。前几天因为遇到个redis的问题，所以编译了一下reids，并且做一些监控......
  • 性能分析之dubbo性能参数导致单cpu高
    今天记录一个小问题。问题不大，也没什么分析的逻辑可以讲的。但是想着比较典型，所以就写一写。某年某月的某一天，就像一张破碎的脸......不对，串台了。这一日，一个朋友发来个问题。听起来是个问题。一个线程忙，这种情况应该比较好处理吧。再看一下CPU的状态是什么样，记住这一步是看进程......
  • 性能分析之一个阿里云环境公众号小程序服务性能分析案例
     前天有个认识多年的做性能测试的朋友发了个信息给我。让我帮他分析一个问题。一看到性能问题描述，我就想骂人，你自己也做性能测试十年以上了，性能问题还来问我？这家伙是来考我的，第一印象就是这样。摘抄关联信息如下： 场景30分钟，用户100递增到1000，应用服务器CPU使用率70%-80%。tomcat......
  • 性能分析之OS资源饱和度
    在做性能分析的时候，我们不可避免地判断资源到底够不够用？哪里不够？为什么不够？证据是什么？回复得了这些问题并不容易。今天就来絮叨一下OS资源饱和度应该如何衡量。现在kubernets盛行，所以这里来借用k8s中部署的prometheus+grafana来看直观的看图。CPU资源：先看一个图：一边是CPU使用率，一边......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99