记一次Node接口性能测试

前言

突发奇想,想作一点Node应用的性能测试,本身也了解一些性能测试方面的知识,因而用Eggjs写了一个简单的注册接口,进行了简单的压力测试.

原料

  • 开发框架: eggjs sequlize mysql
  • 服务器: 阿里云 1核 1GB 1Mbps(最低配)
  • 测试工具: jmeter

注册接口编写

async login(ctx) { // 登陆
        ctx.validate(userRule);
    
        // 用户校验
        const { name, passwd } = ctx.request.body;
        let user = await ctx.model.User.findOne({
            where: { name: name }
        });
    
        if (user) { ctx.error(user.passwd === passwd, "密码错误或昵称已存在", 10001); }
        else { user = await ctx.model.User.create({ name: name, passwd: passwd }); }
    
        // 生成token和session并存储
        const token = await ctx.service.token.genToken(user.id, ctx.request.ip);
        await app.redis.set(`${app.options.sessionPrefix}:${token.id}`, JSON.stringify({
            user: user.id,
            token: token.id
        }));
        ctx.cookies.set("access_token", token.id);
        ctx.jsonBody = user;
    }

接口逻辑很简单,可见接口中仅有4个I/O操做,下面的性能测试就是针对这个接口.java

安装并配置jmeter

  • 安装jmeter(启动时须要java环境,自行安装)下载传送门
  • 解压jmeter后,启动脚本路径为 apache-jmeter-3.3/bin/jmeter.bat
  • 启动成功后界面
    clipboard.png
  • 下面开始配置测试用例
  1. 配置并发数入口
    clipboard.png
  2. 配置监听器
    clipboard.png
  3. 添加http请求入口/cookie/header等信息
    clipboard.png
  4. 配置好后以下图所示
    clipboard.png

接下来点击开始按钮进行测试.mysql

测试结果及其分析

  • 首先看下图形测试结果:
    clipboard.pngredis

    图表底部参数的含义以下:sql

    • 样本数目:总共发送到服务器的请求数。
    • 最新样本:表明时间的数字,是服务器响应最后一个请求的时间。
    • 吞吐量:服务器每分钟处理的请求数。
    • 平均值:总运行时间除以发送到服务器的请求数。
    • 中间值:表明时间的数字,有一半的服务器响应时间低于该值而另外一半高于该值。
    • 偏离:服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布。
  • 聚合报告结果:
    clipboard.pngapache

    部分参数解释:json

    • Samples: 本次场景中一共完成了多少个Transaction
    • Average: 平均响应时间
    • Median: 统计意义上面的响应时间的中值
    • 90% Line: 全部transaction中90%的transaction的响应时间都小于xx
    • Min: 最小响应时间
    • Max: 最大响应时间
    • PS: 以上时间的单位均为ms
    • Error: 出错率
    • Troughput: 吞吐量,单位:transaction/sec
    • KB/sec: 以流量作衡量的吞吐量
  • 服务器内存/cpu监控:
    clipboard.png
    clipboard.png
  • 总结(不知对否,胡言乱语一下):服务器

    1. 能够看到在2000并发的状况下,Node应用并无跑死,只是响应变得比较慢(机器配置有必定缘由)
    2. 经过服务器状态的监控发现cpu资源的消耗低于内存的消耗(我的以为应该是Node在处理请求时,异步I/O致使了内存消耗比较高)
    3. 感受用户量不是很大的应用Node应该仍是能知足需求的(把集群用上)
相关文章
相关标签/搜索