压测工具 大数据_数据库压测工具 - CSDN
精华内容
参与话题
  • 大数据压力测试工具HiBench

    千次阅读 2018-12-20 09:58:54
    HiBench是一套基准测试套件,用于帮助我们评估不同的大数据框架性能指标(包括处理速度、吞吐等)的负载指标,可以评估Hadoop、Spark和流式负载等 源码下载:wget ...

    需求描述:需要测试cdh集群的组件的性能和稳定性。

    压力测试工具选型:HiBench

    HiBench测试工具说明:

    HiBench是一套基准测试套件,用于帮助我们评估不同的大数据框架性能指标(包括处理速度、吞吐等)的负载指标,可以评估Hadoop、Spark和流式负载等

    源码下载:wget https://github.com/intel-hadoop/HiBench/archive/HiBench-7.0.zip

    源码编译:命令:mvn -Dspark=2.1 -Dscala=2.11 clean package

    官方文档:https://github.com/intel-hadoop/HiBench/blob/master/docs/build-hibench.md

     

    前提条件:

    1)、需要python2.x(>=2.6)

    2)、需要linux bc命令,用于生成Hibench 报告,若没有,则安装:yum install bc

     

    修改配置:

    vim conf/hadoop.conf

    hibench.hadoop.home:hadoop安装目录
    hibench.hadoop.executable:你的bin/hadoop所在目录,一般是{HADOOP_HOME}/bin/hadoop
    hibench.hadoop.configure.dir:hadoop配置文件所在目录,一般位于HADOOP_HOME}/etc/hadoop
    hibench.hdfs.master:hdfs上存储Hibench数据的目录,如:hdfs://localhost:8020/user/hibench
    hibench.hadoop.release:hadoop发行版提供者,支持value:apache, cdh5, hdp
     

     /root/apps/HiBench-master/conf
              -rw-r--r-- 1 root root  245 Dec 12 21:30 benchmarks.lst
    -rw-r--r-- 1 root root  332 Aug 13 02:34 flink.conf.template
    -rw-r--r-- 1 root root   13 Dec 12 21:30 frameworks.lst
    -rw-r--r-- 1 root root  246 Aug 13 02:34 gearpump.conf.template
    -rw-r--r-- 1 root root  471 Dec 13 20:30 hadoop.conf
    -rw-r--r-- 1 root root  448 Aug 13 02:34 hadoop.conf.template
    -rw-r--r-- 1 root root 6600 Dec 18 04:57 hibench.conf
    -rw-r--r-- 1 root root 1640 Dec 18 22:42 spark.conf
    -rw-r--r-- 1 root root 1655 Aug 13 02:34 spark.conf.template
    -rw-r--r-- 1 root root  942 Aug 13 02:34 storm.conf.template
    drwxr-xr-x 8 root root  109 Dec 14 02:49 workloads #里面有对应配置产生的数据量配置

    举例:micro
    [root@gsafety1 conf]# ll /root/apps/HiBench-master/conf/workloads/micro
    total 20
    -rw-r--r-- 1 root root 1920 Aug 13 02:34 dfsioe.conf
    -rwxr-xr-x 1 root root  805 Aug 13 02:34 sleep.conf
    -rw-r--r-- 1 root root  657 Aug 13 02:34 sort.conf
    -rw-r--r-- 1 root root  571 Dec 18 04:40 terasort.conf
    -rwxr-xr-x 1 root root  658 Dec 14 02:38 wordcount.conf

    目录结构:

      /root/apps/HiBench-master/bin/workloads下面有:
                      graph
                      micro#选这个!!测试
                      ml
                      sql
                      streaming
                      websearch

     

    测试算法包:
      /root/apps/HiBench-master/bin/workloads/micro/dfsioe# hdfsio测试
      /root/apps/HiBench-master/bin/workloads/micro/sleep
      /root/apps/HiBench-master/bin/workloads/micro/sort
      /root/apps/HiBench-master/bin/workloads/micro/wordcount
      
       cd /root/apps/HiBench-master/bin/workloads/micro/terasort#排序
       准备数据启动:
       /root/apps/HiBench-master/bin/workloads/micro/terasort/prepare/prepare.sh
       启动mr任务:
       /root/apps/HiBench-master/bin/workloads/micro/terasort/hadoop/run.sh
       启动spark任务:
       /root/apps/HiBench-master/bin/workloads/micro/terasort/spark/run.sh

     

    测试报告:

     /root/apps/HiBench-master/report
                   drwxr-xr-x 4 root root   44 Dec 14 03:58 bayes
                    -rw-r--r-- 1 root root 6651 Dec 19 01:39 hibench.report
                    drwxr-xr-x 3 root root   28 Dec 13 23:56 sort
                    drwxr-xr-x 4 root root   44 Dec 13 03:45 terasort
                    drwxr-xr-x 5 root root   61 Dec 12 04:11 wordcount

    展开全文
  • 介绍市面上的常见压测工具(ab、locust、Jmeter、go实现的压测工具、云压测),对比这些压测工具,教大家如何选择一款适合自己的压测工具,本文还有两个压测实战项目: 单台机器对HTTP短连接 QPS 1W+ 的压测实战 单台...

    本文介绍压测是什么,解释压测的专属名词,教大家如何压测。介绍市面上的常见压测工具(ab、locust、Jmeter、go实现的压测工具、云压测),对比这些压测工具,教大家如何选择一款适合自己的压测工具,本文还有两个压测实战项目:

    • 单台机器对HTTP短连接 QPS 1W+ 的压测实战
    • 单台机器100W长连接的压测实战

    目录

    • 1、项目说明
      • 1.1 go-stress-testing
      • 1.2 项目体验
    • 2、压测
      • 2.1 压测是什么
      • 2.2 为什么要压测
      • 2.3 压测名词解释
        • 2.3.1 压测类型解释
        • 2.3.2 压测名词解释
        • 2.3.3 机器性能指标解释
        • 2.3.4 访问指标解释
      • 3.4 如何计算压测指标
    • 3、常见的压测工具
      • 3.1 ab
      • 3.2 locust
      • 3.3 Jmeter
      • 3.4 云压测
        • 3.4.1 云压测介绍
        • 3.4.2 阿里云 性能测试 PTS
        • 3.4.3 腾讯云 压测大师 LM
    • 4、go-stress-testing go语言实现的压测工具
      • 4.1 介绍
      • 4.2 用法
      • 4.3 实现
      • 4.4 go-stress-testing 对 Golang web 压测
    • 5、压测工具的比较
      • 5.1 比较
      • 5.2 如何选择压测工具
    • 6、单台机器100w连接压测实战
      • 6.1 说明
      • 6.2 内核优化
      • 6.3 客户端配置
      • 6.4 准备
      • 6.5 压测数据
    • 7、总结
    • 8、参考文献

    1、项目说明

    1.1 go-stress-testing

    go 实现的压测工具,每个用户用一个协程的方式模拟,最大限度的利用CPU资源

    1.2 项目体验

    • 可以在 mac/linux/windows 不同平台下执行的命令

    参数说明:

    -c 表示并发数

    -n 每个并发执行请求的次数,总请求的次数 = 并发数 * 每个并发执行请求的次数

    -u 需要压测的地址

    
    # clone 项目
    git clone https://github.com/link1st/go-stress-testing.git
    
    # 进入项目目录
    cd go-stress-testing
    
    # 运行 
    go run main.go -c 1 -n 100 -u https://www.baidu.com/
    
    
    
    • 压测结果展示

    执行以后,终端每秒钟都会输出一次结果,压测完成以后输出执行的压测结果

    压测结果展示:

    
    ─────┬───────┬───────┬───────┬────────┬────────┬────────┬────────┬────────
     耗时│ 并发数 │ 成功数│ 失败数 │   qps  │最长耗时 │最短耗时│平均耗时 │ 错误码
    ─────┼───────┼───────┼───────┼────────┼────────┼────────┼────────┼────────
       1s│      1│      8│      0│    8.09│  133.16│  110.98│  123.56│200:8
       2s│      1│     15│      0│    8.02│  138.74│  110.98│  124.61│200:15
       3s│      1│     23│      0│    7.80│  220.43│  110.98│  128.18│200:23
       4s│      1│     31│      0│    7.83│  220.43│  110.23│  127.67│200:31
       5s│      1│     39│      0│    7.81│  220.43│  110.23│  128.03│200:39
       6s│      1│     46│      0│    7.72│  220.43│  110.23│  129.59│200:46
       7s│      1│     54│      0│    7.79│  220.43│  110.23│  128.42│200:54
       8s│      1│     62│      0│    7.81│  220.43│  110.23│  128.09│200:62
       9s│      1│     70│      0│    7.79│  220.43│  110.23│  128.33│200:70
      10s│      1│     78│      0│    7.82│  220.43│  106.47│  127.85│200:78
      11s│      1│     84│      0│    7.64│  371.02│  106.47│  130.96│200:84
      12s│      1│     91│      0│    7.63│  371.02│  106.47│  131.02│200:91
      13s│      1│     99│      0│    7.66│  371.02│  106.47│  130.54│200:99
      13s│      1│    100│      0│    7.66│  371.02│  106.47│  130.52│200:100
    
    
    *************************  结果 stat  ****************************
    处理协程数量: 1
    请求总数: 100 总请求时间: 13.055 秒 successNum: 100 failureNum: 0
    *************************  结果 end   ****************************
    
    

    参数解释:

    耗时: 程序运行耗时。程序每秒钟输出一次压测结果

    并发数: 并发数,启动的协程数

    成功数: 压测中,请求成功的数量

    失败数: 压测中,请求失败的数量

    qps: 当前压测的QPS(每秒钟处理请求数量)

    最长耗时: 压测中,单个请求最长的响应时长

    最短耗时: 压测中,单个请求最短的响应时长

    平均耗时: 压测中,单个请求平均的响应时长

    错误码: 压测中,接口返回的 code码:返回次数的集合

    2、压测

    2.1 压测是什么

    压测,即压力测试,是确立系统稳定性的一种测试方法,通常在系统正常运作范围之外进行,以考察其功能极限和隐患。

    主要检测服务器的承受能力,包括用户承受能力(多少用户同时玩基本不影响质量)、流量承受等。

    2.2 为什么要压测

    • 压测的目的就是通过压测(模拟真实用户的行为),测算出机器的性能(单台机器的QPS),从而推算出系统在承受指定用户数(100W)时,需要多少机器能支撑得住
    • 压测是在上线前为了应对未来可能达到的用户数量的一次预估(提前演练),压测以后通过优化程序的性能或准备充足的机器,来保证用户的体验。

    2.3 压测名词解释

    2.3.1 压测类型解释

    压测类型 解释
    压力测试(Stress Testing) 也称之为强度测试,测试一个系统的最大抗压能力,在强负载(大数据、高并发)的情况下,测试系统所能承受的最大压力,预估系统的瓶颈
    并发测试(Concurrency Testing) 通过模拟很多用户同一时刻访问系统或对系统某一个功能进行操作,来测试系统的性能,从中发现问题(并发读写、线程控制、资源争抢)
    耐久性测试(Configuration Testing) 通过对系统在大负荷的条件下长时间运行,测试系统、机器的长时间运行下的状况,从中发现问题(内存泄漏、数据库连接池不释放、资源不回收)

    2.3.2 压测名词解释

    压测名词 解释
    并发(Concurrency) 指一个处理器同时处理多个任务的能力(逻辑上处理的能力)
    并行(Parallel) 多个处理器或者是多核的处理器同时处理多个不同的任务(物理上同时执行)
    QPS(每秒钟查询数量 Query Per Second) 服务器每秒钟处理请求数量 (req/sec 请求数/秒 一段时间内总请求数/请求时间)
    事务(Transactions) 是用户一次或者是几次请求的集合
    TPS(每秒钟处理事务数量 Transaction Per Second) 服务器每秒钟处理事务数量(一个事务可能包括多个请求)
    请求成功数(Request Success Number) 在一次压测中,请求成功的数量
    请求失败数(Request Failures Number) 在一次压测中,请求失败的数量
    错误率(Error Rate) 在压测中,请求成功的数量与请求失败数量的比率
    最大响应时间(Max Response Time) 在一次事务中,从发出请求或指令系统做出的反映(响应)的最大时间
    最少响应时间(Mininum Response Time) 在一次事务中,从发出请求或指令系统做出的反映(响应)的最少时间
    平均响应时间(Average Response Time) 在一次事务中,从发出请求或指令系统做出的反映(响应)的平均时间

    2.3.3 机器性能指标解释

    机器性能 解释
    CUP利用率(CPU Usage) CUP 利用率分用户态、系统态和空闲态,CPU利用率是指:CPU执行非系统空闲进程的时间与CPU总执行时间的比率
    内存使用率(Memory usage) 内存使用率指的是此进程所开销的内存。
    IO(Disk input/ output) 磁盘的读写包速率
    网卡负载(Network Load) 网卡的进出带宽,包量

    2.3.4 访问指标解释

    访问 解释
    PV(页面浏览量 Page View) 用户每打开1个网站页面,记录1个PV。用户多次打开同一页面,PV值累计多次
    UV(网站独立访客 Unique Visitor) 通过互联网访问、流量网站的自然人。1天内相同访客多次访问网站,只计算为1个独立访客

    2.4 如何计算压测指标

    • 压测我们需要有目的性的压测,这次压测我们需要达到什么目标(如:单台机器的性能为100QPS?网站能同时满足100W人同时在线)

    • 可以通过以下计算方法来进行计算:

    • 压测原则:每天80%的访问量集中在20%的时间里,这20%的时间就叫做峰值

    • 公式: ( 总PV数80% ) / ( 每天的秒数20% ) = 峰值时间每秒钟请求数(QPS)

    • 机器: 峰值时间每秒钟请求数(QPS) / 单台机器的QPS = 需要的机器的数量

    • 假设:网站每天的用户数(100W),每天的用户的访问量约为3000W PV,这台机器的需要多少QPS?

    ( 30000000*0.8 ) / (86400 * 0.2) ≈ 1389 (QPS)

    • 假设:单台机器的的QPS是69,需要需要多少台机器来支撑?

    1389 / 69 ≈ 20

    3、常见的压测工具

    3.1 ab

    • 简介

    ApacheBench 是 Apache服务器自带的一个web压力测试工具,简称ab。ab又是一个命令行工具,对发起负载的本机要求很低,根据ab命令可以创建很多的并发访问线程,模拟多个访问者同时对某一URL地址进行访问,因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单,上手学习较快,可以提供需要的基本性能指标,但是没有图形化结果,不能监控。

    ab属于一个轻量级的压测工具,结果不会特别准确,可以用作参考。

    • 安装
    # 在linux环境安装
    sudo yum -y install httpd
    
    • 用法
    Usage: ab [options] [http[s]://]hostname[:port]/path
    用法:ab [选项] 地址
    
    选项:
    Options are:
        -n requests      #执行的请求数,即一共发起多少请求。
        -c concurrency   #请求并发数。
        -s timeout       #指定每个请求的超时时间,默认是30秒。
        -k               #启用HTTP KeepAlive功能,即在一个HTTP会话中执行多个请求。默认时,不启用KeepAlive功能。
    
    • 压测命令
    # 使用ab压测工具,对百度的链接 请求100次,并发数1
    ab -n 100 -c 1 https://www.baidu.com/
    

    压测结果

    ~ >ab -n 100 -c 1 https://www.baidu.com/
    This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking www.baidu.com (be patient).....done
    
    
    Server Software:        BWS/1.1
    Server Hostname:        www.baidu.com
    Server Port:            443
    SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
    
    Document Path:          /
    Document Length:        227 bytes
    
    Concurrency Level:      1
    Time taken for tests:   9.430 seconds
    Complete requests:      100
    Failed requests:        0
    Write errors:           0
    Total transferred:      89300 bytes
    HTML transferred:       22700 bytes
    Requests per second:    10.60 [#/sec] (mean)
    Time per request:       94.301 [ms] (mean)
    Time per request:       94.301 [ms] (mean, across all concurrent requests)
    Transfer rate:          9.25 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:       54   70  16.5     69     180
    Processing:    18   24  12.0     23     140
    Waiting:       18   24  12.0     23     139
    Total:         72   94  20.5     93     203
    
    Percentage of the requests served within a certain time (ms)
      50%     93
      66%     99
      75%    101
      80%    102
      90%    108
      95%    122
      98%    196
      99%    203
     100%    203 (longest request)
    
    • 主要关注的测试指标

    • Concurrency Level 并发请求数

    • Time taken for tests 整个测试时间

    • Complete requests 完成请求个数

    • Failed requests 失败个数

    • Requests per second 吞吐量,指的是某个并发用户下单位时间内处理的请求数。等效于QPS,其实可以看作同一个统计方式,只是叫法不同而已。

    • Time per request 用户平均请求等待时间

    • Time per request 服务器处理时间

    3.2 Locust

    • 简介

    是非常简单易用、分布式、python开发的压力测试工具。有图形化界面,支持将压测数据导出。

    • 安装
    # pip3 安装locust
    pip3  install locust
    # 查看是否安装成功
    locust -h
    # 运行 Locust 分布在多个进程/机器库
    pip3 install pyzmq
    # webSocket 压测库
    pip3 install websocket-client
    
    • 用法

    编写压测脚本 test.py

    from locust import HttpLocust, TaskSet, task
    
    # 定义用户行为
    class UserBehavior(TaskSet):
    
        @task
        def baidu_index(self):
            self.client.get("/")
    
    
    class WebsiteUser(HttpLocust):
        task_set = UserBehavior # 指向一个定义的用户行为类
        min_wait = 3000 # 执行事务之间用户等待时间的下界(单位:毫秒)
        max_wait = 6000 # 执行事务之间用户等待时间的上界(单位:毫秒)
    
    • 启动压测
    locust -f  test.py --host=https://www.baidu.com
    

    访问 http://localhost:8089 进入压测首页

    Number of users to simulate 模拟用户数

    Hatch rate (users spawned/second) 每秒钟增加用户数

    点击 “Start swarming” 进入压测页面

    locust 首页

    压测界面右上角有:被压测的地址、当前状态、RPS、失败率、开始或重启按钮

    性能测试参数

    • Type 请求的类型,例如GET/POST

    • Name 请求的路径

    • Request 当前请求的数量

    • Fails 当前请求失败的数量

    • Median 中间值,单位毫秒,请求响应时间的中间值

    • Average 平均值,单位毫秒,请求的平均响应时间

    • Min 请求的最小服务器响应时间,单位毫秒

    • Max 请求的最大服务器响应时间,单位毫秒

    • Average size 单个请求的大小,单位字节

    • Current RPS 代表吞吐量(Requests Per Second的缩写),指的是某个并发用户数下单位时间内处理的请求数。等效于QPS,其实可以看作同一个统计方式,只是叫法不同而已。

    locust 压测页面

    3.3 Jmeter

    • 简介

    Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。
    JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。

    • 安装

    访问 https://jmeter-plugins.org/install/Install/ 下载解压以后即可使用

    • 用法

    JMeter的功能过于强大,这里暂时不介绍用法,可以查询相关文档使用(参考文献中有推荐的教程文档)

    3.4 云压测

    3.4.1 云压测介绍

    顾名思义就是将压测脚本部署在云端,通过云端对对我们的应用进行全方位压测,只需要配置压测的参数,无需准备实体机,云端自动给我们分配需要压测的云主机,对被压测目标进行压测。

    云压测的优势:

    1. 轻易的实现分布式部署
    2. 能够模拟海量用户的访问
    3. 流量可以从全国各地发起,更加真实的反映用户的体验
    4. 全方位的监控压测指标
    5. 文档比较完善

    当然了云压测是一款商业产品,在使用的时候自然还是需要收费的,而且价格还是比较昂贵的~

    3.4.2 阿里云 性能测试 PTS

    PTS(Performance Testing Service)是面向所有技术背景人员的云化测试工具。有别于传统工具的繁复,PTS以互联网化的交互,提供性能测试、API调试和监测等多种能力。自研和适配开源的功能都可以轻松模拟任意体量的用户访问业务的场景,任务随时发起,免去繁琐的搭建和维护成本。更是紧密结合监控、流控等兄弟产品提供一站式高可用能力,高效检验和管理业务性能。

    阿里云同样还是支持渗透测试,通过模拟黑客对业务系统进行全面深入的安全测试。

    3.4.3 腾讯云 压测大师 LM

    通过创建虚拟机器人模拟多用户的并发场景,提供一整套完整的服务器压测解决方案

    4、go-stress-testing go语言实现的压测工具

    4.1 介绍

    • go-stress-testing 是go语言实现的简单压测工具,源码开源、支持二次开发,可以压测http、webSocket请求,使用协程模拟单个用户,可以更高效的利用CPU资源。

    • 项目地址 https://github.com/link1st/go-stress-testing

    4.2 用法

    • 支持参数:
    Usage of ./go_stress_testing_mac:
      -c uint
            并发数 (default 1)
      -d string
            调试模式 (default "false")
      -n uint
            请求总数 (default 1)
      -p string
            curl文件路径
      -u string
            请求地址
      -v string
            验证方法 http 支持:statusCode、json webSocket支持:json (default "statusCode")
    
    • -n 是单个用户请求的次数,请求总次数 = -c* -n, 这里考虑的是模拟用户行为,所以这个是每个用户请求的次数

    • 使用示例:

    # 查看用法
    go run main.go
    
    # 使用请求百度页面
    go run main.go -c 1 -n 100 -u https://www.baidu.com/
    
    # 使用debug模式请求百度页面
    go run main.go -c 1 -n 1 -d true -u https://www.baidu.com/
    
    # 使用 curl文件(文件在curl目录下) 的方式请求
    go run main.go -c 1 -n 1 -p curl/baidu.curl.txt
    
    # 压测webSocket连接
    go run main.go -c 10 -n 10 -u ws://127.0.0.1:8089/acc
    
    • 使用 curl文件进行压测

    curl是Linux在命令行下的工作的文件传输工具,是一款很强大的http命令行工具。

    使用curl文件可以压测使用非GET的请求,支持设置http请求的 method、cookies、header、body等参数

    chrome 浏览器生成 curl文件,打开开发者模式(快捷键F12),如图所示,生成 curl 在终端执行命令
    copy cURL

    生成内容粘贴到项目目录下的curl/baidu.curl.txt文件中,执行下面命令就可以从curl.txt文件中读取需要压测的内容进行压测了

    # 使用 curl文件(文件在curl目录下) 的方式请求
    go run main.go -c 1 -n 1 -p curl/baidu.curl.txt
    

    4.3 实现

    • 具体需求可以查看项目源码

    • 项目目录结构

    |____main.go                      // main函数,获取命令行参数
    |____server                       // 处理程序目录
    | |____dispose.go                 // 压测启动,注册验证器、启动统计函数、启动协程进行压测
    | |____statistics                 // 统计目录
    | | |____statistics.go            // 接收压测统计结果并处理
    | |____golink                     // 建立连接目录
    | | |____http_link.go             // http建立连接
    | | |____websocket_link.go        // webSocket建立连接
    | |____client                     // 请求数据客户端目录
    | | |____http_client.go           // http客户端
    | | |____websocket_client.go      // webSocket客户端
    | |____verify                     // 对返回数据校验目录
    | | |____http_verify.go           // http返回数据校验
    | | |____websokcet_verify.go      // webSocket返回数据校验
    |____heper                        // 通用函数目录
    | |____heper.go                   // 通用函数
    |____model                        // 模型目录
    | |____request_model.go           // 请求数据模型
    | |____curl_model.go              // curl文件解析
    |____vendor                       // 项目依赖目录
    

    4.4 go-stress-testing 对 Golang web 压测

    这里使用go-stress-testing对go server进行压测(部署在同一台机器上),并统计压测结果

    • 申请的服务器配置

    CPU: 4核 (Intel Xeon(Cascade Lake) Platinum 8269 2.5 GHz/3.2 GHz)

    内存: 16G
    硬盘: 20G SSD
    系统: CentOS 7.6

    go version: go1.12.9 linux/amd64

    go-stress-testing01

    • go server
    package main
    
    import (
        "log"
        "net/http"
    )
    
    const (
        httpPort = "8088"
    )
    
    func main() {
    
        runtime.GOMAXPROCS(runtime.NumCPU() - 1)
    
        hello := func(w http.ResponseWriter, req *http.Request) {
            data := "Hello, World!"
    
            w.Header().Add("Server", "golang")
            w.Write([]byte(data))
    
            return
        }
    
        http.HandleFunc("/", hello)
        err := http.ListenAndServe(":"+httpPort, nil)
    
        if err != nil {
            log.Fatal("ListenAndServe: ", err)
        }
    }
    
    
    • go_stress_testing 压测命令
    ./go_stress_testing_linux -c 100 -n 10000 -u http://127.0.0.1:8088/
    
    • 压测结果
    并发数 go_stress_testing QPS
    1 6394.86
    4 16909.36
    10 18456.81
    20 19490.50
    30 19947.47
    50 19922.56
    80 19155.33
    100 18336.46
    200 16813.86

    从压测的结果上看:效果还不错,压测QPS有接近2W

    5、压测工具的比较

    5.1 比较

    - ab locust Jmeter go-stress-testing 云压测
    实现语言 C Python Java Golang -
    UI界面
    优势 使用简单,上手简单 支持分布式、压测数据支持导出 插件丰富,支持生成HTML报告 项目开源,使用简单,没有依赖,支持webSocket压测 更加真实的模拟用户,支持更高的压测力度

    5.2 如何选择压测工具

    这个世界上没有最好的,只有最适合的,工具千千万,选择一款适合你的才是最重要的

    在实际使用中有各种场景,选择工具的时候就需要考虑这些:

    • 明确你的目的,需要做什么压测、压测的目标是什么?

    • 使用的工具你是否熟悉,你愿意花多大的成本了解它?

    • 你是为了测试还是想了解其中的原理?

    • 工具是否能支持你需要压测的场景

    6、单台机器100w连接压测实战

    6.1 说明

    之前写了一篇文章,基于websocket单台机器支持百万连接分布式聊天(IM)系统(不了解这个项目可以查看上一篇或搜索一下文章),这里我们要实现单台机器支持100W连接的压测

    目标:

    • 单台机器能保持100W个长连接
    • 机器的CPU、内存、网络、I/O 状态都正常

    说明:

    gowebsocket 分布式聊天(IM)系统:

    • 之前用户连接以后有个全员广播,这里需要将用户连接、退出等事件关闭
    • 服务器准备:

    由于自己手上没有自己的服务器,所以需要临时购买的云服务器

    压测服务器:

    16台(稍后解释为什么需要16台机器)

    CPU: 2核
    内存: 8G
    硬盘: 20G
    系统: CentOS 7.6

    webSocket压测服务器

    被压测服务:

    1台

    CPU: 4核
    内存: 32G
    硬盘: 20G SSD
    系统: CentOS 7.6

    webSocket被压测服务器

    6.2 内核优化

    • 修改程序最大打开文件数

    被压测服务器需要保持100W长连接,客户和服务器端是通过socket通讯的,每个连接需要建立一个socket,程序需要保持100W长连接就需要单个程序能打开100W个文件句柄

    # 查看系统默认的值
    ulimit -n
    # 设置最大打开文件数
    ulimit -n 1040000
    

    这里设置的要超过100W,程序除了有100W连接还有其它资源连接(数据库、资源等连接),这里设置为 104W

    centOS 7.6 上述设置不生效,需要手动修改配置文件

    vim /etc/security/limits.conf

    这里需要把硬限制和软限制、root用户和所有用户都设置为 1040000

    core 是限制内核文件的大小,这里设置为 unlimited

    # 添加一下参数
    root soft nofile 1040000
    root hard nofile 1040000
    
    root soft nofile 1040000
    root hard nproc 1040000
    
    root soft core unlimited
    root hard core unlimited
    
    * soft nofile 1040000
    * hard nofile 1040000
    
    * soft nofile 1040000
    * hard nproc 1040000
    
    * soft core unlimited
    * hard core unlimited
    

    注意:

    /proc/sys/fs/file-max 表示系统级别的能够打开的文件句柄的数量,不能小于limits中设置的值

    如果file-max的值小于limits设置的值会导致系统重启以后无法登录

    # file-max 设置的值参考
    cat /proc/sys/fs/file-max
    12553500
    

    修改以后重启服务器,ulimit -n 查看配置是否生效

    6.3 客户端配置

    由于linux端口的范围是 0~65535(2^16-1)这个和操作系统无关,不管linux是32位的还是64位的

    这个数字是由于tcp协议决定的,tcp协议头部表示端口只有16位,所以最大值只有65535(如果每台机器多几个虚拟ip就能突破这个限制)

    1024以下是系统保留端口,所以能使用的1024到65535

    如果需要100W长连接,每台机器有 65535-1024 个端口, 100W / (65535-1024) ≈ 15.5,所以这里需要16台服务器

    • vim /etc/sysctl.conf 在文件末尾添加
    net.ipv4.ip_local_port_range = 1024 65000
    net.ipv4.tcp_mem = 786432 2097152 3145728
    net.ipv4.tcp_rmem = 4096 4096 16777216
    net.ipv4.tcp_wmem = 4096 4096 16777216
    

    配置解释:

    • ip_local_port_range 表示TCP/UDP协议允许使用的本地端口号 范围:1024~65000
    • tcp_mem 确定TCP栈应该如何反映内存使用,每个值的单位都是内存页(通常是4KB)。第一个值是内存使用的下限;第二个值是内存压力模式开始对缓冲区使用应用压力的上限;第三个值是内存使用的上限。在这个层次上可以将报文丢弃,从而减少对内存的使用。对于较大的BDP可以增大这些值(注意,其单位是内存页而不是字节)
    • tcp_rmem 为自动调优定义socket使用的内存。第一个值是为socket接收缓冲区分配的最少字节数;第二个值是默认值(该值会被rmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值;第三个值是接收缓冲区空间的最大字节数(该值会被rmem_max覆盖)。
    • tcp_wmem 为自动调优定义socket使用的内存。第一个值是为socket发送缓冲区分配的最少字节数;第二个值是默认值(该值会被wmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值;第三个值是发送缓冲区空间的最大字节数(该值会被wmem_max覆盖)。

    6.4 准备

    1. 在被压测服务器上启动Server服务(gowebsocket)

    2. 查看被压测服务器的内网端口

    3. 登录上16台压测服务器,这里我提前把需要优化的系统做成了镜像,申请机器的时候就可以直接使用这个镜像(参数已经调好)

    压测服务器16台准备

    1. 启动压测
     ./go_stress_testing_linux -c 62500 -n 1  -u ws://192.168.0.74:443/acc
    

    62500*16 = 100W正好可以达到我们的要求

    建立连接以后,-n 1发送一个ping的消息给服务器,收到响应以后保持连接不中断

    1. 通过 gowebsocket服务器的http接口,实时查询连接数和项目启动的协程数

    2. 压测过程中查看系统状态

    # linux 命令
    ps      # 查看进程内存、cup使用情况
    iostat  # 查看系统IO情况
    nload   # 查看网络流量情况
    /proc/pid/status # 查看进程状态
    

    6.5 压测数据

    • 压测以后,查看连接数到100W,然后保持10分钟观察系统是否正常

    • 观察以后,系统运行正常、CPU、内存、I/O 都正常,打开页面都正常

    • 压测完成以后的数据

    查看goWebSocket连接数统计,可以看到 clientsLen连接数为100W,goroutine数量2000008个,每个连接两个goroutine加上项目启动默认的8个。这里可以看到连接数满足了100W

    查看goWebSocket连接数统计

    从压测服务上查看连接数是否达到了要求,压测完成的统计数据并发数为62500,是每个客户端连接的数量,总连接数: 62500*16=100W

    压测服务16台 压测完成

    • 记录内存使用情况,分别记录了1W到100W连接数内存使用情况
    连接数 内存
    10000 281M
    100000 2.7g
    200000 5.4g
    500000 13.1g
    1000000 25.8g

    100W连接时的查看内存详细数据:

    cat /proc/pid/status
    VmSize: 27133804 kB
    

    27133804/1000000≈27.1 100W连接,占用了25.8g的内存,粗略计算了一下,一个连接占用了27.1Kb的内存,由于goWebSocket项目每个用户连接起了两个协程处理用户的读写事件,所以内存占用稍微多一点

    如果需要如何减少内存使用可以参考 @Roy11568780 大佬给的解决方案

    传统的golang中是采用的一个goroutine循环read的方法对应每一个socket。实际百万链路场景中这是巨大的资源浪费,优化的原理也不是什么新东西,golang中一样也可以使用epoll的,把fd拿到epoll中,检测到事件然后在协程池里面去读就行了,看情况读写分别10-20的协程goroutine池应该就足够了

    至此,压测已经全部完成,单台机器支持100W连接已经满足~

    7、总结

    到这里压测总算完成,本次压测花费16元巨款。

    单台机器支持100W连接是实测是满足的,但是实际业务比较复杂,还是需要持续优化~

    本文通过介绍什么是压测,在什么情况下需要压测,通过单台机器100W长连接的压测实战了解Linux内核的参数的调优。如果觉得现有的压测工具不适用,可以自己实现或者是改造成属于自己的自己的工具。

    8、参考文献

    性能测试工具

    性能测试常见名词解释

    性能测试名词解释

    PV、TPS、QPS是怎么计算出来的?

    超实用压力测试工具-ab工具

    Locust 介绍

    Jmeter性能测试 入门

    基于websocket单台机器支持百万连接分布式聊天(IM)系统

    https://github.com/link1st/go-stress-testing

    github 搜:link1st 查看项目 go-stress-testing

    展开全文
  • Mysql 压测工具 sysbench

    2020-06-06 09:45:13
    如果先服务上线前,我们想了解mysql的性能,可以使用一款mysql压测工具sysbench,是一款非常方便的工具,它可以帮你在数据库中构建大量的大数据,自动的创建表,接着模拟很多的线程去并发访问你的数据库,可以执行...

    介绍

    如果先服务上线前,我们想了解mysql的性能,可以使用一款mysql压测工具sysbench,是一款非常方便的工具,它可以帮你在数据库中构建大量的大数据,自动的创建表,接着模拟很多的线程去并发访问你的数据库,可以执行各种各样用于读写数据库的sql语句,以及提交复杂的事物

    我们先去安装sysbench

    安装sysbench

    在linux服务器,使用root账户安装

    curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh
    
    yum -y install sysbench
    

    执行上述两条命令,就可以安装完成了

    数据准备阶段

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_read_write --db-ps-mode=disable prepare
    
    

    数据安装完成以后,我们使用上述命令进行数据准备,下面介绍下各个命令的参数

    1.–db-driver=mysql 使用mysql数据库驱动
    2.–time=300 连续访问300s
    3.-threads=10 10个线程模拟并发访问
    4.-report-interval=1 每隔1s输出压测情况
    5.–mysql-host=192.168.1.106 mysqlip地址
    6.–mysql-port=3306 mysql端口号
    7.–mysql-user=root mysql用户名
    8.–mysql-password=root mysql密码
    9.-mysql-db=eshop mysql数据库
    10.–tables=20 表的数量
    11.–table_size=1000000 每张表的数据量
    12.oltp_read_write 读写模式,这里有多种模式,后面会继续介绍
    13 -db-ps-mode=disable 禁用ps模式
    14prepare 数据准备阶段,这里一般会有3种模式 run 运行, cleanup 清楚准备好的数据

    压测阶段

    这里会有多种的压测模式

    读写压测 oltp_read_write run

    
    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_read_write --db-ps-mode=disable run
    

    只读压测 oltp_read_only

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_read_only --db-ps-mode=disable run
    
    

    删除压测 oltp_delete

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_delete --db-ps-mode=disable run
    
    

    更新字段索引 oltp_update_idnex

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_update_idnex --db-ps-mode=disable run
    
    

    更新非字段索引功能 oltp_update_non_idnex

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_update_non_idnex --db-ps-mode=disable run
    
    

    插入功能 oltp_insert

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_insert --db-ps-mode=disable run
    
    

    写入性能 oltp_write_only

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_write_only --db-ps-mode=disable run
    
    

    清除数据

    sysbench --db-driver=mysql --time=300 --threads=10 --report-interval=1 --mysql-host=192.168.1.106 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=eshop --tables=20 --table_size=1000000 oltp_read_write --db-ps-mode=disable cleanup
    
    

    压测报告分析

    [ 300s ] thds: 10 tps: 127.75 qps: 2044.99 (r/w/o: 1790.49/0.00/254.50) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00
    SQL statistics:
        queries performed:
            read:                            461090
            write:                           0
            other:                           65870
            total:                           526960
        transactions:                        32935  (109.76 per sec.)
        queries:                             526960 (1756.23 per sec.)
        ignored errors:                      0      (0.00 per sec.)
        reconnects:                          0      (0.00 per sec.)
    
    General statistics:
        total time:                          300.0485s
        total number of events:              32935
    
    Latency (ms):
             min:                                   38.32
             avg:                                   91.08
             max:                                  492.23
             95th percentile:                      130.13
             sum:                              2999714.63
    
    Threads fairness:
        events (avg/stddev):           3293.5000/26.39
    

    我们分别解释输出报告的含义

    [ 300s ] thds: 10 tps: 127.75 qps: 2044.99 (r/w/o: 1790.49/0.00/254.50) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00
    
    

    这个就是我们之前设定的 每秒1次的输出报告,由于我是在本地虚拟机压测的所以性能特别低

    1. thds: 10 10个线程
    2. tps: 127.75 每s执行了127.75 个事务
    3. qps: 2044.99 每s 执行2044.99个请求
    4. (r/w/o: 1790.49/0.00/254.50) 在2044.99 个请求中有1790.49个请求时读请求 0.00个写请求(我这里压测的是只读),有254.5 是其它请求
    5. lat (ms,95%): 108.68 有95%的请求延迟都在108ms以下
    6. err/s: 0.00 reconn/s: 0.00 meis有0个请求失败,有0个请求进行网络失联

    总的分析报告:

    
    SQL statistics:
        queries performed:
            read:                            461090  //在300s请求内发生了461090次读请求
            write:                           0     //在300s请求内发生了0次写请求
            other:                           65870   //在300s请求内发生了65870次其它请求
            total:                           526960  //在300s请求内发生了526960  次请求
        transactions:                        32935  (109.76 per sec.)   //300s 内一共执行3万多事务,每秒109个事务 TPS
        queries:                             526960 (1756.23 per sec.)//300s 内一共执行50万请求,每秒1756个请求 TPS
        ignored errors:                      0      (0.00 per sec.) 
        reconnects:                          0      (0.00 per sec.)
    
    General statistics:
        total time:                          300.0485s  // 进行了300s压测
        total number of events:              32935  //事务有3万多个
    
    Latency (ms):
             min:                                   38.32   //请求中延迟最小的是38.32ms
             avg:                                   91.08 //请求中平均延迟91.08ms
             max:                                  492.23 // 请求中最大延迟 492ms
             95th percentile:                      130.13  //95%请求延迟在130ms
             sum:                              2999714.63
    
    Threads fairness:
        events (avg/stddev):           3293.5000/26.39 
    

    性能监控

    但在压测的过程中我们还需要密切关注服务器cpu 内存,磁盘,网络的性能,下面我们介绍下关注它们的命令

    cpu

    在Linux服务器下,关注CPU的性能主要使用top

    内存

    free-m top

    磁盘IO情况

    观察磁盘吞吐量
    dstat -d 查看每s读写的数量

    dstat -r 查看随机读写的数量

    网卡情况

    dstat - -n

    展开全文
  • 10大主流压力测试工具推荐

    万次阅读 2018-03-27 10:28:02
    在移动应用和Web服务正式发布之前,除了进行必要的功能测试和安全测试,为了保证互联网产品的服务...那么互联网产品为什么要进行压力/负载/性能测试,又有哪些工具帮我们实现呢,本文将为您细说端详。 压力/负载/性

    在移动应用和Web服务正式发布之前,除了进行必要的功能测试和安全测试,为了保证互联网产品的服务交付质量,往往还需要做压力/负载/性能测试。然而很多传统企业在试水互联网+的过程中,往往由于资源或产品迭代速度等原因忽视了这一块工作,导致新产品上线之后频繁出现卡顿等严重影响用户体验的问题。那么互联网产品为什么要进行压力/负载/性能测试,又有哪些工具帮我们实现呢,本文将为您细说端详。

    压力/负载/性能测试之异同

    在产品研发过程中,常常会混淆压力/负载/性能测试这三者之间的区别,这三种测试到底有什么不同呢?

    压力测试(StressTesting),也称为强度测试,通过模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件,来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大的服务级别。通俗地讲,压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

    负载测试(Load Testing)通常被定义为给被测系统加上它所能操作的最大任务数的过程,负载测试有时也会被称为“容量测试”或者“耐久性测试/持久性测试”,其目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。对于WEB应用来讲,负载则是并发用户或者HTTP连接的数量。负载测试通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。

    性能测试(PerformanceTesting)的目的不是去找系统Bugs,而是排除系统的性能瓶颈,并为回归测试建立一个基准。而性能测试的操作,实际上就是一个非常小心受控的测量分析过程:“运行负载试验->测度性能->调试系统”。在理想的情况下,被测应用在这个时候已经是足够稳定,所以这个过程得以顺利进行。性能测试还有另一个目标就是建立一组被测系统的基准数据。应用在网络上的性能测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

    虽然三种测试的目的截然不同,但其测试操作的环节都是基本一致的,因此一次测试过程中完全可以包含性能测试、负载测试、压力测试三个方面的内容,所使用的测试工具往往大同小异。

    10大主流压力/负载/性能测试工具推荐

    市面上流行的压力/负载/性能测试工具多是来自国外,同时由于开发的目的和侧重点不同,其功能也有很大差异,下面就为您简单介绍10款目前最常见的测试产品。

    1

    LoadRunner

    LoadRunner是一种预测系统行为和性能的负载测试工具,通过模拟实际用户的操作行为进行实时性能监测,来帮助测试人员更快的查找和发现问题。LoadRunner适用于各种体系架构,能支持广泛的协议和技术,为测试提供特殊的解决方案。企业通过LoadRunner能最大限度地缩短测试时间,优化性能并加速应用系统的发布周期。

    LoadRunner提供了3大主要功能模块:VirtualUser Generator(用于录制性能测试脚本),LoadRunner Controller(用于创建、运行和监控场景),LoadRunner Analysis(用于分析性能测试结果)既可以作为独立的工具完成各自的功能,又可以作为LoadRunner的一部分彼此衔接,与其他模块共同完成软件性能的整体测试。

    详见:《性能测试入门——LoadRunner使用初探》(http://www.admin5.com/article/20161114/695706.shtml)

    LoadRunner官网:https://saas.hpe.com/zh-cn/software/loadrunner

    2

    Apache JMeter

    JMeter作为一款广为流传的开源压测产品,最初被设计用于Web应用测试,如今JMeter可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP服务器等等,还能对服务器、网络或对象模拟巨大的负载,通过不同压力类别测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能测试和回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。

    JMeter的特点包括对HTTP、FTP服务器、数据库进行压力测试和性能测试;完全的可移植性;完全 Swing和轻量组件支持包;完全多线程;缓存和离线分析/回放测试结果;可链接的取样器;具有提供动态输入到测试的功能;支持脚本编程的取样器等。在设计阶段,JMeter能够充当HTTP PROXY(代理)来记录浏览器的HTTP请求,也可以记录Apache等WebServer的log文件来重现HTTP流量,并在测试运行时以此为依据设置重复次数和并发度(线程数)来进行压测。

    参考文章:《云智慧压测实战分享之JMeter工具使用初探》(https://segmentfault.com/a/1190000007922515)

    官网链接:http://jmeter.apache.org/

    3

    NeoLoad

    NeoLoad是Neotys出品的一种负载和性能测试工具,可真实地模拟用户活动并监视基础架构运行状态,从而消除所有Web和移动应用程序中的瓶颈。NeoLoad通过使用无脚本GUI和一系列自动化功能,可让测试设计速度提高5-10倍,并将维护的脚本维持在原始设计时间的10%,同时帮助用户使用持续集成系统自动进行测试。

    NeoLoad支持WebSocket、HTTP1/ 2、GWT、HTML5、AngularJS、Oracle Forms等技术协议,能够监控包括操作系统,应用服务器,Web服务器,数据库和网络设备在内的各种IT基础设施,同时可以通过Neotys云平台发起外部压力。

    官网链接:http://www.neotys.com/product/overview-neoload.html

    4

    WebLOAD

    WebLOAD是来自Radview公司的负载测试工具,它可被用以测试系统性能和弹性,也可被用于正确性验证(验证返回结果的正确性)。其测试脚本是用Javascript(和集成的COM/Java对象)编写的,并支持多种协议,如Web(包括AJAX在内的REST/HTTP)、SOAP/XML及其他可从脚本调用的协议如FTP、SMTP等,因而可从所有层面对应用程序进行测试。

    WebLOAD存在免费和专业两个版本,免费版本支持50个虚拟用户,专业版还提供更多的报告和协议供用户选择。WebLOAD通常用作QA团队的独立运行工具,在开发周期的验证阶段,被测系统(System Under Test,SUT)投入实用之前,在模拟环境中对被测系统进行测试。

    官网链接:http://www.radview.com/

    5

    Loadster

    Loadster是一款商用负载测试软件,用于测试高负载下网站、Web应用、Web服务的性能表现,支持Linux,Mac和Windows等运行环境。

    Loadster能够对Web应用/服务的Cookies、线程、头文件、动态表格等元素发起测试,获得Web在压力下的性能、弹性、稳定性和可扩展性等方面的表现。

    官网链接:http://www.loadsterperformance.com/

    6

    Load impact

    Load impact是一款服务于DevOps的性能测试工具,支持各种平台的网站、Web应用、移动应用和API测试。Loadimpact可以帮助用户了解应用的最高在线用户访问量,通过模拟测试不同在线人数下网站的响应时间,估算出服务器的最大负载。

    Load impact的使用非常简单,只需要输入网址进行测试,便可统计出加载网站的一些详细数据。包括整体加载和站内图片,javascript, CSS等代码载入。可以在右侧列表选择不同文件来同时对比最多三个对象的加载数据,并生成图表显示,方便网站设计者来分析。测试完成之后,网站还可以存储测试过的统计数据。

    官网链接:http://loadimpact.com/

    7

    CloudTest

    CloudTest 是一个集性能和功能测试于一体的综合压力测试云平台,专为现代网络和移动应用测试而设计开发,CloudTest可以图形化实现判断、循环,整体减轻了测试开发的工作量,缩短了开发时间。CloudTest基于内存的分析引擎,可以实时收集和展示数据,所有数据在3秒内汇聚显示。

    CloudTest采用虚拟化技术,完美的配合公有/私有云计算技术,无需过多的硬件,带宽资源的投入,人力维护成本几乎为零,测试按需获得,远程接入,适合多团队协作。各种规模的模拟成本均远远优于传统工具,同时大大缩短了测试周期。

    官网链接:https://soasta.com/cloudtest

    8

    Loadstorm

    Loadstorm是一款针对Web应用的云端负载测试工具,通过模拟海量点击来测试Web应用在大负载下的性能表现。由于采用了云资源,所以Loadstorm的测试成本非常低,用户可以在云端选择创建自己的测试计划,测试标准和测试场景。

    Loadstorm最多可以生成多达50000个并发用户,通过数以千计的云服务器发起访问。使用Loadstorm不需要任何脚本知识,同时提供多样化的测试图表和报告模版,用于准确测量Web应用的各项性能指标,如错误率,平均响应时间和用户数量等。Loadstorm可以申请免费试用,但更多压力和功能需要开通高级帐户。

    官网链接:http://loadstorm.com/

    9

    阿里云PTS

    阿里云性能测试(Performance Testing)是一个SaaS性能测试平台,具有强大的分布式压测能力,可模拟海量用户真实的业务场景,让应用性能问题无所遁形。PTS平台特色包括提供压测机,无需安装软件;脚本场景监控简单化,省时、省力;分布式并发压测,施压能力无上限;快速大规模集群扩容、支持几十万用户及百万级TPS性能压测;80%以上用户基本不需要花费额外的成本。

    PTS分为两个版本,Lite版免费,企业版提供资源包月和按量付费两种计费方式,按量付费采用阶梯价计算,满足企业客户多种压测需求。

    官网链接:https://www.aliyun.com/product/pts

    10

    压测宝

    压测宝是云智慧推出的面向真实用户行为与地域分布的全链路云端压力测试平台,通过云端服务器产生真实分布式用户访问压力,模拟来自各地域用户接入后台所带来的真实流量,无限接近生产环境所面临的各种复杂因素,测量真实的用户体验。通过集成云智慧应用性能管理和监控产品,帮助实现基于真实用户行为的压测方案定制、压测过程中实时定位各环节应用资源及代码瓶颈,现场纠错,分析应用性能肇因。

    产品功能特色方面,压测宝通过独有的开放架构,支持各种主流网络协议;同时支持手机APP的脚本录制方式,可以大大降低压测脚本制作的时间和难度。依托压测宝以及完善的产品线,云智慧为用户提供了一站式压测服务,面向云计算时代的复杂应用提供专业性能压测服务,帮助企业客观评估应用性能容量,发现全链路性能瓶颈,对应用架构的调优及架构容量规划提供专业咨询服务,满足企业灵活多变的业务需求。目前压测宝已提供高达10万UV并发级别的压测服务。

    官网链接:http://www.yacebao.com/

    以上是市面上比较常见的十款压力/负载/性能测试工具,其中以Jmeter和Loadrunner为代表的大部分产品属于传统防火墙内的压测,适用于测试内网系统硬件资源以及服务、数据库在并发条件下的性能表现。阿里云PTS和CloudTest为代表的第二代压测产品把压测机迁移到云端,通过云资源在防火墙外部生成规模并发,有效降低了压测的成本与准备周期,提高了效率。只是由于压测点限制,国外或阿里的云压测产品,很难对国内应用,特别是非阿里环境部署的应用发起有效测试。

    为满足复杂的云端分布式应用交付场景的压力测试需求,第三代以云智慧压测宝为代表的压测产品应运而生,从终端用户行为与体验的视角来审视应用性能问题,通过与APM整合深度追踪系统,准确发现影响性能的问题瓶颈。

    展开全文
  • 2、选择-Binaries下面的版本 apache-jmeter-x.x.x.tgz sha512 pgp apache-jmeter-x.x.x.zip sha512 pgp 其中x.x.x.tgz是适用于Linux系统系列的版本 x.x.x.zip格式的适用于Windows版本 如果是m...
  •  目前啊,都知道,大数据集群管理方式分为手工方式(Apache hadoop)和工具方式(Ambari + hdp 和Cloudera Manger + CDH)。  手工部署呢,需配置太多参数,但是,好理解其原理,建议初学这样做,能学到很多。该...
  • 性能测试基础篇

    2020-04-28 23:10:04
    目录 一、性能测试基础 二、概念和术语介绍 三、性能测试模型 四、性能测试分类介绍 一、性能测试基础 1. 为什么要进行性能测试 为了保证所有设备运转正常 2. 性能测试关注什么 ...3. 谁会...
  • 因为 2013 有了全链路压测。 每年的 11 月 11 日 00:00:00,阿里巴巴集团最紧张激动的时刻到来了。多收档的热情这一刻开始爆发,反映到数字上是去年双十一今人的记录:24 小时交易额 1012 亿,交易创建峰值 17.2w...
  • 那么互联网产品为什么要进行压力/负载/性能测试,又有哪些工具帮我们实现呢,本文将为您细说端详。 压力/负载/性能测试之异同 在产品研发过程中,常常会混淆压力/负载/性能测试这三者之间的区别,这三种测试到底有...
  • excel文件导入sql sever中: 如果就把Excel数据插入一个新表,就选择【复制一个或多个表或视图的数据】  如果想把Excel数据插入到已存在的一张表中,则选择下面的【编写查询以指定要传输的数据】  ...
  • 从0到1构建美团压测工具

    千次阅读 2019-07-05 10:05:39
    美团内部的RPC服务大多构建在Thrift之上,在日常开发服务的过程中,需要...使用开源工具进行压测 然而,无论采取哪种方法,压测都是一个十分耗时而又繁琐的过程,主要痛点有: 需要写很多代码解析日志,还原请求,...
  • rest接口测试工具下载 在 Roy论文的6.3节中,他解释了REST如何应用于HTTP。 但是,实施RESTful方法需要不使用REST工具进行艰苦的组装。 Java JAX-RS和API管理基础结构通过简化API的创建,发布和使用,减少了学习...
  • 美团线上真实流量压测 编者按:高可用架构分享及传播在架构领域具有典型意义的文章,本文由杨硕在高可用架构群分享。 杨硕,现就职于美团,负责广告运营平台、美团点评广告系统对接等工作。曾就职于 Yahoo ! 北...
  • 编者按:高可用架构分享及传播在架构领域具有典型意义的文章,本文由杨硕在高可用架构群分享。点击上方蓝字订阅高可用架构可获取进群机会。杨硕,现就职于美团,负责广告运营平台、美...
  • 此文档是有关测试资料的,大家可以看看,希望有帮助
  • YCSB压测Kudu

    2020-04-16 18:55:59
    最近在工作中接触到了Kudu,在应用之前需要先对其性能进行各指标分析,于是用到了ycsb,...进行kudu压测需要编译或下载对应的压缩包。有两种方式可以获得该压缩包 第一种:将源代码(https://github.com/brianfra...
  • 移动互联网场景中随着人机交互方式的改变,用户数据也发生了比较大的改变。从以1k以下的文本为主数据,...1. 压测工具:mcperf mcperf使用简单,输出报告清晰。最初是twitter为了证明其Twemcache在特定场景下(需要...
  • pktgen-dpdk 简介 Pktgen(Packet Gen-erator)是一个基于软件的流量生成器,由 DPDK 快速数据包处理框架提供支持。 Pktgen 的一些功能是: 它能够生成具有 64 字节帧的 10Gbit 线速流量。...
  • 大数据平台现状 饿了么的大数据平台团队成立于2015年5月份左右,在16年4月份,Hadoop集群规模还只在100+节点数,而在一年时间里集群规模快速增长到1000+的水平,这还是在引入数据生命周期进行管控的情况下的规模...
1 2 3 4 5 ... 20
收藏数 1,936
精华内容 774
关键字:

压测工具 大数据