记一次zuul的压力测试
阅读数:151 评论数:0
跳转到新版页面分类
python/Java
正文
使用ab工具对spring cloud的zuul进行压力测试,我的网关只有验证token的逻辑,如果token不存在返回一个提示。但是测试时发现qps(这里也可以理解为tps)只有400左右。但是对于应用广泛的开源组件,这显然是未优化过的。
使用jconsole进行观察
jconsole是jdk自带的工具。
在起动时添加参数
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=2099 -Djava.rmi.server.hostname=192.168.50.5
发现内存和cpu都没有出现异常。观察线程,发现不论我的并发是多少,实际运行的线程也就1或2个,这显然是不对的。于是我开始怀疑是不是我的ab工具或者网络配置的不对。
1、把ab工具装到了centos7系统本机上,同时进行了以下调整。
(1)ulimit -SHn 65535
(2)修改/ect/sysctl.conf
#添加
net.ipv4.tcp_syncookies=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.nf_conntrack_max=100000
net.netfilter.nf_conntrack_max=100000
(3)修改服务器上的/etc/sysctl.conf
#添加
net.ipv4.tcp_syncookies=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
现在qps已经达到了1000多,但是还不很理想。
2、使用jprofiler和jstack找到新的瓶颈
通过在windows上安装jprofiler9, 在服务器上也安装了jprofiler9(版本要一致,以在从这里下载https://download.csdn.net/download/chs007chs/10930102),这样我就可以在我的windows机器上通过界面连接服务器上的jvm进程,这里发现在压测时有线程blocked的情况,于是通过jstack工具dump在线程快照,发现是logback日志写入文件的线程造成了阻塞。
于是修改日志配置文件:
<appender name="info_file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.path}/${application.name}/info.log</file>
<append>true</append>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>${log.path}/${application.name}/%d{yyyy-MM-dd}/info/info-%i.zip</fileNamePattern>
<maxFileSize>50MB</maxFileSize>
<maxHistory>7</maxHistory>
<totalSizeCap>2GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n</pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.LevelFilter">
<level>INFO</level>
<onMatch>ACCEPT</onMatch>
<onMismatch>DENY</onMismatch>
</filter>
</appender>
<appender name="warn_file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.path}/${application.name}/warn.log</file>
<append>true</append>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>${log.path}/${application.name}/%d{yyyy-MM-dd}/warn/warn-%i.zip</fileNamePattern>
<maxFileSize>50MB</maxFileSize>
<maxHistory>15</maxHistory>
<totalSizeCap>2GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n</pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.LevelFilter">
<level>WARN</level>
<onMatch>ACCEPT</onMatch>
<onMismatch>DENY</onMismatch>
</filter>
</appender>
<appender name="error_file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.path}/${application.name}/error.log</file>
<append>true</append>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>${log.path}/${application.name}/%d{yyyy-MM-dd}/error/error-%i.zip</fileNamePattern>
<maxFileSize>50MB</maxFileSize>
<maxHistory>15</maxHistory>
<totalSizeCap>2GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n</pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.LevelFilter">
<level>ERROR</level>
<onMatch>ACCEPT</onMatch>
<onMismatch>DENY</onMismatch>
</filter>
</appender>
<appender name="async_info_file" class="ch.qos.logback.classic.AsyncAppender">
<discardingThreshold>0</discardingThreshold>
<queueSize>512</queueSize>
<appender-ref ref="info_file"/>
</appender>
<appender name="async_warn_file" class="ch.qos.logback.classic.AsyncAppender">
<discardingThreshold>0</discardingThreshold>
<queueSize>512</queueSize>
<appender-ref ref="warn_file"/>
</appender>
<appender name="async_error_file" class="ch.qos.logback.classic.AsyncAppender">
<discardingThreshold>0</discardingThreshold>
<queueSize>512</queueSize>
<appender-ref ref="error_file"/>
</appender>
通过使用异步日志后,不再出现线程阻塞的情况,继续使用jprofiler观察,在CPU View->Call Tree中发现,在我自定义的zuulFilter中使用fastjson进行序列化时比较耗cpu,于是重新修改了自定义zuulfilter,减少了fastjson的使用。最后,qps在3000左右,其本满足了我的预期。