tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <>
Subject Re: Performance on socket reads
Date Fri, 15 May 2009 19:16:24 GMT
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.

>> 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.


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

View raw message