quarkus: quarkus-resteasy-reactive slower than quarkus-resteasy when returning Multi

Describe the bug

When a JAX-RS endpoint returns Multi with the quarkus-resteasy-reactive extension, the response time is unstable and sometimes much higher than with quarkus-resteasy.

Expected behavior

Stable and reasonable response time with quarkus-resteasy-reactive.

To Reproduce

https://github.com/gwenneg/quarkus-resteasy-reactive-response-time

This repo contains two subfolders which contain the exact same code. The only different file is pom.xml:

the resteasy subfolder depends on quarkus-resteasy and quarkus-resteasy-mutiny
the resteasy-reactive subfolder depends on quarkus-resteasy-reactive

Steps to reproduce the behavior:

cd resteasy-reactive
./mvnw clean quarkus:dev
Go to http://localhost:8080/test/uni and look at the response time, it should be good
Repeat a few times, the response time should be stable
Go to http://localhost:8080/test/multi and look at the response time, it may or may not be good
Repeat a few times, the response time should be unstable and sometimes really bad

If you follow the same steps with the resteasy subfolder, the response time should always be good and stable with both Uni and Multi.

Environment (please complete the following information):

Output of `java -version`

$ java -version
openjdk version "11.0.9.1" 2020-11-04

Quarkus version or git rev

1.13.3.Final

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (14 by maintainers)

Most upvoted comments

Ok, I was missing -T application/json. I updated the uni results above.

Multi:

reactive:

Summary:
  Total:        5.1124 secs
  Slowest:      0.2764 secs
  Fastest:      0.0009 secs
  Average:      0.0241 secs
  Requests/sec: 1956.0146


Response time histogram:
  0.001 [1]     |
  0.028 [8015]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.056 [744]   |■■■■
  0.084 [413]   |■■
  0.111 [295]   |■
  0.139 [196]   |■
  0.166 [123]   |■
  0.194 [86]    |
  0.221 [62]    |
  0.249 [37]    |
  0.276 [28]    |


Latency distribution:
  10% in 0.0055 secs
  25% in 0.0066 secs
  50% in 0.0077 secs
  75% in 0.0173 secs
  90% in 0.0723 secs
  95% in 0.1155 secs
  99% in 0.2075 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0001 secs, 0.0009 secs, 0.2764 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0020 secs
  req write:    0.0000 secs, 0.0000 secs, 0.0018 secs
  resp wait:    0.0237 secs, 0.0007 secs, 0.2761 secs
  resp read:    0.0002 secs, 0.0000 secs, 0.0027 secs

Status code distribution:
  [200] 10000 responses

non-reactive:

Summary:
  Total:        5.0915 secs
  Slowest:      0.0674 secs
  Fastest:      0.0015 secs
  Average:      0.0233 secs
  Requests/sec: 1964.0689

  Total data:   70000 bytes
  Size/request: 7 bytes

Response time histogram:
  0.002 [1]     |
  0.008 [951]   |■■■■■
  0.015 [79]    |
  0.021 [559]   |■■■
  0.028 [7266]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.034 [542]   |■■■
  0.041 [23]    |
  0.048 [240]   |■
  0.054 [59]    |
  0.061 [38]    |
  0.067 [242]   |■


Latency distribution:
  10% in 0.0088 secs
  25% in 0.0227 secs
  50% in 0.0231 secs
  75% in 0.0238 secs
  90% in 0.0305 secs
  95% in 0.0460 secs
  99% in 0.0623 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0000 secs, 0.0015 secs, 0.0674 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0031 secs
  req write:    0.0000 secs, 0.0000 secs, 0.0010 secs
  resp wait:    0.0232 secs, 0.0015 secs, 0.0674 secs
  resp read:    0.0000 secs, 0.0000 secs, 0.0007 secs

Status code distribution:
  [200] 10000 responses

YMMV!

famod on May 8, 2021

I’m going to close this as it does not seem to be an issue. If it is an issue, please reopen and/or comment with updated information

geoand on Aug 4, 2021

OK great, thanks 😃

FroMage on May 10, 2021

That’s exactly my point.

That unless you are really streaming data back to the client, Uni<List> is likely what you want to return

geoand on May 8, 2021