• 兄弟你的脚本还不如现成的工具呢,一来 requests 库是同步的,二来 cpython 有 GIL,多线程有点鸡肋,虽然对这种主要耗时在I/O的场景影响不大,但以python的性能,最终还是达不到 jmeter、gatling、ab、wrk 的效果。

    至于jmeter是BIO的,这个我一直以为是搞性能的人的常识呢……

    如果有资源,更高压力可以通过多开实例或增加客户端机器达到,但未必会得到你想要的结果。在服务器或后台服务被压死之前,考虑一下请求根本到不了服务的情况:负载均衡/反代/网关/waf掐掉连接,netfilter哈希表用光弃掉IP包,请求在tcp监听队列、接收队列排队直到超时,连接数限制,文件描述符限制,然后spring cloud或tomcat各种配置限制……

    响应时间增加就是在排队,继续增加压力基本上只能看到计算出的响应时间越来越长,因为队列越来越长,后到的请求排了很久的队,最终看到的错误多半是连接超时或响应超时。

    其实不需要真的搞挂什么,只要业务给出这场景能接受的最大响应时间(或99%,99.9%之类)是多少,达到这个数的时候就是极限了。之后还有余量那是用来扛突发情况的,对用户来说不管挂不挂都是不可用了,在某些行业慢几毫秒可能已经出事了。

  • 请问招专职性能测试不?

    学历除了本科有没有硬性要求专业和学校?😂

  • nGrinder - Groovy 脚本指南 at 2018年03月05日

    选型参考:

    优点:

    • 无需安装、跨平台:总共就 controller、agent、monitor 3个 jar 包。
    • 开箱即用,web UI 比较友好,测最简单的 GET 请求上手门槛低。
    • 有简单的可视化报告。
    • 有简单的资源监控。
    • 有简单的脚本管理功能,整合了 SVN。
    • 容易扩容:只需要把 agent 放到压测机器,monitor 放到被测服务器。

    缺点:

    • 发送请求
      • 首页只支持 GET,POST 需要新建脚本然后创建测试。
    • 脚本管理
      • 脚本文件、目录没法重命名,没法移动,只能删掉重新建一份,或通过 SVN 操作。
      • 如果多个脚本使用同样的库和资源文件,UI 里不好搞(除非全塞同一个目录下),需要建完整的 Maven 工程。
    • 报告
      • 1个测试脚本里调多个接口时,报告里看不出这些接口分别是什么、响应时间和 TPS 分别多少。
      • 1个测试脚本里调多个接口时,只要某个测试方法成功,即使其他方法抛异常也不会反映在报告的错误数里,要看 log 才能发现。
      • 脚本里可以定义多个事务,但详细报告里只有总体情况,想看各个事务的数据只能下载 CSV 自己写程序解析。
      • 响应时间没有按百分位数的统计,需要二次开发。
      • 服务器资源监控收集的数据较少,需要二次开发。
      • 想改默认脚本模板很麻烦,需要改源码然后重新打包。

    总结:

    如果非专职做性能测试的人,如开发/运维/业务测试希望有一个简单的工具来定位问题,而且项目用 HTTP 协议、没有很麻烦的鉴权、签名、加密等限制、GET 请求又足够多,nGrinder 可以用。易用性至少跟 PTS、WeTest 一个水平,nGrinder 要写代码的场景这2个平台或者其他工具多半同样要写。

    专职的话它肯定不是首选,开发起来不够快,定位问题也不够方便,有其他更合适的选择。

  • 传好了,在这里下:

    https://github.com/keithmork/oh-my-ngrinder

  • JMeter4.0 变化-迎接 java9 at 2018年03月01日

    感觉最大的变化就是现在打开界面飞快

  • 请问这些修改有提pull request吗?每个人一处处改还是挺麻烦的,版本更新了又得改一次

  • 你找个接口试试?debug sampler的逻辑也许不一样

  • JMeter4.0 变化-迎接 java9 at 2018年02月27日

    JSON assertion终于标准化了,可以少装一个插件😆

  • influxdb那个web控制台很早就没有了,直接上服务器查😀

  • md5函数在插件里,搜 jmeter-plugins 网站,有个插件叫 custom jmeter functions

守正出奇,一身邪气