[
https://issues.apache.org/jira/browse/THRIFT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani reopened THRIFT-959:
-----------------------------------
This caused a big performance regression see THRIFT-1121
> 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.2, 0.3, 0.4, 0.5
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.6
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
