[
https://issues.apache.org/jira/browse/THRIFT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-959.
------------------------------------
Resolution: Incomplete
Assignee: James E. King III (was: Bryan Duxbury)
This was never completed, I am closing as incomplete.
> TSocket seems to do its own buffering inefficiently
> ---------------------------------------------------
>
> Key: THRIFT-959
> URL: https://issues.apache.org/jira/browse/THRIFT-959
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
> Affects Versions: 0.7
> Reporter: Bryan Duxbury
> Assignee: James E. King III
> Priority: Major
>
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
