我对性能测试的设置如下：
示例应用程序公开了一个端点（/ passthrough / message），该端点又调用下游服务。 到端点的请求消息如下所示：
{"id": "1","payload": "sample payload","delay": 3000
}下游服务将基于消息中的“延迟”属性（以毫秒为单位）进行延迟。
Spring Boot 1应用程序
我已经将Spring Boot 1.5.8.RELEASE用于该应用程序的Boot 1版本。 端点是一个简单的Spring MVC控制器，它依次使用Spring的RestTemplate进行下游调用。 一切都是同步且阻塞的，我已使用默认的嵌入式Tomcat容器作为运行时。 这是下游调用的原始代码：
public MessageAck handlePassthrough(Message message) {ResponseEntity<MessageAck> responseEntity = this.restTemplate.postForEntity(targetHost + "/messages", message, MessageAck.class);return responseEntity.getBody();
}Spring Boot 2应用程序
该应用程序的Spring Boot 2版本公开了一个基于Spring Webflux的终结点，并使用WebClient ，这是RestTemplate的新的非阻塞，反应性替代方法，可以进行下游调用–我也使用Kotlin进行了实现，这与性能无关。 运行时服务器为Netty ：
import org.springframework.http.HttpHeaders
import org.springframework.http.MediaType
import org.springframework.web.reactive.function.BodyInserters.fromObject
import org.springframework.web.reactive.function.client.ClientResponse
import org.springframework.web.reactive.function.client.WebClient
import org.springframework.web.reactive.function.client.bodyToMono
import org.springframework.web.reactive.function.server.ServerRequest
import org.springframework.web.reactive.function.server.ServerResponse
import org.springframework.web.reactive.function.server.bodyToMono
import reactor.core.publisher.Monoclass PassThroughHandler(private val webClient: WebClient) {fun handle(serverRequest: ServerRequest): Mono<ServerResponse> {val messageMono = serverRequest.bodyToMono<Message>()return messageMono.flatMap { message ->passThrough(message).flatMap { messageAck ->ServerResponse.ok().body(fromObject(messageAck))}}}fun passThrough(message: Message): Mono<MessageAck> {return webClient.post().uri("/messages").header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE).header(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON_VALUE).body(fromObject<Message>(message)).exchange().flatMap { response: ClientResponse ->response.bodyToMono<MessageAck>()}}
}性能测试的详细信息
测试很简单，对于不同组的并发用户（300、1000、1500、3000、5000），我发送了一个延迟属性设置为300 ms的消息，每个用户重复该场景30次，延迟为1-2请求之间的秒数。 我正在使用出色的加特林工具来生成此负载。
结果
这些是加特林捕获的结果：
300个并发用户：
| 开机1 | 开机2 |
|---|---|
 | |
1000个并发用户：
| 开机1 | 开机2 |
|---|---|
| | |
1500个并发用户：
| 开机1 | 开机2 |
|---|---|
| | |
3000个并发用户：
| 开机1 | 开机2 |
|---|---|
| | |
5000个并发用户：
| 开机1 | 开机2 |
|---|---|
| | |
可以预期的是，当并发用户数保持较低水平（例如，少于1000个）时，Spring Boot 1和Spring Boot 2都能很好地处理负载，并且95％的响应时间仍比预期的300 ms延迟高出几毫秒。
在更高的并发级别上，Spring Boot 2中的异步非阻塞IO和响应式支持开始显示其颜色-即使负载非常大的5000个用户，第95个百分位时间仍保持在312ms左右！ 在这些并发级别上，Spring Boot 1记录了很多故障和高响应时间。
我在github回购中提供了所有示例和加载脚本– https://github.com/bijukunjummen/boot2-load-demo。
翻译自: https://www.javacodegeeks.com/2017/10/raw-performance-numbers-spring-boot-2-webflux-vs-spring-boot-1.html
