服务器性能测试
文章平均质量分 90
本专栏专门提供性能相关技巧和经验
李先森&Mr.Li
我看到了太多想提升测试技术而没有明确方向的人,深刻的体会到测试人员的技术痛点,以及测试这个角色在互联网公司的待遇和地位远不及其他岗位,甚至还是会有很多人会认为测试在公司随时能被取代,可有可无。那么在软件测试行业如果只会手工测试的我不做测试了,我还能做什么?唯一办法就是保持持续的学习!!!
展开
-
全链路压测的“谜”
面对全链路线上压测,希望你理性分析它的实施成本和上层的支持力度。切忌在没有必要的航线上不断试错。如果你的企业确实需要做全链路压测,那就要把改造的细节列清楚,并计算出成本。不盲从,不夸大,不缩小,做真正有价值的事情。毕竟全链路压测本身就是一项综合技术要求很高的实践场景,需要整体IT团队在积累了各种前期的技术储备后,共同协作完成,并不是某个部门或者团队的事,需要有人整体的协调和统筹才能真正落地。...原创 2022-07-25 13:51:45 · 1025 阅读 · 2 评论 -
秒杀链路兜底方案之限流&降级实战
前言:学习本篇博客是有一些前提基础的1、熟悉gateway网关使用2、熟悉nginx使用3、熟悉sentinel的应用,会涉及网关规则持久化改造看不懂的童鞋们可以补一下微服务gateway网关和Sentinel相关知识秒杀链路兜底方案之限流&降级实战一、秒杀场景介绍1.1 秒杀场景的特点1.2 流量消峰1.3 兜底方案二、限流实战2.1 nginx限流(https://nginx.org/en/docs)2.2 网关限流2.2.1 网关接入sentinel控制台2.2.2 Sentinel原创 2021-10-12 16:30:19 · 81959 阅读 · 2 评论 -
kafka性能测试、性能分析与性能调优
前言:最近在做kafka、mq、redis、fink、kudu等在中间件性能压测,压测kafka的时候参考了这篇文章,大家可以借鉴下!一、测试环境测试使用到三台机器,机器配置如下:共同配置:Intel® Core™ i7-7700 CPU @ 3.60GHz、Cores:4、Threads:232GB内存1000Mb/sec网卡差异化配置2TB、7200rpm、SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)1TB、7200rpm、SATA 3.1, 6.0Gb转载 2021-08-23 15:28:55 · 52905 阅读 · 1 评论 -
jmeter发送kafka数据key错误且无法生成时间戳解决方案
前言:最近在做kafka、mq、redis、fink、kudu等在中间件性能压测,压测kafka的时候遇到了一个问题,我用jmeter往kafka发消息没有时间戳,同样的数据我用python发送就有时间戳,且jmeter会自动生成错误的变量key,那我是怎么解决的呢,容我一一道来!一、jmeter怎么往kafka发送数据jmeter往kafka发送数据我之前有写过博客,大家可以参考下,遇到我前言说的问题就可以参考本篇文章二、jmeter生成错误key解决方案我们用了kafka插件后jmeter中引入原创 2021-08-23 15:07:26 · 81364 阅读 · 5 评论 -
分析SQL语句性能必备知识(explain命令详解)
前言:在日常工作中,我们会有时会开慢查询去记录一些执行时间比较久的SQL语句,找出这些SQL语句并不意味着完事了,些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划,查看该SQL语句有没有使用上了索引,有没有做全表扫描,这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器,还可以获得很多可能被优化器考虑到的访问策略的细节,以及当运行SQL语句时哪种策略预计会被优化器采用。(QEP:sql生成一个执行计划query Execution plan)expa原创 2020-11-12 09:06:19 · 37795 阅读 · 0 评论 -
JAVA 线上故障排查完整套路,从 CPU、磁盘、内存、网络、GC 一条龙服务!
前言:线上故障主要会包括cpu、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df、free、top 三连,然后依次jstack、jmap伺候,具体问题具体分析即可。一、CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的,可以使用j转载 2020-09-14 18:03:51 · 75697 阅读 · 2 评论 -
JVM 线上故障排查基本操作
前言:对于后端程序员,特别是 Java 程序员来讲,排查线上问题是不可避免的。各种 CPU 飚高,内存溢出,频繁 GC 等等,这些都是令人头疼的问题。楼主同样也遇到过这些问题,那么,遇到这些问题该如何解决呢?首先,出现问题,肯定要先定位问题所在,然后分析问题原因,再然后解决问题,最后进行总结,防止下次再次出现。今天的文章,就如我们的题目一样,讲的是基本操作,也就是一些排查线上问题的基本方法。为什么这么说呢?因为线上问题千奇百怪,就算是身经百战的专家也会遇到棘手的问题,因此不可能在一篇文章里说完,还有一个转载 2020-09-14 17:40:58 · 12986 阅读 · 0 评论 -
软件性能测试的10大误区你中了几个?
前言:初入性能测试的小伙伴们会进入误区么?可能你自己都不知道自己踩坑了,要不跟着我一起瞧瞧!误区1:应用程序必须通过功能测试后才可以测试性能应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中,即使是在单元层,一个单独模块的性能也可以使用白盒测试来进行评估,然而,只有当整个系统的所有成分都集成到一起后,才能检查一个系统的真正性能。性能测试从早开始,完成一个小模块,对小模块的接口进行性能测试,一般耗费资源很少,但可以防止问题在项目最后出现,花费很大的精力去修改。而有些资料中提到的:在系统代码开发和原创 2020-09-11 16:16:13 · 15191 阅读 · 0 评论 -
对秒杀系统进行性能压测,你需要了解一些秒杀系统相关的知识点
前言:秒杀抢购系统的成功平稳运行,有一些需要注意的知识点。高并发,以及刷接口等黑客请求对服务端的负载冲击,高并发时带来的超卖,即商品数量的控制,高负载下,下单的速度和成功率的保证,其他等以秒杀单品为例,如抢小米手机。解决方案探讨:1、第一步限制前端发来的请求量例如定在了周二10点开启抢购,那么在之前的一周时间内,都会有预约通知,或者普通的用户浏览。通过预约量、浏览量等数据分析,大概能预估到在周二会参与“点击抢购按钮”的人数。譬如有500万。此时,我们是知道实际商品数量的,譬如20万。那么我是没有原创 2020-08-26 13:03:39 · 4604 阅读 · 0 评论 -
Jmeter分布式压测介绍、原理及实操(一台master-windows控制机,三台slaves-linux负载机)
前言:大家在使用jmeter压测过程中,可能会度遇到内存溢出的错误,这是为什么呢?因为jmeter是java写的应用,java应用jvm堆内存heap受负载机硬件限制,虽然我们可以调整堆内存大小,但是单机无法支撑数以万计大并发,此时,需要多个负载机进行分压测试,这样性能瓶颈就不会受负载机硬件限制了。一、简介:讲解什么是分布式压测普通压测:单台机可以对目标机器产生的压力比较小,受限因素包括CPU,网络,IO等分布式压测:利用多台机器向目标机器产生压力,模拟几万用户并发访问二、简介:讲解Jmete原创 2020-08-26 12:06:35 · 47996 阅读 · 0 评论 -
Jmeter压测运行原理,这些你知道么?
前言:想知道jmeter压测的原理是什么,得先知道性能测试的核心三原则: 基于协议,多线程,场景模拟!基于协议:基于应用层和传输层的各种协议。比如http,udp,ftp,tcp等多线程:通过进程下启动线程的方式来模拟并发用户实现负载场景模拟:通过模拟用户使用的真实场景,来提高性能测试的准确性jmeter压测的核心原理就是:基于各种协议,通过多线程的方式来模拟并发用户,设计各种场景来模拟真实的用户负载所谓压力,其实就是单位时间内向服务器发起的请求数。jmeter在设计压力模式的时候,引入了两层概念原创 2020-08-24 15:46:30 · 9344 阅读 · 0 评论 -
JMeter聚合报告吞吐量误差分析
前言:最近公司有个项目要进行压测,压测完之后发现tps没有达到预期目标,最后自己手动计算了一遍tps,偶然间发现一个问题,JMeter报告中的吞吐量误差较大!下面这个聚合报告是我起的demo,结果如下图:按照经典理论模型计算吞吐量TPS或者QPS应该是等于并发线程数除以平均响应时间:tps =Thread / AVG(t)(并发线程数除以平均响应时间)或者 tps = COUNT(request) / T(总的请求数除以总的请求时间)大家看上图汇总结果:平均响应时间494ms,30并发,计算得到原创 2020-08-24 14:35:33 · 19033 阅读 · 8 评论 -
你不得不了解的jvm知识,还不看?
前言:一个丰富的jvm知识图谱原创 2020-07-15 15:36:54 · 10496 阅读 · 0 评论 -
性能测试中常见的几种性能问题
前言:性能测试结果中,我们关注的指标是tps和art,如果tps低,或者响应时间长,或者服务器资源紧张,那就需要我们去定位性能问题了,常见的性能问题主要包含如下!a.服务器问题cpu内存磁盘io磁盘容量b.网络带宽:看当前收发占用的带宽及有没有丢包c.load高:看线程信息;看是否fgcd.队列问题:磁盘io队列、线程队列e.各种连接池问题:不足或者没释放f.死锁问题:数据库死锁、线程死锁g.慢sql问题h.缓存设置问题知道这些问题是一个很大的进步,但是针对这些问题我们怎么定位呢?原创 2020-07-07 10:02:57 · 13426 阅读 · 1 评论 -
性能测试tps上不去,又是redis的坑,说多了都是泪啊
前言:这是几个月前压测某项目登录接口时遇到的性能问题,虽然大家不一定会遇到,但是分析定位问题的思路还是可以参考一下。1、压测过程中,tps突然剧烈下降,且所有请求失败(下图绿线)服务端错误日志,获取不到redis连接池(Could not get a resource from the pool),另外,从下图可以看到,当前jedis版本是2.9.1获取不到连接,可能是这四种情况: Timeout waiting for idle object Pool exhausted Unabl原创 2020-07-07 09:55:32 · 14709 阅读 · 2 评论 -
性能测试时发现tps波动频繁,我们该如何去定位?这里教你一个定位技巧!
前言:前段时间,压测遇到一个问题,在压测的时候,tps波动很频繁。使用xshell远程连接到应用服务器,通过top命令看了下服务器资源情况,cpu波动也很频繁,其它服务器都正常。打开JvisualVM,双击对应的应用进程然后进入Sampler,在cpu波动的时候点击cpu进行抽样抽样进行一段时间后(一般1-2分钟即可),点击“stop”,然后点击“snapshot”生成快照接着按照“Total Time(CPU)”排序,看哪些线程最耗费cpu,因为我们用的是dubbo框架,所以,我们要分析的原创 2020-07-07 09:36:08 · 14672 阅读 · 0 评论 -
性能测试中你是否遇见过频繁fgc的问题呢?
前言:今天分享一个频繁fgc的问题,现象是接口响应时间太长了,达到了好几秒,远远高于预期的1秒。xshell连接到应用服务器,服务器负载高,且cpu使用率也偏高。使用jstat看了下gc的情况,fgc很频繁,老年代满了(下图的O列)打开JvisualVM,双击对应的应用进程,然后进入Monitor,可以看到堆内存GC频繁。然后进入 Visual GC查看,发现堆内存Full GC非常频繁.根据下面gc日志,Full GC Old区回收的内存很少。现在情况就非常明显了,就是内存中有大量GC不原创 2020-07-07 09:25:01 · 11716 阅读 · 1 评论 -
性能测试过程中发现的问题:数据库cpu高导致响应时间长
前言:前几天在用jmeter做性能测试的时候,遇到一个响应时间长的性能问题,简单总结一下,分享给大家,希望能给大家在性能测试过程中类似问题提供一个性能问题分析定位的思路。现象如下图,响应时间很长,达到了18秒左右,tps也只有20。根据经验,直奔oracle数据库服务器,top命令一看,负载高,用户cpu将近100%,cpu已经达到性能瓶颈了,shift+p,或者键盘大写状态下按P,将所有进程按cpu使用率从高到低排序,这样,我们关注消耗cpu最多的进程即可。直接选取上图第一个进程ID27087,原创 2020-07-07 09:14:42 · 14341 阅读 · 0 评论 -
性能测试过程中获取不到redis连接池如何去定位?
前言:最近在压测过程中,出现获取不到redis连接池的问题,怎么去定位呢?xshell连接redis服务器,查看连接数,发现居然比redis.properties文件中配置的连接数差不多,纳尼?这是怎么回事?redis-cli -p port -a name@password info | grep -e "connected_clients"停止压测后,连接数依旧差不多,难道是连接池没有释放?于是先确认下tcp连接到底是不是都是我那台provider服务器连接过来的,结果发现连接数排序前2个i原创 2020-07-07 08:58:49 · 11730 阅读 · 0 评论 -
在性能压测过程中带宽占用高如何去定位?
前言:压测过程中,tps上不去,监控应用服务器cpu、内存、磁盘、网络、线程栈等等,发现网络传输数据量大,带宽几乎占满了,也就是服务器带宽到达瓶颈点了。服务器网卡一般都是千兆,我们可以确认一下,先用ifconfig来看下当前服务器的网卡,是eth0;另外,lo是本地环路接口。用ethtool查询网卡信息,下面显示的速度是1000Mb/s,注意,这里是Mb,不是MB.b是bit的缩写,称“位”,为一位二进制数,是计算机表示中最小单位,称为"信息基本单位"。如同原子构成所有物质一样,bit构成计算机虚原创 2020-07-07 08:51:07 · 12346 阅读 · 0 评论 -
性能到底要不要熟悉业务逻辑?这篇文章会告诉你答案!
前言:有些朋友说,做性能,不需要了解业务逻辑,直接按接口文档,或者抓包写压测接口的脚本,然后压测、监控、分析、调优、回归;我觉得这样的回答,可能是他们没吃过不熟悉业务逻辑的亏;最近压测的时候,遇到一个等待锁超时的问题,就是因为不熟悉业务逻辑造成设计的脚本不合理,下面和大家分享一下!由于是临时任务、时间紧迫、对应的开发又出差了,他远程信誓旦旦给我说直接压,根本不给我熟悉业务逻辑的机会,赶鸭子上架一样;请求参数用户名是变化的,做了参数化,由于各种客观因素,参数数据只准备了100个,参数取值策略是唯一、用原创 2020-07-07 08:39:15 · 11501 阅读 · 0 评论 -
QPS、TPS、并发用户数、吞吐量之间有什么联系,存在什么关系?
前言:QPS、TPS、并发用户数、吞吐量之间的关系你真的懂么?1、QPSQPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数,也即是最大吞吐能力。2、TPSTPS Transactions Per Second 也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的原创 2020-07-06 13:09:50 · 16551 阅读 · 2 评论 -
性能测试中常见问题个人经验总结,如果有错误,请指正(持续更新中)
前言:性能压测中我们需要明白以下几点1、好的开始是成功的一半,前期的准备非常重要2、过程中,关注每个细节,多个维度监控3、在调优中多积累经验4、对结果负责,测试报告要清晰易懂,追求数据的准确性一、如何分析性能数据(测试结果)答:主要从吞吐量,错误率,资源监控数据,比如一个接口的处理能力为100个/s,高于需求的期望值。错误率为0.001%,期望值为0.01%,最高cpu占用率不超70%。以上指标都符合期待值,那么通过提取这些关键数据就可以记录下来,作为测试的准出标准二、如何快速定位到性能阈值原创 2020-05-15 17:21:59 · 62797 阅读 · 0 评论