You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Geoff Soutter <ge...@whitewolf.com.au> on 2000/08/15 05:40:38 UTC
file uploads 6x slower than JSDK!
Hi there
Just been doing some profiling of Tomcat vs JSDK2.0 for file uploads
Turns out that file upload code that calls ServletInputStream.readLine(), eg
Jason Hunters file upload code, is around 6 times slower under Tomcat
(standalone) than it is under JSDK2.0, well at least according to
OptimizeIt. Yuck!
Looking into it a bit, I discovered than SIS.readLine() ends up calling
read() for single bytes one after the other till it finds the end of line
chars. The OptimizeIt profile of SIS.readLine under Tomcat looked like so:
76.96 % - 220859.056 ms - 38 inv. -
javax.servlet.ServletInputStream.readLine()
69.03 % - 198113.475 ms - 2359398 inv. -
org.apache.tomcat.core.BufferedServletInputStream.read()
52.81 % - 151556.038 ms - 2359398 inv. -
org.apache.tomcat.core.BufferedServletInputStream.doRead()
38.93 % - 111741.727 ms - 2359398 inv. -
org.apache.tomcat.service.http.HttpRequestAdapter.doRead()
24.05 % - 69036.059 ms - 2359398 inv. - java.io.BufferedInputStream.read()
8.06 % - 23141.747 ms - 2359398 inv. -
java.io.BufferedInputStream.ensureOpen()
0.13 % - 376.099 ms - 1438 inv. - java.io.BufferedInputStream.fill()
0.11 % - 337.282 ms - 1438 inv. - java.net.SocketInputStream.read()
0.1 % - 299.693 ms - 1438 inv. - java.net.SocketInputStream.socketRead()
If you're used to reading OptimizeIt output, you can see that I uploaded a
2.3MB file, and that it spent %76 percent of the total file upload time
within the SIS.readLine() method.
Now compare this to the JSDK2.0 trace for the same 2.3 MB file:
4.45 % - 1927.818 ms - 38 inv. - sun.servlet.http.HttpInputStream.readLine()
2.22 % - 963.361 ms - 4900 inv. - sun.servlet.http.HttpInputStream.fill()
1.86 % - 805.48 ms - 4900 inv. - java.net.SocketInputStream.read()
1.66 % - 719.908 ms - 4900 inv. - java.net.SocketInputStream.socketRead()
Here, it only spent 4.45% of the total file upload time performing the same
function. Note that JSDK2.0 actually subclasses ServletInputStream (with
HttpInputStream) to override it's very slow implementation of readLine() -
it avoids single byte reads and also seemingly avoids the need for the
BufferedInputStream. Maybe thats something that Tomcat ought to do to?
Any comments?
Cheers
Geoff
Re: file uploads 6x slower than JSDK!
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
Hi Costin,
"Costin Manolache" <cm...@yahoo.com> wrote:
> If you have any idea for optimizations please send patches.
> You can use a Buffer ( or just avoid using readLine), but
> tomcat should do all that ( and recycle the buffers as
> much as possible, etc).
I'll see if I get some time, I'm a bit busy at the moment (as always)
As for ideas, all we need to do is find the source code for JSDK2.0
HttpInputStream and port it across into Tomcat ! ;-)
cheers
Geoff
>
> Costin
>
>
> Geoff Soutter wrote:
>
> > Hi there
> >
> > Just been doing some profiling of Tomcat vs JSDK2.0 for file uploads
> >
> > Turns out that file upload code that calls
ServletInputStream.readLine(), eg
> > Jason Hunters file upload code, is around 6 times slower under Tomcat
> > (standalone) than it is under JSDK2.0, well at least according to
> > OptimizeIt. Yuck!
> >
> > Looking into it a bit, I discovered than SIS.readLine() ends up calling
> > read() for single bytes one after the other till it finds the end of
line
> > chars. The OptimizeIt profile of SIS.readLine under Tomcat looked like
so:
> >
> > 76.96 % - 220859.056 ms - 38 inv. -
> > javax.servlet.ServletInputStream.readLine()
> > 69.03 % - 198113.475 ms - 2359398 inv. -
> > org.apache.tomcat.core.BufferedServletInputStream.read()
> > 52.81 % - 151556.038 ms - 2359398 inv. -
> > org.apache.tomcat.core.BufferedServletInputStream.doRead()
> > 38.93 % - 111741.727 ms - 2359398 inv. -
> > org.apache.tomcat.service.http.HttpRequestAdapter.doRead()
> > 24.05 % - 69036.059 ms - 2359398 inv. -
java.io.BufferedInputStream.read()
> > 8.06 % - 23141.747 ms - 2359398 inv. -
> > java.io.BufferedInputStream.ensureOpen()
> > 0.13 % - 376.099 ms - 1438 inv. - java.io.BufferedInputStream.fill()
> > 0.11 % - 337.282 ms - 1438 inv. - java.net.SocketInputStream.read()
> > 0.1 % - 299.693 ms - 1438 inv. - java.net.SocketInputStream.socketRead()
> >
> > If you're used to reading OptimizeIt output, you can see that I uploaded
a
> > 2.3MB file, and that it spent %76 percent of the total file upload time
> > within the SIS.readLine() method.
> >
> > Now compare this to the JSDK2.0 trace for the same 2.3 MB file:
> >
> > 4.45 % - 1927.818 ms - 38 inv. -
sun.servlet.http.HttpInputStream.readLine()
> > 2.22 % - 963.361 ms - 4900 inv. -
sun.servlet.http.HttpInputStream.fill()
> > 1.86 % - 805.48 ms - 4900 inv. - java.net.SocketInputStream.read()
> > 1.66 % - 719.908 ms - 4900 inv. -
java.net.SocketInputStream.socketRead()
> >
> > Here, it only spent 4.45% of the total file upload time performing the
same
> > function. Note that JSDK2.0 actually subclasses ServletInputStream (with
> > HttpInputStream) to override it's very slow implementation of
readLine() -
> > it avoids single byte reads and also seemingly avoids the need for the
> > BufferedInputStream. Maybe thats something that Tomcat ought to do to?
> >
> > Any comments?
> >
> > Cheers
> >
> > Geoff
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: file uploads 6x slower than JSDK!
Posted by Costin Manolache <cm...@yahoo.com>.
Hi Geoff,
Yes, I know about this - so far I focused more on the output
side.
If you have any idea for optimizations please send patches.
You can use a Buffer ( or just avoid using readLine), but
tomcat should do all that ( and recycle the buffers as
much as possible, etc).
Costin
Geoff Soutter wrote:
> Hi there
>
> Just been doing some profiling of Tomcat vs JSDK2.0 for file uploads
>
> Turns out that file upload code that calls ServletInputStream.readLine(), eg
> Jason Hunters file upload code, is around 6 times slower under Tomcat
> (standalone) than it is under JSDK2.0, well at least according to
> OptimizeIt. Yuck!
>
> Looking into it a bit, I discovered than SIS.readLine() ends up calling
> read() for single bytes one after the other till it finds the end of line
> chars. The OptimizeIt profile of SIS.readLine under Tomcat looked like so:
>
> 76.96 % - 220859.056 ms - 38 inv. -
> javax.servlet.ServletInputStream.readLine()
> 69.03 % - 198113.475 ms - 2359398 inv. -
> org.apache.tomcat.core.BufferedServletInputStream.read()
> 52.81 % - 151556.038 ms - 2359398 inv. -
> org.apache.tomcat.core.BufferedServletInputStream.doRead()
> 38.93 % - 111741.727 ms - 2359398 inv. -
> org.apache.tomcat.service.http.HttpRequestAdapter.doRead()
> 24.05 % - 69036.059 ms - 2359398 inv. - java.io.BufferedInputStream.read()
> 8.06 % - 23141.747 ms - 2359398 inv. -
> java.io.BufferedInputStream.ensureOpen()
> 0.13 % - 376.099 ms - 1438 inv. - java.io.BufferedInputStream.fill()
> 0.11 % - 337.282 ms - 1438 inv. - java.net.SocketInputStream.read()
> 0.1 % - 299.693 ms - 1438 inv. - java.net.SocketInputStream.socketRead()
>
> If you're used to reading OptimizeIt output, you can see that I uploaded a
> 2.3MB file, and that it spent %76 percent of the total file upload time
> within the SIS.readLine() method.
>
> Now compare this to the JSDK2.0 trace for the same 2.3 MB file:
>
> 4.45 % - 1927.818 ms - 38 inv. - sun.servlet.http.HttpInputStream.readLine()
> 2.22 % - 963.361 ms - 4900 inv. - sun.servlet.http.HttpInputStream.fill()
> 1.86 % - 805.48 ms - 4900 inv. - java.net.SocketInputStream.read()
> 1.66 % - 719.908 ms - 4900 inv. - java.net.SocketInputStream.socketRead()
>
> Here, it only spent 4.45% of the total file upload time performing the same
> function. Note that JSDK2.0 actually subclasses ServletInputStream (with
> HttpInputStream) to override it's very slow implementation of readLine() -
> it avoids single byte reads and also seemingly avoids the need for the
> BufferedInputStream. Maybe thats something that Tomcat ought to do to?
>
> Any comments?
>
> Cheers
>
> Geoff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org