tomcat-users mailing list archives

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

"David kerber" <dckerber@verizon.net> wrote in message 
news:4A0DBF88.6030208@verizon.net...
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message