[
https://issues.apache.org/jira/browse/CXF-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Soldano updated CXF-5891:
---------------------------------
Description:
It has been noticed by running some benchmarks that CXF performances could
possibly be improved when dealing of SOAP messages with no SOAP headers. The
ReadHeadersInterceptor builds a DOM Document for each SOAP message; while
that's fine if there actually are headers in the message, it looks like a waste
of time and memory if the message has no header. The document has big memory
footprint, which ends up in high heap memory pressure when running our
benchmarks. The final result is performance penalty.
I've been reasoning on a solution for starting parsing the message with StAX
(envelope and header part only, as per the PartialXMLStreamReader already in
place), buffering the stream events and optionally generating the DOM doc if a
soap header is actually found.
The initial patch is attached; some local tests show that the patched
ReadHeadersInterceptor performance (processing time) is ~*16%* better than the
current one for messages with no headers and ~*3%* worse for messages with 2
not trivial headers.
Ideally, we could switch this patched processing method by default and give the
user a mean for disabling it (prop in the message/exchange ?). Moreover, we
could automatically disable it whenever WS-* interceptors are installed in the
chain (as WS-Security, WS-Addressing, WS-RM, etc. all imply headers being added
to the messages).
In terms of memory allocation, the patched version is dramatically better for
messages with no headers.
was:
It has been noticed by running some benchmarks that CXF performances could
possibly be improved for dealing of SOAP messages with no SOAP headers. The
ReadHeadersInterceptor builds a DOM Document for each SOAP message; while
that's fine if there actually are headers in the message, it looks like a waste
of time and memory if the message has no header. The document has big memory
footprint, which ends up in high heap memory pressure when running our
benchmarks. The final result is performance penalty.
I've been reasoning on a solution for starting parsing the message with StAX
(envelope and header part only, as per the PartialXMLStreamReader already in
place), buffering the stream events and optionally generating the DOM doc if a
soap header is actually found.
The initial patch is attached, some local tests show that the
ReadHeadersInterceptor performance (processing time) is ~*16%* better for
messages with no headers and ~*3%* worse for messages with 2 not trivial
headers.
Ideally, we could switch this patched processing method by default and give the
user a mean for disabling it (prop in the message/exchange ?). Moreover, we
could automatically disable it whenever WS-* interceptors are installed in the
chain (as WS-Security, WS-Addressing, WS-RM, etc. all imply headers being added
to the messages).
In terms of memory allocation, the patched version is dramatically better for
messages with no headers.
> ReadHeadersInterceptor performances improvement
> -----------------------------------------------
>
> Key: CXF-5891
> URL: https://issues.apache.org/jira/browse/CXF-5891
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
> Reporter: Alessio Soldano
> Attachments: headers-perf.diff
>
>
> It has been noticed by running some benchmarks that CXF performances could
> possibly be improved when dealing of SOAP messages with no SOAP headers. The
> ReadHeadersInterceptor builds a DOM Document for each SOAP message; while
> that's fine if there actually are headers in the message, it looks like a
> waste of time and memory if the message has no header. The document has big
> memory footprint, which ends up in high heap memory pressure when running our
> benchmarks. The final result is performance penalty.
> I've been reasoning on a solution for starting parsing the message with StAX
> (envelope and header part only, as per the PartialXMLStreamReader already in
> place), buffering the stream events and optionally generating the DOM doc if
> a soap header is actually found.
> The initial patch is attached; some local tests show that the patched
> ReadHeadersInterceptor performance (processing time) is ~*16%* better than
> the current one for messages with no headers and ~*3%* worse for messages
> with 2 not trivial headers.
> Ideally, we could switch this patched processing method by default and give
> the user a mean for disabling it (prop in the message/exchange ?). Moreover,
> we could automatically disable it whenever WS-* interceptors are installed in
> the chain (as WS-Security, WS-Addressing, WS-RM, etc. all imply headers being
> added to the messages).
> In terms of memory allocation, the patched version is dramatically better for
> messages with no headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
