Pushlet 性能测试计划v1预览

      根据之前MQ的性能测试经验,撰写了Pushlet(高性能,分布式消息推送中间件)的测试计划。这里放出来,希望能给大家一些参考,同时也希望大家多提意见~

  1. Summary

  2. TestMethodology

    2.1 Test Conditions

    2.2 Test Scenario’s

    2.3 Test Duration

    2.4 Environment

    2.5 Measurement

    2.6 Topology

PerformanceResults

3.1 Connection

3.2 Non-Reliable P2P

3.3 Reliable P2P

3.4 Non-Reliable Pub-Sub

3.5 Reliable Pub-sub

References


  1. Summary

Pushlet是一个基于socket.io协议的高性能,分布式消息推送服务Suite,为web,无线应用(Android,IOS)提供了一种简单统一的Push机制。

针对Pushlet这种能够承载C500k并发连接,并能实时可靠推送消息的特性,我们重点考察如下几个应用指标:并发连接总数,连接稳定性,TPS(send/get),推送可靠性,推送实时性。同时考察的系统指标有:CPUMemNetworkminor/ full GC频度与时间。

  1. TestMethodology

  1. 1 TestConditions
  • Client-> socket -> connection

  • Pushlet连接分两阶段,所有结果均建立在连接完全建立后。

  • 每种测试场景运行多次(3~5),达到统计平均效果

  • 测试期间,独占系统共享资源(CPU,MEM etc.

  • 可靠消息测试需要分standalonecluster两种场景

  • 所有测试场景均要考虑warmupcooldown

  1. 2 TestScenario’s

场景1:并发连接总数&连接稳定性

按照一定的rampup频率(可设定),脚本控制施压机发起连接请求(单网卡连接大致在64511),服务端观测tcp连接状态(重点关注SYN_RECVESTABLISHED,TIME_WAIT,CLOSE_WAIT状态,同时观察各个CPU(利用率是否均衡),JVM内存情况(新老生代回收频率,回收时间)。找到系统稳定连接总数(必要时校准kernel,JVM参数)。


场景2:点对点消息推送

选取10个左右的点对点通道,消息体(50byte150byte255byte1k5k)持续运行30分钟,测算推送TPS,推送成功率,推送时延。


场景3:点对点可靠消息推送

同上,选取10个左右的点对点通道,消息体(50byte150byte255byte1k5k)持续运行30分钟,测算推送TPS,推送成功率,推送时延。这里需要考虑测试离线消息推送,在线消息接受的场景。

场景4:广播消息推送

选取10个左右的广播通道(订阅方个数分别为51015),消息体(50byte150byte255byte1k5k)持续运行30分钟,测算推送TPS,推送成功率,推送时延。

场景5:可靠广播消息推送

暂不支持

2.3 TestDuration

所有的测试场景需要持续10分钟以上,并伴有一定时长的warmupcooldown

2.4 Environment

  • Serversystem

RedHat Enterprise Linux Server release 5.7 (Tikanga)

2.6.18-308.4.2.ali1012.el5xen

4CPU Intel(R)Xeon(R)L5630@2.13GHz

x86_648G RAM 6T disk

  • Clientsystem

RedHat Enterprise Linux Server release 5.7 (Tikanga)

2.6.18-308.4.2.ali1012.el5xen

4CPU Intel(R)Xeon(R)L5630@2.13GHz

x86_648G RAM 6T disk

  • NetworkSettings

分两种情况:办公网络,公网

网速1GBPS

  • Serverkernel(sudo vi /etc/sysctl.conf ... sudo /sbin/sysctl -p,另外也可以通过echo,cat形式验证,如echo 1 >cat /proc/sys/net/ipv4/tcp_tw_reuse cat /proc/sys/net/ipv4/tcp_tw_reuse)

fs.file-max =1000000

ulimit -n 1000000

net.ipv4.tcp_max_syn_backlog=3240000

net.core.netdev_max_backlog=3240000

net.core.somaxconn= 3240000

net.ipv4.ip_local_port_range= 1024 65535

net.ipv4.tcp_wmem= 4096 65536 524288

net.core.wmem_max= 1048576

net.ipv4.tcp_rmem= 4096 87380 524288

net.core.rmem_max= 1048576

net.ipv4.tcp_max_tw_buckets= 6000

net.ipv4.tcp_tw_reuse= 1

net.ipv4.tcp_syncookies= 1

net.ipv4.tcp_max_orphans= 262144

这里简单说明一下TCP的连接队列和半连接队列。半连接队列,收到syn包但是还没有收到ack包,半连接队列长度由min(min(somaxconn,listen的backlog参数),tcp_max_syn_backlog)决定,再取大于这个值的2的n次幂的值; 连接队列,已完成3次握手,但是由于应用程序accept线程(boss线程)忙,尚未accept。队列长度由min(somaxconn,应用socket的listen方法的backlog参数)决定。更详细说明,请参看:

https://gist.github.com/vongosling/9929680

补充说明:

The current TCP/IP parameters can be edited without the need for reboot in the following locations:

  /proc/sys/net/core/ 

 rmem_default = Default Receive Window

 rmem_max = Maximum Receive Window

 wmem_default = Default Send Window

 wmem_max = Maximum Send Window

  /proc/sys/net/ipv4/
   You’ll find timestamps, window scalling, selective acknowledgements, etc.Keep in mind the values in /proc will be reset upon reboot.You still need to add the code in /etc/rc.local or /etc/boot.local in order to have the changes 
applied at boot time as described above.

  • Software

JavaHotSpot(TM) 64-Bit Server VM (20.0-b11, mixed mode) 1.6.0_25

JavaHotSpot(TM) 64-Bit Server VM (20.0-b11, mixed mode) 1.7.0_51

Jdk6 jvm options

Xmx6g –Xms6g-Xmn256m

-XX:PermSize=128m-XX:MaxPermSize=256m

-Xss256k

-XX:+DisableExplicitGC

-XX:+UseConcMarkSweepGC

-XX:+UseParNewGC

-XX:+CMSParallelRemarkEnabled

-XX:+UseCMSCompactAtFullCollection

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=85

-XX:+UseFastAccessorMethods

-XX:+CMSPermGenSweepingEnabled

-XX:+HeapDumpOnOutOfMemoryError

Jdk7 jvm params

Xmx6g –Xms6g-Xmn256m

-XX:PermSize=128m-XX:MaxPermSize=256m

-Xss256k

-XX:+DisableExplicitGC

-XX:+UseG1GC

-XX:MaxGCPauseMillis=500

-XX:InitiatingHeapOccupancyPercent

-XX:G1HeapRegionSize=32

2.5 Measurement

综合使用iostat,jstack,jmap,mat,jps,top,jstat等工具,见后续博文

           2.6 Topology

3. PerformanceResults

3.1 Connection

连接总数

CPU

内存

GC情况

TCP状态

C100K





C300K





C500K











3.2 Non-Reliable P2P

消息体

TPSPut/Get

送达率

平均延时

50byte




150byte




255byte




1kb




5kb









3.3 Reliable P2P

消息体

TPSPut/Get

送达率

平均延时

50byte




150byte




255byte




1kb




5kb





3.4 Non-Reliable Pub-Sub

消息体

TPSPut/Get

送达率

平均延时

50byte




150byte




255byte




1kb




5kb





3.5 Reliable Pub-sub

暂无


4.References

http://write.blog.csdn.net/postedit/7200738

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/

http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-java-7-garbage-collectors/

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

http://blog.mgm-tp.com/2014/04/controlling-gc-pauses-with-g1-collector/

CMSand G1 Collector in Java 7 Hotspot: Overview,Comparisons andPerformance Metrics



上一篇:一起学Shell之(四)文本处理以及管道


下一篇:一起学Shell之(三) 查找与替换