Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.215.180 as permitted sender)
Message-ID: <514C8A0B.7080707@gmail.com>
Date: Fri, 22 Mar 2013 16:42:51 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Performance Issue with JAXRS and Many HTTP Headers
References: 
 <53CF299802A281409CB89D5E3DDC4AF70A6525587A@DUBEXCH01.openet-dublin>
 <514B6E08.2010802@gmail.com>
In-Reply-To: <514B6E08.2010802@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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<mailto:gary.madden@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.
>>
>
>