zoukankan      html  css  js  c++  java
  • CloudFoundry 中的GoRouter性能測试

          之前一直感觉CloudFoundry的GoRouter的性能不靠谱,或者我们的CloudFoundry 部署架构存在问题,想着进行一些压力測试,可是一直苦于没有压力測试的工具。上一周,部门须要出一个測试报告,刚好借此机会。进行一个比較好的測试。

          測试的时候,是使用的两个gorouter+nginx,測试使用的应用是一个比較简单的应用,使用LoadRunner进行压力測试,使用LoadRunner的1000个用户进行,測试效果非常差。和QQ群里的同学交流,他们也出现了类似的问题,使用F5或者HaProxy 都非常正常,可是使用nginx 出现非常多问题,表现出来的性能非常差。所以也尝试改用haproxy做负载均衡。

        haproxy的部署方式就不描写叙述了,使用haproxy的默认配置,性能也是非常差,開始进行调优。一開始以为是应用、gorouter的问题,可是定位了非常久,发现这些眼下看来都没有什么问题。最后,对haproxy的配置文件进行了优化,眼下我的haproxy配置文件:

          global
        log 127.0.0.1   syslog info
        daemon
        maxconn 300000
        spread-checks 4
        nbproc 8

    defaults
        log global
        timeout connect 30000ms
        timeout client 300000ms
        timeout server 300000ms
        # maxconn 320000
       # option http-pretend-keepalive
        option dontlognull
        option forwardfor
        option redispatch
        option abortonclose
    listen admin_stats
           bind 0.0.0.0:1080   
            mode http            
            option httplog
            maxconn 10
            stats refresh 30s
            stats uri /stats
            stats realm XingCloud Haproxy
            stats auth admin:admin        
            stats hide-version             
    frontend http-in
        mode tcp
        bind *:80
        reqadd X-Forwarded-Proto: http
        default_backend tcp-routers

    backend tcp-routers
        mode tcp
        balance source
             server node1 10.106.1.46:80  weight 10  inter 2000 rise 2 fall 5 maxconn 10000
            server node2 10.106.1.57:80  weight 10 inter 2000 rise 2 fall 5 maxconn 10000

    还须要改动 操作系统的配置 /etc/sysctl.conf

    net.ipv4.ip_forward = 0
    net.ipv4.conf.default.rp_filter = 1
    net.ipv4.conf.default.accept_source_route = 0
    kernel.sysrq = 0
    kernel.core_uses_pid = 1
    net.ipv4.tcp_syncookies = 1
    kernel.msgmnb = 65536
    kernel.msgmax = 65536
    kernel.shmmax = 68719476736
    kernel.shmall = 4294967296
    net.ipv4.tcp_max_tw_buckets = 6000
    net.ipv4.tcp_sack = 1
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.tcp_rmem = 4096        87380   4194304
    net.ipv4.tcp_wmem = 4096        16384   4194304
    net.core.wmem_default = 8388608
    net.core.rmem_default = 8388608
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.core.netdev_max_backlog = 262144
    net.core.somaxconn = 262144
    net.ipv4.tcp_max_orphans = 3276800
    net.ipv4.tcp_max_syn_backlog = 262144
    net.ipv4.tcp_timestamps = 0
    net.ipv4.tcp_synack_retries = 1
    net.ipv4.tcp_syn_retries = 1
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_mem = 94500000 915000000 927000000
    net.ipv4.tcp_fin_timeout = 1
    net.ipv4.tcp_keepalive_time = 30
    net.ipv4.ip_local_port_range = 1024    65000
    net.nf_conntrack_max = 1024000

        改动该配置文件,主要是为了添加机器能够打开的TCP连接数,还须要设置ulimit,设置的应该比較大一些。我使用的操作系统是Ubuntu10.04 ,须要载入模块 modprobe ip_conntrack

    终于的測试结果:

     

     

    之前使用nginx的时候,才300TPS。。。哎。。如今最终好多了。眼下使用的机器都是虚拟机(4core /10G/ )假设使用更好的机器,不知道结果会不会好一些。

    个人独立博客:http://www.wangdk.com/

  • 相关阅读:
    Mac开发利器之程序员编辑器MacVim学习总结(转)
    FFmpeg的H.264解码器源代码简单分析
    Google推荐的图片加载库Glide
    Java集合及concurrent并发包总结(转)
    ArrayList、Vector和LinkedList等的差别与用法(基础回顾)
    应用最广泛的模式-工厂方法模式
    Android 开发 命名规范(基础回顾)
    Java线程问题(基础回顾)
    Mac下使用wireshark解决Interface为空的办法
    Express4.10.2开发框架中默认app.js的代码注释
  • 原文地址:https://www.cnblogs.com/hrhguanli/p/4517334.html
Copyright © 2011-2022 走看看