generated from quarkiverse/quarkiverse-template
-
Notifications
You must be signed in to change notification settings - Fork 61
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 responses written slowly due to allocating too small buffers #1066
Comments
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 10, 2023
ppalaga
changed the title
Slow Performance of CXF Extension
Large responses written slowly
Nov 13, 2023
ppalaga
changed the title
Large responses written slowly
Large responses written slowly due to allocating too small buffers
Nov 13, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 13, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 13, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 14, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 16, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 16, 2023
ppalaga
added a commit
that referenced
this issue
Nov 16, 2023
ppalaga
added a commit
to ppalaga/quarkus-cxf
that referenced
this issue
Nov 22, 2023
ppalaga
added a commit
that referenced
this issue
Nov 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Note by @ppalaga 2023-11-23: This issue is only observable when sending a chunked response large enough to surpass the default buffer size used in
VertxServletOutputStream
to a HTTP/1.1 client. (Note that there is noTransfer-Encoding: chunked
in HTTP/2.)I have found evidence of slow performance of Quarkus CXF extension.
In a nutshell, a single invocation of a SOAP endpoint takes about 10 seconds to return a response. The performance further degrades when concurrent calls are made.
From my initial analysis, I can see that the main Thread that replies to your request interacts with Saxon parsing library for most of the time, until the stream of data is returned to the customer:
I'm attaching a reproducer for the endpoint available at: http://localhost:8080/foo/ReferenceData?wsdl
Here is a sample SOAP request you can use for a test:
The text was updated successfully, but these errors were encountered: