[
https://issues.apache.org/jira/browse/THRIFT-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16732646#comment-16732646
]
James E. King III commented on THRIFT-1121:
-------------------------------------------
I can't remember which language I did it for (probably C++) but I changed one
TFramed implementation to reserve 4 bytes in the buffer so only one write() was
called, which helps to ensure this doesn't happen. It could be done for Java
too... shouldn't be that hard.
> 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
> Priority: Major
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
