----- 原始邮件 ----- 发件人: Daniel Kulp <[EMAIL PROTECTED]> 发送时间: 2008年8月19日 星期二 20:19 收件人: users@cxf.apache.org 抄送: David Soroko <[EMAIL PROTECTED]> 主题: Re: Just what is 'AllowChunking'?
On Tuesday 19 August 2008 5:08:40 am David Soroko wrote: > So "performance reasons" is running out of memory and "20-30%" is the > amount of memory saved by allowing HTTP chunking? No, it's not just that. In chunking mode, you can "stream" data as it's being generated. For example, let's assume you have a very big JAXB object tree, maybe with a list of 1000 "part" objects. In chunking mode, as JAXB starts writing the list, the first chunks can be sent off to the server to have it start processing them before the last part of the list is even looked at. Thus, the server gets to start processing it before the client has even sent the whole thing. The client and server get to work kind of in parallel. As the client generates data, it can send it and the server can start using it. In non-chunking mode, the whole things gets bufferred up and sent in one block. Thus, the server does nothing until the client is done, then the client does nothing while the server does it's thing, etc.... I think the default chunk size is 2K or 4K depending on the VM. That is partially why messages under 4K don't really help with chunking. It would only be one chunk anyway. Dan > > -- david > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of nicolas de loof > Sent: 19 August 2008 09:42 > To: users@cxf.apache.org > Subject: Re: Just what is 'AllowChunking'? > > AFAIK chunking is used to avoid the pre-computation of message size to > set > the "content-length" header. > > On "traditional" HTTP, content-length is used to ensure the full body > has > been received on the server. But this requires the client to fully > create > the request message in memory. This can have impact on client that needs > to > send large messages (more than 4k according to CXF behaviour) > > The chunk mode allows to just send "more bytes to come" to the server, > and > use small buffers on the client. The server knows it got all the body > when > the chunk is set to 0. > > Nicolas > > 2008/8/19 David Soroko <[EMAIL PROTECTED]> > > > Could you provide more details regarding the "performance reasons" and > > why they are not relevant for messages smaller then 4k? > > > > thanks > > > > -- david > > > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: 18 August 2008 19:14 > > To: users@cxf.apache.org > > Subject: Re: Just what is 'AllowChunking'? > > > > On Monday 18 August 2008 1:10:03 pm AmaDaden wrote: > > > Glen Mazza wrote: > > > > chunking needs to be manually turned off in those cases. > > > > > > That seems a bit odd. Shouldn't the default settings be designed to > > > > work > > > > > with the least issues? Why is chunking on by default? > > > > For performance reasons..... Turning chunking off can reduce > > performance by > > 20-30% for messages larger than about 4K. It also severely increased > > memory > > usage causing all kinds of scalability problems. > > > > CXF 2.1.2 (releasing today once it synced everywhere), changes things > > a > > > little > > bit. For messages 4K and smaller, it doesn't use chunking. Once > > the > > > message hits 4K, it flips to chunking mode (unless turned off). > > > > > > -- > > Daniel Kulp > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > ________________________________________________________________________ > > > In order to protect our email recipients, Betfair Group use SkyScan > > from > > > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
