性能测试分析案例-定位redis响应延迟

这篇具有很好参考价值的文章主要介绍了性能测试分析案例-定位redis响应延迟。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

环境准备

预先安装 docker、sysstat 、git、make 等工具,如 apt install docker.io sysstat

操作和分析

案例由 Python 应用 +Redis 两部分组成。其中,Python 应用是一个基于 Flask 的应用,它会利用 Redis ,来管理应用程序的缓存,并对外提供三个 HTTP 接口:
/:返回 hello redis;
/init/:插入指定数量的缓存数据,如果不指定数量,默认的是 5000 条;
缓存的键格式为 uuid:
缓存的值为 good、bad 或 normal 三者之一
/get_cache/<type_name>:查询指定值的缓存数据,并返回处理时间。其中,type_name 参数只支持 good, bad 和 normal(也就是找出具有相同 value 的 key 列表)。
案例需要两台虚拟机,其中一台用作案例分析的目标机器,运行 Flask 应用,它的 IP 地址是 xxx.xxx.xxx.xxx;而另一台作为客户端,请求缓存查询接口
性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
在第一个终端中,执行下面的命令,运行本次案例要分析的目标应用。正常情况下,你应该可以看到下面的输出:

# 注意下面的随机字符串是容器ID,每次运行均会不同,并且你不需要关注它
docker run --name=redis -itd -p 10000:80 feisky/redis-server

docker run --name=app --network=container:redis -itd feisky/redis-app

再运行 docker ps 命令,确认两个容器都处于运行(Up)状态:

docker ps

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
第二个终端,使用 curl 工具,访问应用首页。如果你看到 hello redis 的输出,说明应用正常启动:

curl http://xxx.xxx.xxx.xxx:10000/

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化

继续在终端二中,执行下面的 curl 命令,来调用应用的 /init 接口,初始化 Redis 缓存,并且插入 5000 条缓存信息。这个过程比较慢,比如我的机器就花了十几分钟时间。耐心等一会儿后,你会看到下面这行输出:

# 案例插入5000条数据,在实践时可以根据磁盘的类型适当调整,比如使用SSD时可以调大,而HDD可以适当调
curl http://xxx.xxx.xxx.xxx:10000/init/5000

继续执行下一个命令,访问应用的缓存查询接口。如果一切正常,你会看到如下输出

curl http://xxx.xxx.xxx.xxx:10000/get_cache

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
这个接口调用居然要花3秒!这么长的响应时间,显然不能满足实际的应用需求。
要把 curl 命令放到一个循环里来执行。你可以在终端二中,继续执行下面的命令:

$ while true; do curl http://xxx.xxx.xxx.xxx:10000/get_cache; done

终端一中执行 top 命令,分析系统的 CPU 使用情况:
性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
CPU的 iowait 比较高,已经达到了 30%;而各个进程的 CPU 使用率都不太高,最高的 python 和 redis-server ,也分别只有 19和 12。
综合 top 的信息,最有嫌疑的就是 iowait。所以,接下来还是要继续分析,是不是 I/O 问题。
执行下面的 iostat 命令,查看有没有 I/O 性能问题:

iostat -d -x 1

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
磁盘 sda 每秒的写数据(wkB/s)为 1.3MB,I/O 使用率(%util)是 70。看来,虽然有些 I/O 操作,但并没导致磁盘的 I/O 瓶颈。

案例问题是从 Redis 缓存中查询数据慢。对查询来说,对应的 I/O 应该是磁盘的读操作,但刚才我们用 iostat 看到的却是写操作。虽说 I/O 本身并没有性能瓶颈,但这里的磁盘写也是比较奇怪的。为什么会有磁盘写呢?那我们就得知道,到底是哪个进程在写磁盘。
运行下面的 pidstat 命令

pidstat -d 1

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
I/O 最多的进程是 PID 为 4355的 redis-server,并且它也刚好是在写磁盘。这说明,确实是 redis-server 在进行磁盘写。
执行 strace 命令

strace -f -T -tt -p 4355

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
运行 lsof 命令

lsof -p 4355

性能测试分析案例-定位redis响应延迟,性能测试,性能测试小白,redis,性能优化
描述符编号为 3 的是一个 pipe 管道,5 号是 eventpoll,7 号是一个普通文件,而 8 号是一个 TCP socket。
我们就找出了 Redis 正在进行写入的文件,也知道了产生大量 I/O 的原因。文章来源地址https://www.toymoban.com/news/detail-792026.html

到了这里,关于性能测试分析案例-定位redis响应延迟的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 基于 Redis 实现高性能、低延迟的延时消息的方案演进

    🎉欢迎来系统设计专栏:基于 Redis 实现高性能、低延迟的延时消息的方案演进 📜其他专栏:java面试 数据结构 源码解读 故障分析 🎬作者简介:大家好,我是小徐🥇 ☁️博客首页:CSDN主页 小徐的博客 🌄每日一句: 好学而不勤非真好学者 📜 欢迎大家关注! ❤️ 随着

    2024年01月22日
    浏览(68)
  • 从库延迟案例分析

    近来一套业务系统,从库一直处于延迟状态,无法追上主库,导致业务风险较大。从资源上看,从库的CPU、IO、网络使用率较低,不存在服务器压力过高导致回放慢的情况;从库开启了并行回放;在从库上执行show processlist看到没有回放线程阻塞,回放一直在持续;解析relay-

    2024年04月12日
    浏览(39)
  • Linux-Stream内存带宽及MLC内存延迟性能测试方法

    1、Stream内存带宽测试   Stream是业界主流的内存带宽测试程序,测试行为相对简单可控。该程序对CPU的计算能力要求很小,对CPU内存带宽压力很大。随着处理器核心数量的增大,而内存带宽并没有随之成线性增长,因此内存带宽对提升多核心的处理能力就越发重要。Stream具

    2024年02月08日
    浏览(36)
  • 【性能测试】运维测试01之性能测试整体认知包括:TPS、请求响应时间、事务响应时间、并发用户数、吞吐量、吞吐率、点击率、资源使用率等性能指标详细介绍

    性能测试整体认知包括:TPS、请求响应时间、事务响应时间、并发用户数、吞吐量、吞吐率、点击率、资源使用率。 1.1 需求一 1.熟悉Linux、windows等操作系统,熟悉shell脚本; ⒉.熟悉jvm调优, tomcat调优等基础策略 3.熟悉mysq数据库,熟练掌握javascript、java、python、groovy等至少一门

    2024年02月16日
    浏览(39)
  • 性能分析5部曲:瓶颈分析与问题定位,如何快速解决瓶颈?

    一、引言 很多做性能测试的同学都问过我这样一个问题:鱼哥(Carl_奕然),你说性能测试的重点是什么? 我的回答很简单:瓶颈分析与问题定位。 在性能项目的整个周期,不管是脚本设计,脚本编写还是脚本执行,都还算简单。 难点在于如何定位瓶颈,分析瓶颈,解决瓶颈。

    2024年02月20日
    浏览(44)
  • 【性能测试】03-JMeter使用案例

    (1)步骤 (2)乱码解决 sampleresult.default.encoding=UTF-8 (3)请求响应不一致问题 当发送www.jd.com的http请求时,查看结果树看到的发送消息和HTTP取样器中配置的不完全一样? 原因分析: 查看结果数中 最外层HTTP请求 的 请求信息和响应信息,应该与 子节点中最后一个 HTTP请求的

    2024年02月06日
    浏览(35)
  • CYQ.Data 操作 Redis 性能测试:对比 StackExchange.Redis

    前几天,点开自己的博客,看了一下 CYQ.Data V5系列 都有哪些文章, 发现了一篇2019年写的:CYQ.Data 对于分布式缓存Redis、MemCache高可用的改进及性能测试,于是点进去看了看。 感觉文章中有些表述存有问题,不过不是重点。 重点,看了里面的测试结论,如果四五年过去了,

    2024年03月13日
    浏览(47)
  • openGauss学习笔记-195 openGauss 数据库运维-常见故障定位案例-分析查询语句运行状态

    195.1 分析查询语句运行状态 195.1.1 问题现象 系统中部分查询语句运行时间过长,需要分析查询语句的运行状态。 195.1.2 处理办法 以操作系统用户omm登录主机。 使用如下命令连接数据库。 postgres为需要连接的数据库名称,8000为端口号。 设置参数track_activities为on。 当此参数为

    2024年01月15日
    浏览(56)
  • openGauss学习笔记-198 openGauss 数据库运维-常见故障定位案例-分析查询效率异常降低的问题

    198.1 分析查询效率异常降低的问题 198.1.1 问题现象 通常在几十毫秒内完成的查询,有时会突然需要几秒的时间完成;而通常需要几秒完成的查询,有时需要半小时才能完成。 198.1.2 处理办法 通过下列的操作步骤,分析查询效率异常降低的原因。 使用analyze命令分析数据库。

    2024年01月16日
    浏览(60)
  • app自动化测试之Appium问题分析及定位

    使用 Appium 进行测试时,会产生大量日志,一旦运行过程中遇到报错,可以通过 Appium 服务端的日志以及客户端的日志分析排查问题。 Appium Server日志-开启服务 通过命令行的方式启动 Appium Server,下面来分析一下启动日志,日志第一行显示了 Appium 版本信息和服务在本地的运行

    2024年02月14日
    浏览(35)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包