Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large performance impact when using SSE in Spring Web Reactive [SPR-14944] #19511

Closed
spring-projects-issues opened this issue Nov 24, 2016 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: invalid An issue that we don't feel is valid

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 24, 2016

Daniel Fernández opened SPR-14944 and commented

Scenario

This is the scenario:

  • Web application outputting a very large sequence of items produced by a Flux<Item>
  • SSE (Accept:text/event-stream) being used.

Observed Results

When using Spring Web Reactive in a Spring Boot 2.0.0 (snapshot) application, comparing execution times between SSE and non-SSE requests for all the five server options (Jetty, Netty, RxNetty, Tomcat and Undertow), SSE requests take much more time (4x to 12x) than equivalent non-SSE requests (JSON array result).

Compare Tomcat (intro being hit during curl execution to see the data transfer flow) returning a normal JSON array:

$ curl http://localhost:8084/items/10000 > out.tomcat
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1959k    0 1959k    0     0   334k      0 --:--:--  0:00:05 --:--:--  340k
100 2421k    0 2421k    0     0   336k      0 --:--:--  0:00:07 --:--:--  340k

...and returning Server-Sent Events:

$ curl -H "Accept:text/event-stream" http://localhost:8084/items/10000 > outsse.tomcat
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  388k    0  388k    0     0  26500      0 --:--:--  0:00:15 --:--:-- 26772
100  781k    0  781k    0     0  26658      0 --:--:--  0:00:30 --:--:-- 26881
100 1173k    0 1173k    0     0  26710      0 --:--:--  0:00:45 --:--:-- 26925
100 1566k    0 1566k    0     0  26731      0 --:--:--  0:01:00 --:--:-- 26783
100 1960k    0 1960k    0     0  26764      0 --:--:--  0:01:15 --:--:-- 26894
100 2352k    0 2352k    0     0  26767      0 --:--:--  0:01:30 --:--:-- 26746
100 2746k    0 2746k    0     0  26782      0 --:--:--  0:01:45 --:--:-- 26888
100 3007k    0 3007k    0     0  26786      0 --:--:--  0:01:54 --:--:-- 26840

Example applications

Example applications: https://github.com/danielfernandez/test-spring-boot-reactive-netty-output

The above applications replicate the scenario using Spring Boot 2.0.0 apps with Jetty, Netty, RxNetty, Tomcat and Undertow. Note this application also tests other issues (specified in separate tickets).

Please have a look at the detailed test explanation at the linked repository's README


Affects: 5.0 M3

Reference URL: https://github.com/danielfernandez/test-spring-boot-reactive-netty-output

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 2, 2016

Sébastien Deleuze commented

As described in danielfernandez/test-spring-boot-reactive-netty-output#1, the SSE performance issue come from the fact that stacktrace mode is enabled by default on Spring Boot Web Reactive.

Without stacktrace mode, there is no performance issue with SSE on Tomcat:

  • Stacktrace mode enabled (current default): 1 min 57 seconds
  • Stacktrace mode disabled: 1 second with or without SSE

I have created https://github.com/bclozel/spring-boot-web-reactive/issues/53 in order to ask we disable this mode by default given the huge impact on performances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

2 participants