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@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
