tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Hagen" <>
Subject Re: Re: Performance problem on HTTP PUT of large binary data
Date Thu, 26 Jul 2007 08:18:19 GMT
Hi Christopher,

thank you for your reply.

From: Christopher Schultz<>
> Daniel Hagen wrote:
> > I am currently developing an application that handles uploads of big 
> > files using HTTP PUT.
> > The client is a Java client writing 32K blocks to the server using
> > chunked streaming mode with 32K chunk size.
> > 
> > On performance tests I noticed the CPU load of the server going up to
> > 100% and remaining there during the complete upload. I did some
> > further profiling and finally got one (in my eyes) very propable
> > candidate: The read(byte[]) methods of the (Coyote)InputStream return
> > only blocks of ~1000 to ~7500 bytes resulting in an excessive amount
> > of calls to the aforementioned methods in the process.
> It looks like you are using non-buffered streams. Have you tried using
> BufferedInputStream?

Yes, I am (forgot to mention that)

> That might allow more bytes to pile up before the
> bytes are actually returned. Simply using a 32k byte array doesn't
> really set any chunking size when reading.

That is clear to me - that is why I hoped that some of the Tomcat HTTP Connector socket settings
could help with that...

> To me, that's a little vague. It only says that it will block until data
> is available... it doesn't say how much is required for a successful
> return. I suspect that it will return immediately when any amount of
> data is available.

That is also my guess since the available() method on socket input streams always returns
0 as far as I know.

> I suspect that your server is fast enough to be able to steal small
> amounts of data from the TCP stack each time, rather than actually
> getting 32k all at once. Since you aren't buffering your input, you are
> getting small bytes (ha!) of data instead of large ones.

May be, may be not - I do not think execution speed (and thus the intervall between the reading)
is an issue here since even putting an "aritificial" delay between reads does not have any
effect on the size of the filled buffer.

Best regards


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message