[THRIFT-1121] Java server performance regression in 0.6

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.6
• Fix Version/s: 0.8
• Component/s: Java - Library
• Assignee: Bryan Duxbury
• Reporter: Todd Lipcon
• Created: 28/Mar/11 18:06
• Updated: 03/Jan/19 04:32
• Resolved: 27/Sep/11 17:08

Description

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.

Issue Links

• is broken by: THRIFT-959 TSocket seems to do its own buffering inefficiently
• is related to: THRIFT-4714 Java TFramedTransport calls write twice for each flush