随笔分类 -  服务端性能测试

摘要:因为做性能测试分析的人来说,HTTP 协议可能是绕不过去的一个槛。在讲 HTTP 之前,我们得先知道一些基本的信息。 HTTP(HyperText Transfer Protocol,超文本传输协议),显然是规定了传输的规则,但是它并没有规定内容的规则。 HTML(HyperText Marked 阅读全文
posted @ 2021-06-08 15:07 丝瓜呆呆 阅读(305) 评论(0) 推荐(1) 编辑
摘要:正式场景前的基准测试 在没有做业务混合场景之前,我们需要先做 Benchmark 测试,来确定一个登录业务能支持多少的业务量,这样就可以在业务混合场景中,根据场景中各业务的比例来确定登录的数据需要多少真实的数据。 summary + 125 in 00:00:04 = 31.0/s Avg: 28 阅读全文
posted @ 2021-06-08 11:56 丝瓜呆呆 阅读(294) 评论(0) 推荐(0) 编辑
摘要:对每一个性能测试工具来说,关联和断言都是应该具备的基本功能。 关联 现在做性能测试的,有很多都是单纯的接口级测试,这样一来,关联就用得更少了。因为接口级的测试是一发一收就结束了,不需要将数据保存下来再发送出去。 那么什么样的数据需要关联呢?满足如下条件的数据都是需要关联的: 数据是由服务器端生成的; 阅读全文
posted @ 2021-06-08 11:05 丝瓜呆呆 阅读(113) 评论(0) 推荐(0) 编辑
摘要:在脚本实现中,我们最常用的协议就是 HTTP 和 TCP 了吧,所以在今天的内容里,我简单地说一下如何编写 HTTP 和 TCP 脚本,以应测试主题。 先上图 我们知道 HTTP 是应用层的协议之一,现在很多场景都在用它,并且是用的 HTTP1.1 的版本,对应的是 RFC2616,当然还有补充协议 阅读全文
posted @ 2021-06-08 10:24 丝瓜呆呆 阅读(7812) 评论(0) 推荐(0) 编辑
摘要:什么是并发 并发数是 16TPS,就是 1 秒内整个系统处理了 16 个事务。 在线用户数、并发用户数怎么计算 如上图所示,总共有 32 个用户进入了系统,但是绿色的用户并没有任何动作,那么显然,在线用户数是 32 个,并发用户数是 16 个,这时的并发度就是 50%。 但在一个系统中,通常都是下面 阅读全文
posted @ 2021-06-07 16:54 丝瓜呆呆 阅读(2313) 评论(0) 推荐(0) 编辑
摘要:通常我们都从两个层面定义性能场景的需求指标:业务指标和技术指标。 我在这里借用大神的一张示意图以便你理解业务指标和性能指标之间的关系。 所有的技术指标都是在有业务场景的前提下制定的,而技术指标和业务指标之间也要有详细的换算过程。同时,在回答了技术指标是否满足的同时,也能回答是否可以满足业务指标。 T 阅读全文
posted @ 2021-06-07 11:33 丝瓜呆呆 阅读(862) 评论(0) 推荐(0) 编辑
摘要:在这个图中,定义了三条曲线、三个区域、两个点以及三个状态描述。 三条曲线:吞吐量的曲线(紫色)、使用率 / 用户数曲线(绿色)、响应时间曲线(深蓝色)。三个区域:轻负载区(Light Load)、重负载区(Heavy Load)、塌陷区(Buckle Zone)。两个点:最优并发用户数(The Op 阅读全文
posted @ 2021-06-07 09:49 丝瓜呆呆 阅读(380) 评论(0) 推荐(0) 编辑
摘要:一、性能测试概念 性能测试针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件之下执行性能场景,分析判断性能瓶颈并调优,最终得出性能结果来评估系统的性能指标是否满足既定值。 二、性能测试需要有指标 时间指标、容量指标和资源利用率指标。 三、性能测试需要有模型 模型是什么? 阅读全文
posted @ 2021-06-04 17:00 丝瓜呆呆 阅读(158) 评论(0) 推荐(0) 编辑
摘要:一、性能测试基本概念 (1)为什么要做性能测试? 满足用户使用需求:网站访问量大奔溃,12306,微博,外卖 最小化成本:新服务上线不知道要部署多少台服务器 评估应用系统性能,给运维做系统容量规划提供依据、给开发提供应用调优参考。 (2)什么是性能测试? 模拟多个用户的操作,对服务器硬件性能的影响。 阅读全文
posted @ 2021-06-03 15:46 丝瓜呆呆 阅读(74) 评论(0) 推荐(0) 编辑
摘要:1.现象 QPS、TPS降低,CPU使用率超高导致宕机; 磁盘IO过高,网卡IO被占满 2.原因 SQL查询速度慢,语句效率低下; 服务器硬件性能差; 表数据文件巨大,表单超过千万行; 资源锁定造成数据库事务超时,数据库死锁; 事务粒度过大 3.解决办法(主要解决数据库的问题) 定位资源占用较大的事 阅读全文
posted @ 2021-05-20 15:56 丝瓜呆呆 阅读(72) 评论(0) 推荐(0) 编辑
摘要:1.现象 磁盘读写速率、IOPS过高,系统出现卡顿 2.原因 SQL写法、参数配置不合理; 交换机故障,网线老化; 存储针列条带宽不足,缓存不足,Qos限制,RAID级别设置不当 3.解决办法(主要解决磁盘IO的问题) 通过把日志和数据库对象分布在独立的设备上 把不同的数据库放在不同的硬盘上 阅读全文
posted @ 2021-05-20 15:55 丝瓜呆呆 阅读(269) 评论(0) 推荐(0) 编辑
摘要:1.现象 项目内存持续增加; 响应时间成规律性的先增加后回落; 查看应用日志,会出现OutOfMemoryError错误; GC日志发出FULL GC警告; 系统长时间运行后出现访问错误或宕机 2.原因 启动参数内存值设定得过小; 代码中存在死循环或者循环产生过多重复的对象实体; 集合类中有对对象的 阅读全文
posted @ 2021-05-20 15:54 丝瓜呆呆 阅读(61) 评论(0) 推荐(0) 编辑
摘要:1.现象 系统访问卡顿,QPS、TPS降低,响应时间延长,网络吞吐量降低; 应用服务器内存和IO正常,CPU利用率增高 2.原因 线程太多,上下文切换太频繁; GC回收使用了过高的CPU资源; 某段代码陷入了死循环; 锁争用激烈 3.解决方法(主要解决CPU的问题) 考虑使用更高级的CPU代替当前的 阅读全文
posted @ 2021-05-20 15:53 丝瓜呆呆 阅读(63) 评论(0) 推荐(0) 编辑
摘要:TPS=并发用户/平均响应时延 1、网络带宽 在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,那么就会造成网络资源竞争,间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少,造成请求等待。连接池一般分为服务器连接池(比 阅读全文
posted @ 2021-05-20 15:52 丝瓜呆呆 阅读(686) 评论(0) 推荐(0) 编辑
摘要:1.先top ,然后按1 发现load average负载高. 然后用mpstat -P ALL 发现iowait不高,所以内存和IO暂时排除,top中wa不高,也验证了I/O没有问题 找其他导致CPU高的原因,找进程,找到占用CPU高的java进程PID,分别为1932,30693和30788 利 阅读全文
posted @ 2021-05-20 15:39 丝瓜呆呆 阅读(76) 评论(0) 推荐(0) 编辑
摘要:一.操作系统计数器和分析 1.内存分析方法 iostat命令 Read(write) per sec :磁盘读写次数,一般>5,表示磁盘读,而不是缓存读 r/s w/s 磁盘使用率高,磁盘队列长(wait),而Read(write) per sec小,就是磁盘瓶颈 队列变长,而Read(write) 阅读全文
posted @ 2021-05-20 15:36 丝瓜呆呆 阅读(147) 评论(0) 推荐(0) 编辑
摘要:一、CPU 查看使用情况: 1.vmstat 统计1-id计数 2.sar -u 统计1-%idle计数 3.dstat 统计1-idl计数 4.mpstat -P ALL 统计 1-%idle计数 5.ps 统计CPU计数 满载:vmstat 的r计数 sar -q, 错误:perf工具捕获错误信 阅读全文
posted @ 2021-05-20 15:32 丝瓜呆呆 阅读(126) 评论(0) 推荐(0) 编辑
摘要:一.操作系统计数器和分析 1.内存分析方法 iostat命令 Read(write) per sec :磁盘读写次数,一般>5,表示磁盘读,而不是缓存读 r/s w/s 磁盘使用率高,磁盘队列长(wait),而Read(write) per sec小,就是磁盘瓶颈 队列变长,而Read(write) 阅读全文
posted @ 2021-05-20 10:00 丝瓜呆呆 阅读(115) 评论(0) 推荐(0) 编辑
摘要:1.kafka主要看堆积消息数,生产速率,消费速率 2.数据库主要关注: CPU, QPS ,TPS, 行锁,慢日志,数据库总连接数(有没有连满,连满会连接拒绝) 3.JVM:内存:主要看新生代内存,老生代内存和FULLGC。 快速分析定位内存泄漏,和初始内存是否合理 线程: 死锁,空闲执行和粘滞线 阅读全文
posted @ 2021-05-19 17:01 丝瓜呆呆 阅读(280) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示