CloudFoundry 中的GoRouter性能测试

标签: cloudfoundry gorouter 性能 | 发表时间:2014-06-25 03:22 | 作者:wangdk789
出处:http://blog.csdn.net

      之前一直感觉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/ )如果使用更好的机器,不知道结果会不会好一些。

作者:wangdk789 发表于2014-6-24 19:22:30 原文链接
阅读:97 评论:0 查看评论

相关 [cloudfoundry gorouter 性能] 推荐:

CloudFoundry 中的GoRouter性能测试

- - CSDN博客云计算推荐文章
      之前一直感觉CloudFoundry的GoRouter的性能不靠谱,或者我们的CloudFoundry 部署架构存在问题,想着进行一些压力测试,但是一直苦于没有压力测试的工具. 上一周,部门需要出一个测试报告,刚好借此机会.       测试的时候,是使用的两个gorouter+nginx,测试使用的应用是一个比较简单的应用,使用LoadRunner进行压力测试,使用LoadRunner的1000个用户进行,测试效果非常差.

gorouter调研

- - SegmentFault 最新的文章
最近在公司调研docker集群方案,涉及到 router这一层,有两个可选方案,源于cloudfoundry的 gorouter & 源于dotcloud的 hipache, 因为对golang实现的gorouter比较有好感,就主要调研了下. 项目地址: https://github.com/cloudfoundry/gorouter/.

MySQL 性能

- - 谁主沉浮
这里罗列了一些基本的 MySQL 性能提示,但不是放之四海而皆准,需要根据实际的应用情况而决定. 使用标准化设计(数据库三范式),记住表的联合查询(join)性能不会差. 选择合适的字符集,虽然UTF16无所不能,但需要两倍的存储;UTF8适合各种字符,但比latin1慢,尽可能选用latin1(此条不适合中文).

性能监控

- - 互联网 - ITeye博客
一旦你的服务器是在控制台模式下运行,你就可以开始我们接下来的内容. iostat  iostat 命令用来显示存储子系统的详细信息,通常用它来监控磁盘 I/O 的情况. 要特别注意 iostat 统计结果中的 %iowait 值,太大了表明你的系统存储子系统性能低下. meminfo 和 free  Meminfo 可让你获取内存的详细信息,你可以使用 cat 和 grep 命令来显示 meminfo 信息: 1 cat /proc/meminfo  另外你可以使用 free 命令来显示动态的内存使用信息,free 只是给你大概的内存信息,而 meminfo 提供的信息更加详细.

高性能mysql 之 性能剖析

- - 数据库 - ITeye博客
1 定义性能优化 mysql服务器性能,此处定义为 响应时间. 在解释性能优化之前,先来消除一个误解,很多人认为,性能优化就是降低cpu的利用率或者减少对资源的使用. 资源时用来消耗并用来工作的,所以有时候消耗更多的资源能够加快查询速度,保持cpu忙绿,这是必要的. 很多时候发现 编译进了新版本的InnoDB之后,cpu利用率上升的很厉害,这并不代表性能出现了问题.

MySQL性能优化

- sun - IT程序员面试网
在笔试面试中,尤其是像百度,淘宝这些数据量非常大,而且用LAMP架构的公司,数据库优化方面就显得特别重要了. 此外,除了数据库索引之外,在LAMP结果如此流行的今天,数据库(尤其是MySQL)性能优化也是海量数据处理的一个热点. 下面就结合自己的经验,聊一聊MySQL数据库优化的几个方面. 首先,在数据库设计的时候,要能够充分的利用索引带来的性能提升,至于如何建立索引,建立什么样的索引,在哪些字段上建立索引,上面已经讲的很清楚了,这里不在赘述.

HBase性能调优

- - 学着站在巨人的肩膀上
我们经常看到一些文章吹嘘某产品如何如何快,如何如何强,而自己测试时却不如描述的一些数据. 其实原因可能在于你还不是真正理解其内部结构,对于其性能调优方法不够了解. 本文转自TaoBao的Ken Wu同学的博客,是目前看到比较完整的HBase调优文章. 原文链接:HBase性能调优. 因官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果.

mongodb性能测试

- - 数据库 - ITeye博客
1) Mongodb的非安全插入方式,在一开始插入性能是非常高的,但是在达到了两千万条数据之后性能骤减,这个时候恰巧是服务器24G内存基本占满的时候(随着测试的进行mongodb不断占据内存,一直到操作系统的内存全部占满),也就是说Mongodb的内存映射方式,使得数据全部在内存中的时候速度飞快,当部分数据需要换出到磁盘上之后,性能下降很厉害.

JDBC性能小贴

- - 开源软件 - ITeye博客
本文收集了一些用于提升JDBC性能的方法. Java应用或者JavaEE Web应用的性能是很重要的,尤其是数据库后端对应用的性能影响. 不知你是否经历过Java、JavaEE web应用非常慢的案例没有(处理一个简单的请求都要花上好几秒的时间用于数据库访问,分页、排序等). 下面这些贴士也许能提升Java应用的性能.

hbase性能调优

- - 数据库 - ITeye博客
   1)、hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容很大(上MB,比如大的put、使用缓存的scans)的时候,如果该值设置过大则会占用过多的内存,导致频繁的GC,或者出现OutOfMemory,因此该值不是越大越好.