zoukankan      html  css  js  c++  java
  • 高并发架构

    1.1 高并发介绍

      1、高并发中一些概念

          1. PV(访问量): 页面访问量,页面刷新一次算一次。

          2. UV(独立访客): 即Unique Visitor,一个客户端(电脑,手机)为一个访客;

          3. DAU(日活跃用户数):登录或使用了某个产品的用户数,这与流量统计工具里的访客(UV)概念相似。

          4. 峰值QPS:

              原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间

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

          5. QPS/TPS(每秒查询率):每秒能够查询次数(QPS/TPS= 并发数 / 平均响应时间)

              并发数:并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。

              吐吞量:吞吐量是指系统在单位时间内处理请求的数量

              响应时间(RT):响应时间是指系统对请求作出响应的时间,一般取平均响应时间

      2、举例说明 

        1)例1:

            1. 假设1秒钟100个请求,处理每个请求需要花2秒,

            2. 那么 50(每秒可以处理50个请求,即QPS使50) = 100(每秒并发数) / 2 (每个请求的平均处理时间)

            3. 这是一台机器的QPS,如有每秒并发数为1000,那么就需要10台这样的机器才扛得住:

        2)例2:

            1. 每天200万PV,那么它的QPS = (2000000 * 0.8)/ (24*60*60*0.2)≈ 93

            2. 假设按照上面那样一台机器的QPS是50,那么抗住每天200万PV的访问量需要2台这样的机器

      3、django性能

        1)原生django:

            用原生django的server做处理的,在10000次请求的情况下brokenpipe的几率极高,成功率只有14%。

        2)uwsgi + nginx:

            uwsgi是性能极高的一个由C编写的服务器,它使用uwsgi协议

            这次让它配合nginx处理django的request,参数为4进程+2线程,性能立即直线上升,处理请求的成功率也基本在90%左右

    1.2 django + uwsgi性能测试

      1、说明

          1. 由于Python中GIL的存在,所以为了提高并发通常使用多进程运行web程序,进程数设置为CPU核心数(可以适当多余CPU数量)

          2. 比如我们我们下面的测试环境使用的是,4核 8G的机器,可以设置 uwsgi为: 4个进程,每个进程开2个线程

    [uwsgi]
    socket = 0.0.0.0:3031
    chdir = /code
    wsgi-file = /code/demo2/wsgi.py
    processes = 4  # 开启5个进程
    threads = 2    # 每个进程最多开启2个线程
    master = true
    daemonize = /code/uwsgi.log
    pidfile = /code/uwsgi.pid
    uwsgi.ini配置

      2、我们分别使用在2个、4个、8个并发的情况下的响应时间和QPS

          1. 通过下面测试,在并发为4的时候就达到了QPS的最高值,此时再继续增大并发,只会增加单个http请求的响应时间。

          2. 我们在保证响应时间在200ms的情况,通过上面的数据,估计最高并发大约为30 

          3. 以后在设置uwsgi参数时,将process设置为CPU的核心数就可以了,如果涉及到从磁盘读取数据的情况,可以考虑加上线程。

          4. 如果想增大并发能力就要办法降低单个http请求的响应时间。

          参考:https://blog.csdn.net/hehekk/article/details/85237375

          注:通过测试可以得出,django+uwsgi在4核机器中QPS最大也很难超过 200

    Concurrency Level:      30                # 模拟三十个并发客户端来压测
    Time taken for tests:   0.649 seconds     # 整个测试持续的时间
    Complete requests:      100               # 所有请求成功数量
    Failed requests:        0
    Total transferred:      1157000 bytes
    HTML transferred:       1119100 bytes
    Requests per second:    154.10 [#/sec] (mean)    # 每秒最多可以处理的请求(QPS)
    Time per request:       194.679 [ms] (mean)      # 用户平均请求等待时间
    Transfer rate:          1741.15 [Kbytes/sec] received   # 平均每秒网络上的流量

           

  • 相关阅读:
    阿里中间件——消息中间件Notify和MetaQ
    大型网站架构系列:分布式消息队列
    Mycat
    spring集成mybatis实现mysql读写分离
    mysql5.7.18的安装与主从复制
    NuGet学习笔记(3) 搭建属于自己的NuGet服务器
    NuGet学习笔记(1)——初识NuGet及快速安装使用
    Android 中使用 html 作布局文件
    获取WebView加载HTML时网页中的内容
    android学习——popupWindow 在指定位置上的显示
  • 原文地址:https://www.cnblogs.com/jiaxinzhu/p/12571382.html
Copyright © 2011-2022 走看看