[THRIFT-959] TSocket seems to do its own buffering inefficiently

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Incomplete
• Affects Version/s: 0.7
• Component/s: Java - Library
• Assignee: James E. King III
• Reporter: Bryan Duxbury
• Created: 15/Oct/10 21:13
• Updated: 03/Jan/19 04:32
• Resolved: 03/Jan/19 04:29

Description

I was looking through TSocket today while reviewing THRIFT-106 and I noticed that in TSocket, when we open the socket/stream, we wrap the input/output streams with Buffered(Input|Output)Stream objects and use those for reading and writing.

Two things stand out about this. Firstly, for some reason we're setting the buffer size specifically to 1KB, which is 1/8 the default. I think that number should be at least 8KB and more likely something like 32KB would be better. Anyone have any idea why we chose this size? Secondly, though, is the fact that we probably shouldn't be doing buffering here at all. The general pattern is to open a TSocket and wrap it in a TFramedTransport, which means that today, even though we're fully buffering in the framed transport, we're wastefully buffering again in the TSocket. This means we're wasting time and memory, and I wouldn't be surprised if this is artificially slowing down throughput, specifically for multi-KB requests and responses.

If we remove the buffering from TSocket, I think we will probably need to add a TBufferedTransport to support users who are talking to non-Framed servers but still need buffering for performance.

Issue Links

• breaks: THRIFT-1121 Java server performance regression in 0.6
• is related to: THRIFT-4714 Java TFramedTransport calls write twice for each flush