后续之《SpringBoot服务器压测对比(jetty、tomcat、undertow)》

原创
2018/12/07 11:41
阅读数 16.6W

一、前言

    昨天发了一个《SpringBoot服务器压测对比(jetty、tomcat、undertow)》,本是工作的一个笔记,没想到被红薯翻牌了(荣幸之至)。看了OSCer的回复,感觉需要重新梳理下,因为确实存在描述不清和不合理的配置。

    这篇博客的目的,不是复述上一篇博客,而是尽量规范的去做一次压测对比,并且能够清晰的描述出过程和结果。

二、准备

    1、服务器

        为了保证尽量少的干扰,这里不再在虚拟机上运行服务,而是直接在物理机上运行服务,并且在这台物理机上安装ab工具。

        服务器配置是2个CPU,单个CPU8核,总共内存40G,1T的RAID5机械硬盘。服务器安装的系统是Centos7.5,系统优化同《Centos7高并发优化》所述。但额外的,因工作需要,这台物理机上有6个虚机,是不能关闭的。以下是简单的top展示:

    2、测试项目

        感谢@TGVvbmFyZA 的建议,测试项目不再使用生产项目,而是从Springboot官网打包2.x版本的项目,这样的目的是减少生产项目中不必要的依赖,从而避免不必要的开销。以下是简单的项目介绍:        

序号 名称 版本
1 springboot 2.1.1
2 java 1.8

        我已将项目放到Gitee,地址:https://gitee.com/loveliyiyi/test4server

        以下贴出关键代码,以便更好理解。        

package com.shy.test4server;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.context.request.async.WebAsyncTask;

/**
 * @ClassName: TestController
 * @Description: TODO(这里用一句话描述这个类的作用)
 * @author chengcai.shang@cmgplex.com
 * @date 2018年12月7日 上午9:36:25
 * 
 */
@Controller
@RequestMapping("/test")
public class TestController {
	/**
	 * 未使用HTTP异步的接口
	 * 
	 * @Title: testCeilingNoAsync
	 * @Description: TODO(这里用一句话描述这个方法的作用)
	 * @date 2018年12月7日 上午9:40:57
	 */
	@GetMapping("/testCeilingNoAsync")
	public String testCeilingNoAsync() {
		return "";
	}

	/**
	 * 使用HTTP异步的接口
	 * 
	 * @Title: testCeilingNoAsync
	 * @Description: TODO(这里用一句话描述这个方法的作用)
	 * @date 2018年12月7日 上午9:40:57
	 */
	@GetMapping("/testCeilingWithAsync")
	public WebAsyncTask<String> testCeilingWithAsync() {
		return new WebAsyncTask(() -> {
			return "";
		});
	}
}

    3、项目优化

        不同的服务器容器优化参数均不一致,以下是本次测试主要优化的地方:

序号 服务容器 优化参数
1 tomcat 最大连接数server.tomcat.max-threads=400
2 jetty 最大连接数(400)和最小连接数(10)
3 undertow cpu核数(16)和工作线程数(400)
4 http异步 线程池core=10,max=400,queue=200

        以下优化步骤:

        针对tomcat,在application.properties中加入server.tomcat.max-threads=400即可。

        针对jetty,在config目录加入JettyConfig类

package com.shy.test4server.config;

import org.apache.catalina.Server;
import org.springframework.boot.web.embedded.jetty.JettyServerCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @ClassName: JettyConfig
 * @Description: TODO(这里用一句话描述这个类的作用)
 * @date 2018年12月7日 上午9:53:46
 * 
 */
@Configuration
public class JettyConfig {
	@Bean
	public JettyEmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory(
			JettyServerCustomizer jettyServerCustomizer) {
		JettyEmbeddedServletContainerFactory factory = new JettyEmbeddedServletContainerFactory();
		factory.addServerCustomizers(jettyServerCustomizer);
		return factory;
	}

	@Bean
	public JettyServerCustomizer jettyServerCustomizer() {
		return server -> {
			threadPool(server);
		};
	}

	private void threadPool(Server server) {
		// Tweak the connection config used by Jetty to handle incoming HTTP
		// connections
		final QueuedThreadPool threadPool = server.getBean(QueuedThreadPool.class);
		// 默认最大线程连接数200
		threadPool.setMaxThreads(100);
		// 默认最小线程连接数8
		threadPool.setMinThreads(20);
		// 默认线程最大空闲时间60000ms
		threadPool.setIdleTimeout(60000);
	}
}

        针对undertow,在application.properties中加入server.undertow.io-threads=16和server.undertow.worker-threads=400即可

        针对http异步,优化代码如下:

package com.shy.test4server.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
import org.springframework.web.servlet.config.annotation.AsyncSupportConfigurer;

/**
 * @ClassName: SpringmvcConfig
 * @Description: TODO(这里用一句话描述这个类的作用)
 * @date 2018年12月7日 上午9:59:06
 * 
 */
@Configuration
public class SpringmvcConfig {
	@Bean
	public void configThreadPoll(AsyncSupportConfigurer asyncSupportConfigurer) {
		ThreadPoolTaskExecutor threadPool = new ThreadPoolTaskExecutor();
		threadPool.setCorePoolSize(10);
		threadPool.setMaxPoolSize(400);
		threadPool.setQueueCapacity(200);
		threadPool.initialize();
		asyncSupportConfigurer.setTaskExecutor(threadPool);
	}
}

        另,所有测试中,日志均关闭。

三、压测方案

    由于三个服务器的优化参数不一致,没法做统一配置,然后观察结果。故只能不断调整参数获取最大的结果,然后比对最终结果,虽然这样得出结果有点片面,但目前也只能这么干。另外,不再辅以Jprofiler监控,因为Jprofiler会影响一定得性能。以下是压测步骤:

    1、使用tomcat,压测两个接口,按不同并发访问10000次,然后不断调整参数,获取最大结果。由此可得出纯tomcat和tomcat+http异步的结果。

    2、使用jetty,压测两个接口,按不同并发访问10000次,然后不断调整参数,获取最大结果。由此可得出纯jetty和jetty+http异步的结果。

    3、使用udertow,压测两个接口,按不同并发访问10000次,然后不断调整参数,获取最大结果。由此可得出纯udertow和udertow+http异步的结果。

四、压测过程

    1、tomcat

        启动命令

java -server -Dserver.tomcat.max-threads=400 -Dspringmvc.thread.core=10 -Dspringmvc.thread.max=400 -Dspringmvc.thread.queue=200 -Xms512m -Xmx512m -jar test4server.jar

        压测命令

ab -n 10000 -c 50 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 50 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingWithAsync

        压测结果:

    2、jetty

        启动命令

java -server -Djetty.thread.max=400 -Djetty.thread.min=10 -Dspringmvc.thread.core=10 -Dspringmvc.thread.max=400 -Dspringmvc.thread.queue=200 -Xms512m -Xmx512m -jar test4server.jar

        压测命令

ab -n 10000 -c 50 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 50 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingWithAsync

        压测结果:

    3、undertow

        启动命令

java -server -Dserver.undertow.io-threads=16 -Dserver.undertow.worker-threads=400 -Dspringmvc.thread.core=10 -Dspringmvc.thread.max=400 -Dspringmvc.thread.queue=200 -Xms512m -Xmx512m -jar test4server.jar

        压测命令

ab -n 10000 -c 50 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingNoAsync
ab -n 10000 -c 50 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 100 http://localhost:8080/test/testCeilingWithAsync
ab -n 10000 -c 200 http://localhost:8080/test/testCeilingWithAsync

        压测结果:

五、压测结果

    1、关于HTTP异步

        HTTP异步的目的在帮助dispatcherservlet分担压力,提升吞吐量。但如果运行在NIO模式的服务容器上,就会产生负面影响,因为NIO本身就做了类似的事情,此时再加HTTP异步,则相当于又加了N多不必要的线程,导致性能主要消耗在线程的开销上,所以建议使用tomcat作为内嵌容器并且没有开启tomcat的NIO模式时,可以配合HTTP异步来提升程序性能。尤其是当业务繁重时,提升效果尤其明显。

    2、关于服务容器

        在基于天花板接口的测试中,综合对比tomcat、jetty、undertow,可以发现undertow相对性能更高点。但此结果并不一定准确,因为测试方案里只进行了很简单的参数调整,以及并没有针对实际业务代码进行测试。不过源码我已提供,有兴趣的可以实际测试下。

展开阅读全文
打赏
20
110 收藏
分享
加载中
HTTP异步的目的在帮助dispatcherservlet分担压力,提升吞吐量。但如果运行在NIO模式的服务容器上,就会产生负面影响,因为NIO本身就做了类似的事情,此时再加HTTP异步,则相当于又加了N多不必要的线程,导致性能主要消耗在线程的开销上

你得出这个原因是因为你的实验里面都是CPU密集型操作(直接返回了字符串),不是实际中的IO密集型操作(调用接口、查询数据....),如果IO密集型,你再试试,这块异步化就会体现优势了
2020/10/29 19:47
回复
举报
nio模式下,查询数据库,http异步没有觉得有优势啊
01/13 15:46
回复
举报
你的这个测试用例,queue设置50000,线程数=16, 压到5w并发试试,能让你爽到爆炸。
2020/03/27 15:56
回复
举报
尚浩宇博主

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.

引用来自“Maxwell1987”的评论

瓶颈到了,spring boot 内嵌的 tomcat 差不多 300% 就到极限了,更多的 C 没用。

引用来自“尚浩宇”的评论

对,tomcat作为一个重量级人物,还是不适合内嵌这种场景

引用来自“Maxwell1987”的评论

实际上你测试的 3 种容器都在同一个量级上,谈不上谁重量谁轻量。内嵌也没有关系。你可以测试一下 webflux,用 netty 的也差不多。这瓶颈并不是 tomcat 的。

引用来自“尚浩宇”的评论

我记得webflux并不能提高性能,他只是在有限的资源下提高系统的吞吐量和伸缩性,本质上也是一个NIO模式

引用来自“Maxwell1987”的评论

我指的是,webflux 缺省用 netty 解析请求,在空调用的情况下也没有更高的 qps。由此认为 tomcat 重量以及不适合内嵌并没有说服力。
嗯,你说的在理,学习了
2018/12/13 09:59
回复
举报

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.

引用来自“Maxwell1987”的评论

瓶颈到了,spring boot 内嵌的 tomcat 差不多 300% 就到极限了,更多的 C 没用。

引用来自“尚浩宇”的评论

对,tomcat作为一个重量级人物,还是不适合内嵌这种场景

引用来自“Maxwell1987”的评论

实际上你测试的 3 种容器都在同一个量级上,谈不上谁重量谁轻量。内嵌也没有关系。你可以测试一下 webflux,用 netty 的也差不多。这瓶颈并不是 tomcat 的。

引用来自“尚浩宇”的评论

我记得webflux并不能提高性能,他只是在有限的资源下提高系统的吞吐量和伸缩性,本质上也是一个NIO模式
我指的是,webflux 缺省用 netty 解析请求,在空调用的情况下也没有更高的 qps。由此认为 tomcat 重量以及不适合内嵌并没有说服力。
2018/12/13 00:39
回复
举报
尚浩宇博主

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.

引用来自“Maxwell1987”的评论

瓶颈到了,spring boot 内嵌的 tomcat 差不多 300% 就到极限了,更多的 C 没用。

引用来自“尚浩宇”的评论

对,tomcat作为一个重量级人物,还是不适合内嵌这种场景

引用来自“Maxwell1987”的评论

实际上你测试的 3 种容器都在同一个量级上,谈不上谁重量谁轻量。内嵌也没有关系。你可以测试一下 webflux,用 netty 的也差不多。这瓶颈并不是 tomcat 的。
我记得webflux并不能提高性能,他只是在有限的资源下提高系统的吞吐量和伸缩性,本质上也是一个NIO模式
2018/12/11 10:12
回复
举报

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.

引用来自“Maxwell1987”的评论

瓶颈到了,spring boot 内嵌的 tomcat 差不多 300% 就到极限了,更多的 C 没用。

引用来自“尚浩宇”的评论

对,tomcat作为一个重量级人物,还是不适合内嵌这种场景
实际上你测试的 3 种容器都在同一个量级上,谈不上谁重量谁轻量。内嵌也没有关系。你可以测试一下 webflux,用 netty 的也差不多。这瓶颈并不是 tomcat 的。
2018/12/10 14:47
回复
举报
尚浩宇博主

引用来自“orpherus”的评论

方法调用10000次是jvm触发jit优化的阈值,所以测试前先预热个10万次,才更接近真实场景。另外tomcat还支持apr native优化,开与不开是有差异的。

正常情况,4核i5机器跑hello world,tomcat应该跑到20000以上rps才及格。
每次的数据都是重复执行10遍,选取的最大值。我这服务器本身硬件老旧,程序优化手段也很简单,主要是想看下常见优化手段下各个服务容器的反应
2018/12/10 08:53
回复
举报
尚浩宇博主

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.

引用来自“Maxwell1987”的评论

瓶颈到了,spring boot 内嵌的 tomcat 差不多 300% 就到极限了,更多的 C 没用。
对,tomcat作为一个重量级人物,还是不适合内嵌这种场景
2018/12/10 08:50
回复
举报
尚浩宇博主

引用来自“freezingsky”的评论

我tomcat和undertow 在2核,4G的情况下,吞吐量,tomcat为3700+,undertow为4300+.请求量为10万.
你这设备配置应该不止这个数啊.
看参数还可以,但是服务器本身已经不行了,PowerEdge R710,本身就是我从线上淘汰下来的机器攒机出来的
2018/12/10 08:49
回复
举报
尚浩宇博主

引用来自“局长”的评论

红薯又要翻牌了
😜
2018/12/10 08:43
回复
举报
更多评论
打赏
17 评论
110 收藏
20
分享
返回顶部
顶部