Dear All,

I am currently developing an application that handles uploads of big files using HTTP PUT.
The I/O part of the server application can be broken down to (not literally spoken, just to make the working clear):

public void doPut(HttpServletRequest request, HttpServletResponse response)
{
  InputStream in = request.getInputStream();
  OutputStream out = new FileOutputStream("some_file");
  [Transfer data between streams using a 32K buffer]
}

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.
(Windows & Linux alike, same behavior when accessing localhost or on access over network, c++ libcurl client produces the same pattern).
The delay between the calls also does not seem to matter since the blocks to not get larger even with a 1 second or larger delay between the calls to InputStream.read(byte[]).

I also noticed a funny pattern in the number of bytes read, there seems to be a fixed maximum of ~7000 bytes (windows) and a similar but not equal number (~7700) on linux.

I tested with Tomcat 6.0.13 accessing the Tomcat HTTP connector directly, the connector was configured with:
[...]
        socket.appReadBufSize="32678"
        socket.appWriteBufferSize="32768"
        socket.rxBufSize="32678"

(BTW, Tomcat 5.5 behavior is the same)

So finally my question:

Do you have any idea what could cause the described behavior and prevent the server from returning larger buffers?
Any parameters I could check/tweek to overcome that problem?

Thank you!

Daniel


---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)