精华内容
下载资源
问答
  • JMeter 压测QPS

    千次阅读 2019-05-21 13:10:59
    JMeter 压测QPS新建测试计划新建线程池新建定时器HTTP RequestListener 监听器 新建测试计划 新建线程池 Number of Threads (users) : 并发数量,能跑多少量。具体说是一次存在多少用户同时访问 Ramp-up Period...

    新建测试计划

    在这里插入图片描述

    新建线程池

    在这里插入图片描述

    1. Number of Threads (users) : 并发数量,能跑多少量。具体说是一次存在多少用户同时访问
    2. Ramp-up Period(in seconds): 表示JMeter每隔多少秒发动并发。理解成准备时长:设置虚拟用户数需要多长时间全部启动。如果线程数是20,准备时长为10,那么需要10秒钟启动20个数量,也就是每秒钟启动2个线程。
    3. Loop Count: 这个设置不会改变并发数,可以延长并发时间。总请求数=线程数*循环次数 (forever 勾选将会一直执行)
    4. Scheduler:调度器,设置压测的启动时间、结束时间、持续时间和启动延迟时间。

    新建定时器

    在这里插入图片描述
    Target throughput(in samples per minute):目标吞吐量。注意这里是每分钟发送的请求数,因此,对应测试需求中所要求的100 QPS ,这里的值应该是6000 。

    Calculate Throughput based on :有5个选项,分别是:

    1. This thread only :控制每个线程的吞吐量,选择这种模式时,总的吞吐量为设置的 target Throughput 乘以矣线程的数量
    2. All active threads : 设置的target Throughput 将分配在每个活跃线程上,每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
    3. All active threads in current thread group :设置的target Throughput将分配在当前线程 组的每一个活跃线程上,当测试计划中只有一个线程组时,该选项和All active threads选项的效果完全相同。
    4. All active threads (shared ):与All active threads 的选项基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
    5. All cative threads in current thread group (shared ):与 All active threads in current thread group 基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程的上 一次运行结束后等待合理的时间后再次运行。

    当 然,Constant Throughput Timer只有在线程组中的线程产生足够多的request 的情况下才有意义,因此,即使设置了 Constant Throughput Timer的值,也可能由于线程组中的线程数量不够,或是定时器设置不合理等原因导致总体的QPS不能达到预期目标.

    HTTP Request

    在这里插入图片描述

    Listener 监听器

    在这里插入图片描述

    展开全文
  • 压测QPS 过低

    2021-02-06 19:12:07
    你好,你的问题中,我可以依据我之前的管理经验回答你问题2、问题3。问题1这个问题并不是我擅长的部分,所以这个问题... 如:如果你怀疑Redis读取有瓶颈,建议你考虑将代码这块逻辑去掉,进行压测,看看是否有提升 等等

    你好,你的问题中,我可以依据我之前的管理经验回答你问题2、问题3。问题1这个问题并不是我擅长的部分,所以这个问题就不回答你了。

    问题2回答:

    其实你想解决的就是“copy on write”带来了redis性能响应的延迟问题。这个问题我觉得你可以这么尝试去出方案和运维或者开发讨论。

    方案1、提升内存不是一个好方法,因为瓶颈不在内存使用上导致的。

    方案2、开启AOF,关闭rdb,这个我觉得可以尝试,但记住需要关闭rdb。

    方案3、分布式缓存,这个方案是可以的,因为采用了集群的方案也能有效的提高整体的性能。但需要注意:你使用分布式缓存的模式 ,是redis cluster?还是走代理模式,通常通过redis走代理工具,不能建议这么作,反而会有额外的性能消耗。

    最后呢,你还可以考虑下方案4、方案5:

    方案4、使用redis的主从分离,主库不开启持久化,可以利用Redis复制功能将持久化功能转移到从库上,让这种方式保障数据库数据丢失的风险,同时提高Redis的服务响应能力。

    方案5、程序端,采用hash的方式,将数据打散,存储到后台多个redis实例上。

    问题3回答:

    这个性能瓶颈的问题,虽然你们的业务逻辑不复杂,但原因有很多可能性。你还是需要继续排查,找到压测的瓶颈。

    如:如果你怀疑Redis读取有瓶颈,建议你考虑将代码这块逻辑去掉,进行压测,看看是否有提升 等等

    展开全文
  • PHP siege 压测 QPS大小

    2018-10-10 17:29:00
    1、使用PHP-FPMSOCKET的形式通讯 2、配置 PHP-FPM配置 [root@bogon php-fpm.d]# ls -al 总用量 24 drwxr-xr-x. 2 root root 22 8月 13 12:15 . drwxr-xr-x. 87 root root 8192 8月 13 12...-rw-r--r--....

    1、使用 PHP-FPM SOCKET的形式通讯

    2、配置
    • PHP-FPM配置
    [root@bogon php-fpm.d]# ls -al
    总用量 24
    drwxr-xr-x.  2 root root    22 8月  13 12:15 .
    drwxr-xr-x. 87 root root  8192 8月  13 12:10 ..
    -rw-r--r--.  1 root root 10110 8月  13 12:05 www.conf
    [root@bogon php-fpm.d]# pwd
    /etc/php-fpm.d
    [root@bogon php-fpm.d]# vi www.conf
    
    pm = static
    
    ; The number of child processes to be created when pm is set to 'static' and the
    ; maximum number of child processes to be created when pm is set to 'dynamic'.
    ; This value sets the limit on the number of simultaneous requests that will be
    ; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
    ; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
    ; CGI.
    ; Note: Used when pm is set to either 'static' or 'dynamic'
    ; Note: This value is mandatory.
    pm.max_children = 200
    
    ; The number of child processes created on startup.
    ; Note: Used only when pm is set to 'dynamic'
    ; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
    pm.start_servers = 20
    
    ; The desired minimum number of idle server processes.
    ; Note: Used only when pm is set to 'dynamic'
    ; Note: Mandatory when pm is set to 'dynamic'
    pm.min_spare_servers = 5
    
    ; The desired maximum number of idle server processes.
    ; Note: Used only when pm is set to 'dynamic'
    ; Note: Mandatory when pm is set to 'dynamic'
    pm.max_spare_servers = 35
    ; The number of requests each child process should execute before respawning.
    ; This can be useful to work around memory leaks in 3rd party libraries. For
    ; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
    ; Default Value: 0
    pm.max_requests = 4096
    
    
    ; Set open file descriptor rlimit.
    ; Default Value: system defined value
    rlimit_files = 4096

     

    • Nginx 配置

      

    [root@bogon nginx]# pwd
    /usr/local/openresty/
    [root@bogon openresty]# cat nginx/conf/nginx.conf
    user  root;
    worker_processes  4;
    
    #error_log  logs/error.log;
    #error_log  logs/error.log  notice;
    #error_log  logs/error.log  info;
    
    #pid        logs/nginx.pid;
    
    
    events {
        worker_connections  2048;
    }
    

      

    • Linux 设置
    [root@bogon php-fpm.d]# cat /etc/rc.local
    #!/bin/bash
    # THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
    #
    # It is highly advisable to create own systemd services or udev rules
    # to run scripts during boot instead of using this file.
    #
    # In contrast to previous versions due to parallel execution during boot
    # this script will NOT be run after all other services.
    #
    # Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
    # that this script will be executed during boot.
    
    touch /var/lock/subsys/local
    ulimit -HSn 65535
    
    [root@bogon php-fpm.d]# source /etc/rc.local
    [root@bogon php-fpm.d]#
    

      3、Siege 压力测试结果

    [root@workspace ~]# siege -c 100 -r 10 http://10.2.1.123 -i -b
    Transactions:                   2550 hits
    Availability:                 100.00 %
    Elapsed time:                  43.20 secs
    Data transferred:             162.12 MB
    Response time:                  3.62 secs
    Transaction rate:              59.03 trans/sec
    Throughput:                     3.75 MB/sec
    Concurrency:                  213.65
    Successful transactions:        2550
    Failed transactions:               0
    Longest transaction:           18.46
    Shortest transaction:           0.04
    [root@workspace ~]#
    

      

    转载于:https://www.cnblogs.com/qichao123/p/9767866.html

    展开全文
  • 在使用locust压测的时候,如果使用web则可以查看到QPS压测过程的曲线图。而如果使用no web模式启动,则只有一些打印的日志可以查看。 那么能否将no web模式启动的locust执行过程日志转化为曲线图表呢? 如果需要将...

    需求

    在使用locust压测的时候,如果使用web则可以查看到QPS压测过程的曲线图。而如果使用no web模式启动,则只有一些打印的日志可以查看。

    那么能否将no web模式启动的locust执行过程日志转化为曲线图表呢?

    如果需要将日志转化为曲线图表,那么则以下步骤:
    1、将locust执行任务日志序列化,方便程序读取
    2、需要定时刷新获取执行日志文件,将日志信息写入数据库
    3、读取数据库数据,将其进行图表化呈现。

    并且还要求这个日志采集处理要足够轻量级、资源消耗小,只有在执行locust的时候才启动即可。所以,我也放弃了filebeat + logstash + Elasticsearch 或者 kafka 、redis等大型采集日志的方案。

    自己定制化写一个即可。

    将locust执行任务日志序列化

    方式一,直接在locust源码中挂上钩子,将日志格式化写入文件

    对于locust执行任务的日志序列化我尝试过直接在locust源码中挂上钩子,然后将日志进行格式化之后,再写入一个文件中。
    功能上是可以实现的,但是压测性能上就会大打折扣,由于locust在压测过程需要对每个压测请求都进行格式化以及写入文件,这样就很影响压测机的并发效率。

    所以这种方式已经被我抛弃。

    有兴趣可以参考:Matplotlib可视化查看Locust测试结果(一)

    方式二,过滤locust使用no web模式下打印出来的日志

    在经过多测压测测试之后,我决定直接使用locust执行过程打印的日志来生成图表。

    1、首先将locust执行过程的日志写入文件中
    2、通过读取执行文件的日志信息,再将其转化存储到influxdb数据库
    3、最后根据influxdb数据库的数据,展示图表

    在这个过程,对于locust自身的压测过程,我并没有嵌入代码去影响执行效率。而是将locust执行过程自动打印出来的信息进行二次处理而已。

    这样做的好处就是不会对locust压测造成较大的性能损耗,因为大概是5秒打印一次执行日志,相信这个损耗是比较低的了。

    原生的locust执行日志:

    可以从图中看到,在执行locust脚本使用no web模式的时候,执行的日志默认是INFO级别的,一般我们都是这样去使用。
    此时,INFO的日志信息和locust压测执行结果混合在一起打印,这就让人很不开心了。所以必须将其分开。

    首先确定我只需要的信息,如下:

    如果压测的接口有多个,那么就会有对应的多条信息。示例如下:

     Name                                                          # reqs      # fails     Avg     Min     Max  |  Median   req/s
    --------------------------------------------------------------------------------------------------------------------------------------------
     GET /apis1                                                        988     0(0.00%)      20       5      73  |      16   97.12
    --------------------------------------------------------------------------------------------------------------------------------------------
     GET /apis2                                                        988     0(0.00%)      20       5      73  |      16   97.12
    --------------------------------------------------------------------------------------------------------------------------------------------
     Total                                                            988     0(0.00%)                                      97.12
    

    确定好了需要的数据日志信息之后,下面第一步就是可以将INFO信息和执行结果信息拆分写入不同的日志文件中。

    拆分日志中的INFO信息与执行结果信息

    • --logfile=locust.log --loglevel=INFOINFO信息写到locust.log日志中
    • 1>run.log 2>&1 将压测执行的结果信息写到run.log日志中

    命令执行如下:
    locust -f locustfile.py --no-web -c 100 -r 50 --run-time=30 --expect-slaves=2 --csv=result --host='http://127.0.0.1:8000' --logfile=locust.log --loglevel=INFO 1>run.log 2>&1

    查看执行压测结果日志run.log如下:

    查看执行INFO信息日志locust.log如下:

    可以看到INFO信息和locust执行的压测结果已经分开日志文件存储好了。那么下面就需要想办法将执行压测结果的数据进行序列化读取,存储到influxdb中。

    使用python实时读取run.log日志信息

    在这里可以写一个简单的功能,如下:

    • 在开启执行locust脚本的同时,也启动这个python脚本或者一直长时间执行。
    • 在python脚本执行的过程期间,需要执行两个动作即可:读取日志信息,然后写入influxdb

    下面直接将实现好的python代码show出来,如下:

    import subprocess
    import re
    import os
    
    def main():
    
        # 实时读取日志信息
        shell = 'tail -F run.log'
        p = subprocess.Popen(shell, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
        for line in iter(p.stdout.readline, b''):
            line = line.rstrip().decode('utf8')
            # print(line)
            
            # 正则匹配获取所有的需要参数
            res = re.match(
                r'^\s+(?P<method>GET|POST)\s+(?P<api>[\/\w\?\=\&]+)\s+(?P<reqs>\d+)\s+(?P<fails>[\d\(\.\)\%]+)\s+(?P<Avg>\d+)\s+(?P<Min>\d+)\s+(?P<Max>\d+)\s+(\|)\s+(?P<Median>\d+)\s+(?P<QPS>[\w\.]+)$',
                line)
            if res:
                print("method: %s, api: %s, reqs: %s, fails: %s, Avg: %s, Min: %s, Max: %s, Median: %s, QPS: %s " % (
                    res.group('method'), res.group('api'), res.group('reqs'), res.group('fails').split('(')[0], res.group('Avg'),
                    res.group('Min'), res.group('Max'), res.group('Median'), res.group('QPS')
                ))
    
                # 设置需要写入influxdb的参数
                method = res.group('method')
                api = res.group('api')
                reqs = res.group('reqs')
                fails = res.group('fails').split('(')[0]
                avg = res.group('Avg')
                min = res.group('Min')
                max = res.group('Max')
                median = res.group('Median')
                qps = res.group('QPS')
    
                # 往influxdb写入数据
                # 创建数据库 curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE testdb"
                # 插入数据
                #                                                                       表名   索引 tag              字段 fields
                # curl -i -XPOST 'http://localhost:8086/write?db=testdb' --data-binary 'locust,method=GET,api=/apis reqs=2099,fails=10,avg=20,min=5,max=83,median=16,qps=95.10'
                database = 'testdb'
                table_name = 'locust'
                insert_data = "curl -i -XPOST 'http://localhost:8086/write?db=%s' --data-binary '%s,method=%s,api=%s reqs=%s,fails=%s,avg=%s,min=%s,max=%s,median=%s,qps=%s'" % (database,table_name,method,api,reqs,fails,avg,min,max,median,qps)
                os.system(insert_data)
    
    if __name__ == '__main__':
        main()
    

    此时执行的参数已经可以实时写入influxdb中了,如下:

    > precision rfc3339
    > 
    > select * from locust limit 10 tz('Asia/Shanghai')
    name: locust
    time                                api   avg fails max   median method min qps   reqs
    ----                                ---   --- ----- ---   ------ ------ --- ---   ----
    2019-11-21T14:59:19.040228993+08:00 /apis 16  0     43    14     GET    6   0     191
    2019-11-21T14:59:21.039195477+08:00 /apis 62  0     206   55     GET    6   36    481
    2019-11-21T14:59:23.059811043+08:00 /apis 151 0     1305  110    GET    6   96.2  765
    2019-11-21T14:59:25.077216006+08:00 /apis 211 0     2098  160    GET    6   103.5 990
    2019-11-21T14:59:27.066784427+08:00 /apis 272 0     4700  180    GET    6   110   1262
    2019-11-21T14:59:29.061261969+08:00 /apis 384 0     6386  190    GET    6   126.1 1532
    2019-11-21T14:59:31.079897673+08:00 /apis 395 0     9465  190    GET    6   133.4 1804
    2019-11-21T14:59:33.076470655+08:00 /apis 422 0     9707  200    GET    6   132   2034
    2019-11-21T14:59:35.084000478+08:00 /apis 526 0     13796 200    GET    6   127.1 2270
    2019-11-21T14:59:37.102809695+08:00 /apis 574 0     15456 200    GET    6   127.5 2553
    > 
    

    那么下一步只要在grafana展示图表就可以了。

    Grafana设置图表

    创建table图表

    先创建一个table表格,如下:

    将查询语句直接写入查询框中,然后选择数据库(我前面已经设置好,这里就不展示了),最后设置查询的时间,就可以看到数据展示了。

    最后修改标题,保存起来就可以了,下面再来做一个折线图。

    创建折线图

    同样的操作,如何需要在折线图上显示什么曲线,那就增加字段即可。在复制到grafana之前,最好在influx查询执行一下,看看能否执行成功。

    我的测试执行如下:

    > select "qps","avg" from locust limit 5 tz('Asia/Shanghai')
    name: locust
    time                                qps   avg
    ----                                ---   ---
    2019-11-21T14:59:19.040228993+08:00 0     16
    2019-11-21T14:59:21.039195477+08:00 36    62
    2019-11-21T14:59:23.059811043+08:00 96.2  151
    2019-11-21T14:59:25.077216006+08:00 103.5 211
    2019-11-21T14:59:27.066784427+08:00 110   272
    > 
    

    到这里就已经实现locust执行日志的实时查看了。

    效果图

    最后设置一下页面自动刷新,如下:

    另外,如果有不清楚influxdb和grafana安装和基本操作的,可以看看我之前写关于这两个工具的篇章:
    Grafana系列
    InfluxDB系列

    展开全文
  • 一、QPS,每秒查询 QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。互联网中,作为域名系统服务器的机器的...
  • 一、QPS,每秒查询 QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。互联网中,作为域名系统服务器的机器的...
  • 注意,压测压不上去,检查ab程序和nginx是不是同一台机器,同一机器影响压测结果,因为ab和nginx都在抢占cpu 实验 1. Nginx的配置调优:Nginx进程数 编辑nginx配置文件nginx.conf 客户端最大连接数 = worker...
  • 在很低的 QPS 压力下服务器 load 就能达到 10-20,CPU 使用率 60% 以上,而且在每次流量峰值时接口都会大量报错,虽然使用了服务熔断框架 Hystrix,但熔断后服务却迟迟不能恢复。每次变更上线更是提心吊胆,担心会...
  • QPS和TPS的区别、负载和压力测试的区别1. QPS/TPS2. 系统吞吐量 作为软件测试工程师,你应该要分清楚QPS和TPS的区别。 1. QPS/TPS QPS(Queries Per Second)意思为“每秒查询率”,是一台服务器每秒能够响应的查询...
  • Jmeter压力测试中的相关参数(QPS、TPS)
  • 2-华为-华为应用市场春晚百万级QPS全链路压测实践-吴进高.pdf
  • 最近笔者用vagrant安装了centos7系统,用了vagrant自带的文件夹共享挂载,为了方便开发调试 项目都是放在映射的文件夹中,nginx配置的路径也是指向这里,可是使用ab压测时,发现qps非常低,无论nginx和fpm如何优化...
  • 腾讯云服务器1核2G1Mbps。在linux本机上使用ab压测nginx的首页,QPS达到了17000左右。我想问下,如果是在外网环境下能否达到同样的效果。
  • 我用的阿里云学生机 配置是带宽 1m,内存 2g,单核...分别使用了 ab 和 wrk 测试静态首页 qps 最大才 600 左右 cpu 和内存占有率都很低,没有充分利用 请问是配置的问题吗,要怎么修改呢? 还是硬件的事?
  • 压力测试指标(QPS、TPS、PV、RT)

    千次阅读 2021-03-04 10:21:56
    QPS(Queries Per Second)每秒查询 每秒查询数率,系统每秒能够处理的查询请求次数,即一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 有两种计算公式: ...
  • 主要介绍了Python并发请求下限制QPS(每秒查询率)实现方法,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
  • 利用ab并发测试吞吐量QPS

    千次阅读 2020-08-18 12:06:28
    1.QPS:每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。因特网上,经常用每秒查询率来衡量域名系统服务器的机器的性能,其即为QPS。对应fetches/sec,即每秒的响应请求数,也即是最大...
  • 什么要统计这个信息,这个信息的对于压力测试的影响究竟是怎么样的,那就通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义。 我们将CPU就类比为电话亭,每一个进程都是一个需要打电话...
  • Jmeter设置QPS限制

    千次阅读 2019-01-02 01:16:20
    原文链接
  • |背景前段时间我们的服务遇到了性能瓶颈,由于前期需求太急没有注意这方面的优化,到了要还技术债的时候就非常痛苦了。在很低的 QPS 压力下服务器 load 就能达到 10-20,CPU 使用...
  • 在进行系统性能压测和系统性能优化的时候,会涉及到QPS,PV,RT相关的概念, 本文总结一下QPS,PV,RT之间的关系。 PV即Page View,网站浏览量 指页面的浏览次数,用于衡量网站用户访问的网页数量。用户每次打开一个...
  • 但是为什么我用http_load压测Gin,当300qps的时候,就开始出现大量超时。而且压测10min后就开始出现超时现象。我的Gi操作就是当请求进来后,sleep 1毫秒,然后return ok(1毫秒为模拟服务响应时间,比如查数据库什么...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,704
精华内容 4,281
关键字:

压测qps是什么