[jira] [Resolved] (THRIFT-1121) Java server performance regression in 0.6

["Bryan Duxbury (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury resolved THRIFT-1121.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.8

OK, I reverted THRIFT-959 in trunk.
                
> Java server performance regression in 0.6
> -----------------------------------------
>
>                 Key: THRIFT-1121
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1121
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.6
>            Reporter: Todd Lipcon
>            Assignee: Bryan Duxbury
>             Fix For: 0.8
>
>
> A user reports a 30% performance regression after upgrading some high-request-rate Java software from Thrift 0.3 to 0.6. After some inspection, it turns out that the changes for THRIFT-959 caused the slowdown. However, even after altering the code to use the TFramedTransport, performance was still only 80% of version 0.3.  I believe the problem is that the TFramedTransport must read the length (unbuffered) before reading (only) one message. In one particular workload, sent with oneway streaming, the server is making many more system calls.
> It wasn't obvious how to compose a Transport that would add back the buffering using existing components.  We created our own trivial TServerSocket that adds the socket buffering back.  Performance is now back where it was with 0.3.

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