You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gary Madden <ga...@openet.com> on 2013/03/21 15:23:01 UTC
Performance Issue with JAXRS and Many HTTP Headers
Hello,
I've noticed a problem with CXF when using a large amount of HTTP headers. If I keep the total head size at just under 6k and start increasing the number of headers, performance starts to decrease dramatically when the header count goes above 10.
The problem area is in different parts of the code that create a new instance of org.apache.cxf.jaxrs.impl.HttpHeadersImpl to retrieve just one header value. An example of this is the getProtocolHeader method in org.apache.cxf.jaxrs.utils.HttpUtils.
HttpHeadersImpl's constructor creates a new MetadataMap for the headers. This copies all the headers into a new map. Then in getRequestHeaders of HttpHeadersImpl, the header values are again copied into a new map and this new map is then returned. Was this done for a particular reason? The reason I can think of is to prevent the original HTTP headers from being overwritten elsewhere in the code.
Has anyone else come across performance issues in relation to HTTP headers and JAXRS?
Thanks,
Gary
...........................................................................
Gary Madden
Senior Software Engineer
...........................................................................
Email: gary.madden@openet.com<ma...@openet.com>
Skype: gmadden.openet
Openet, 6 Beckett Way, Park West Business Park, Dublin 12, Ireland
________________________________
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, circulation, retention or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. If you have received this e-mail or any file or attachment transmitted with it in error please notify postmaster@openet.com. Although Openet has taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 25/03/13 18:52, Sergey Beryozkin wrote:
> Hi
> On 25/03/13 18:28, gmadden wrote:
>> Hi Sergey,
>>
>> Apologies for only getting back to you now. I thought I'd get email
>> notifications when someone replied to my mail.
>>
> No problems
>> I have made more or less the same changes that you did to HttpHeadersImpl
>> locally. I am working off cxf-2.3.3 though.
>>
> Sure, lets see, may be we can optimize it even further, just need to get
> the clarifications on my request about HttpHeaders.getRequestHeaders
>
FYI, I've updated all branches but 2.5.10-SNAPSHOT to completely avoid
copying the headers, after getting the confirmation...
Thanks again for highlighting the issue
Sergey
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 25/03/13 18:28, gmadden wrote:
> Hi Sergey,
>
> Apologies for only getting back to you now. I thought I'd get email
> notifications when someone replied to my mail.
>
No problems
> I have made more or less the same changes that you did to HttpHeadersImpl
> locally. I am working off cxf-2.3.3 though.
>
Sure, lets see, may be we can optimize it even further, just need to get
the clarifications on my request about HttpHeaders.getRequestHeaders
Thanks, Sergey
> Thanks!
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Performance-Issue-with-JAXRS-and-Many-HTTP-Headers-tp5724933p5725143.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by gmadden <ga...@openet.com>.
Hi Sergey,
Apologies for only getting back to you now. I thought I'd get email
notifications when someone replied to my mail.
I have made more or less the same changes that you did to HttpHeadersImpl
locally. I am working off cxf-2.3.3 though.
Thanks!
--
View this message in context: http://cxf.547215.n5.nabble.com/Performance-Issue-with-JAXRS-and-Many-HTTP-Headers-tp5724933p5725143.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
I've opened a spec request to clarify what
HttpHeaders.getRequestHeader(String name) should return when no header
is actually available: if it proves that 'null' needs to be returned
then we can drop this partial copy altogether, given that
HttpHeaders.getRequestHeader(String name) is a shortcut for
HttpHeaders.getRequestHeaders().get(name), otherwise, if the empty list
is returned, we do need to filter the header values to make sure these
two calls produce the consistent output
I'll keep you up to date
Sergey
On 22/03/13 16:42, Sergey Beryozkin wrote:
> Hi
>
> On 21/03/13 20:31, Sergey Beryozkin wrote:
>> Hi
>> On 21/03/13 14:23, Gary Madden wrote:
>>> Hello,
>>>
>>> I've noticed a problem with CXF when using a large amount of HTTP
>>> headers. If I keep the total head size at just under 6k and start
>>> increasing the number of headers, performance starts to decrease
>>> dramatically when the header count goes above 10.
>>>
>>> The problem area is in different parts of the code that create a new
>>> instance of org.apache.cxf.jaxrs.impl.HttpHeadersImpl to retrieve just
>>> one header value. An example of this is the getProtocolHeader method
>>> in org.apache.cxf.jaxrs.utils.HttpUtils.
>>>
>>> HttpHeadersImpl's constructor creates a new MetadataMap for the
>>> headers. This copies all the headers into a new map.
>>
>> The representation of the headers on the CXF Message can not be used as
>> a response from HttpHeaders,
>>
>>> Then in getRequestHeaders of HttpHeadersImpl, the header values are
>>> again copied into a new map and this new map is then returned. Was
>>> this done for a particular reason? The reason I can think of is to
>>> prevent the original HTTP headers from being overwritten elsewhere in
>>> the code.
>>>
>> Quite possibly, I'll have to review
>>> Has anyone else come across performance issues in relation to HTTP
>>> headers and JAXRS?
>>>
>> The original HttpHeardesImpl code is old enough - thanks for reporting
>> the issue - I'll deal with it. JAX-RS implementation in CXF 2.8.0 in
>> particular has 'seen' quote a few performance related updates already, a
>> number of related changes are due too, now including the HttpHeadersImpl
>> enhancements.
>>
>> I'll update you on this thread
>
> I've done some work to optimize it a bit, see [1] & [2].
> Effectively, in most cases, the original message headers will be copied
> only once but without coying the individual list values of the
> individual headers. This 'partial' copy can be avoided in principle too,
> but we have to check if header values are not null.
>
> Can you please retry in the few days ? FYI, the update was not merged to
> 2.5.x only, let me know if you need it there.
>
> Also, if you can see the opportunity to optimize it even further - let
> me know please too
>
> Cheers, Sergey
>
>
> [1] https://issues.apache.org/jira/browse/CXF-4915
> [2] http://svn.apache.org/r1459855
>>
>> Cheers, Sergey
>>
>>> Thanks,
>>>
>>> Gary
>>>
>>> ...........................................................................
>>>
>>>
>>> Gary Madden
>>> Senior Software Engineer
>>> ...........................................................................
>>>
>>>
>>> Email: gary.madden@openet.com<ma...@openet.com>
>>> Skype: gmadden.openet
>>> Openet, 6 Beckett Way, Park West Business Park, Dublin 12, Ireland
>>>
>>>
>>> ________________________________
>>> This email and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom they
>>> are addressed. If you are not the intended recipient, please note that
>>> any review, dissemination, disclosure, alteration, printing,
>>> circulation, retention or transmission of this e-mail and/or any file
>>> or attachment transmitted with it, is prohibited and may be unlawful.
>>> If you have received this e-mail or any file or attachment transmitted
>>> with it in error please notify postmaster@openet.com. Although Openet
>>> has taken reasonable precautions to ensure no viruses are present in
>>> this email, we cannot accept responsibility for any loss or damage
>>> arising from the use of this email or attachments.
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 21/03/13 20:31, Sergey Beryozkin wrote:
> Hi
> On 21/03/13 14:23, Gary Madden wrote:
>> Hello,
>>
>> I've noticed a problem with CXF when using a large amount of HTTP
>> headers. If I keep the total head size at just under 6k and start
>> increasing the number of headers, performance starts to decrease
>> dramatically when the header count goes above 10.
>>
>> The problem area is in different parts of the code that create a new
>> instance of org.apache.cxf.jaxrs.impl.HttpHeadersImpl to retrieve just
>> one header value. An example of this is the getProtocolHeader method
>> in org.apache.cxf.jaxrs.utils.HttpUtils.
>>
>> HttpHeadersImpl's constructor creates a new MetadataMap for the
>> headers. This copies all the headers into a new map.
>
> The representation of the headers on the CXF Message can not be used as
> a response from HttpHeaders,
>
>> Then in getRequestHeaders of HttpHeadersImpl, the header values are
>> again copied into a new map and this new map is then returned. Was
>> this done for a particular reason? The reason I can think of is to
>> prevent the original HTTP headers from being overwritten elsewhere in
>> the code.
>>
> Quite possibly, I'll have to review
>> Has anyone else come across performance issues in relation to HTTP
>> headers and JAXRS?
>>
> The original HttpHeardesImpl code is old enough - thanks for reporting
> the issue - I'll deal with it. JAX-RS implementation in CXF 2.8.0 in
> particular has 'seen' quote a few performance related updates already, a
> number of related changes are due too, now including the HttpHeadersImpl
> enhancements.
>
> I'll update you on this thread
I've done some work to optimize it a bit, see [1] & [2].
Effectively, in most cases, the original message headers will be copied
only once but without coying the individual list values of the
individual headers. This 'partial' copy can be avoided in principle too,
but we have to check if header values are not null.
Can you please retry in the few days ? FYI, the update was not merged to
2.5.x only, let me know if you need it there.
Also, if you can see the opportunity to optimize it even further - let
me know please too
Cheers, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4915
[2] http://svn.apache.org/r1459855
>
> Cheers, Sergey
>
>> Thanks,
>>
>> Gary
>>
>> ...........................................................................
>>
>> Gary Madden
>> Senior Software Engineer
>> ...........................................................................
>>
>> Email: gary.madden@openet.com<ma...@openet.com>
>> Skype: gmadden.openet
>> Openet, 6 Beckett Way, Park West Business Park, Dublin 12, Ireland
>>
>>
>> ________________________________
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. If you are not the intended recipient, please note that
>> any review, dissemination, disclosure, alteration, printing,
>> circulation, retention or transmission of this e-mail and/or any file
>> or attachment transmitted with it, is prohibited and may be unlawful.
>> If you have received this e-mail or any file or attachment transmitted
>> with it in error please notify postmaster@openet.com. Although Openet
>> has taken reasonable precautions to ensure no viruses are present in
>> this email, we cannot accept responsibility for any loss or damage
>> arising from the use of this email or attachments.
>>
>
>
Re: Performance Issue with JAXRS and Many HTTP Headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 21/03/13 14:23, Gary Madden wrote:
> Hello,
>
> I've noticed a problem with CXF when using a large amount of HTTP headers. If I keep the total head size at just under 6k and start increasing the number of headers, performance starts to decrease dramatically when the header count goes above 10.
>
> The problem area is in different parts of the code that create a new instance of org.apache.cxf.jaxrs.impl.HttpHeadersImpl to retrieve just one header value. An example of this is the getProtocolHeader method in org.apache.cxf.jaxrs.utils.HttpUtils.
>
> HttpHeadersImpl's constructor creates a new MetadataMap for the headers. This copies all the headers into a new map.
The representation of the headers on the CXF Message can not be used as
a response from HttpHeaders,
> Then in getRequestHeaders of HttpHeadersImpl, the header values are again copied into a new map and this new map is then returned. Was this done for a particular reason? The reason I can think of is to prevent the original HTTP headers from being overwritten elsewhere in the code.
>
Quite possibly, I'll have to review
> Has anyone else come across performance issues in relation to HTTP headers and JAXRS?
>
The original HttpHeardesImpl code is old enough - thanks for reporting
the issue - I'll deal with it. JAX-RS implementation in CXF 2.8.0 in
particular has 'seen' quote a few performance related updates already, a
number of related changes are due too, now including the HttpHeadersImpl
enhancements.
I'll update you on this thread
Cheers, Sergey
> Thanks,
>
> Gary
>
> ...........................................................................
> Gary Madden
> Senior Software Engineer
> ...........................................................................
> Email: gary.madden@openet.com<ma...@openet.com>
> Skype: gmadden.openet
> Openet, 6 Beckett Way, Park West Business Park, Dublin 12, Ireland
>
>
> ________________________________
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, circulation, retention or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. If you have received this e-mail or any file or attachment transmitted with it in error please notify postmaster@openet.com. Although Openet has taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>