[ 
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

        

Reply via email to