tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Performance on socket reads
Date Sun, 17 May 2009 00:15:30 GMT

"David kerber" <> wrote in message
> Christopher Schultz wrote:
>> Hash: SHA1
>> David,
>> On 5/15/2009 12:22 PM, David kerber wrote:
>>> But the code works; it just seems to be a little slow.
>> Gotcha. How slow are we talking, here? I'm not sure whether the
>> underlying InputStream, here, is buffering, but you could try:
> Not noticeably slow from a human watching it viewpoint, but when I do a 
> thread dump, I see quite a few of the threads waiting on the .read() 
> statement.  "quite a few" in the case of the one I did just now (the 
> busiest time of day for this app) means 12 out of the total of 75 
> http-processorXXX threads.
>> iStream = new BufferedInputStream(req.getInputStream());
>> ... to see if that improves things at all.
> I was wondering about that, too.  I couldn't see anything that 
> specifically said whether the InputStream from an HttpServletRequest was 
> buffered or not, but the implication from some reading about a 3rd party 
> BufferedServletInputStream is that TC 4.x and later provide a buffer for 
> it.

Yes, the TC implementation of the ImputStream from the Request is buffered 
(although it doesn't extend BufferedInputStream).  It is possible that 
wrapping it in a BufferedInputStream could even slow the app down (by making 
it wait until all the data is available).

>>> At this point, [the data is] still encrypted, and a string may not 
>>> properly
>>> handle some of the bytes.
>> Oh, right. I forgot you were sending encrypted data.
>>>> I think you may have better luck reading until there is no more input,
>>> What method would you suggest?  Create the byte array long enough to
>>> handle any possible input and then read without specifying the length?
>> Something like that. After thinking a bit about it, specifying more
>> bytes to read than are available either blocks (waiting for more data
>> that will come) or returns after reading fewer bytes (because the stream
>> is closed and there's no more to read). Your code should be pretty good
>> as-is.
> Thanks,
> D 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message