You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2011/03/28 20:06:05 UTC
[jira] [Created] (THRIFT-1121) Java server performance regression
in 0.6
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1121) Java server performance regression
in 0.6
Posted by "Todd Lipcon (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115808#comment-13115808 ]
Todd Lipcon commented on THRIFT-1121:
-------------------------------------
I don't have any test case - the regression showed up in large scale performance tests of a distributed system. Just forwarding along some results for some folks who, at the time, were not permitted to participate in the JIRA.
> 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
[jira] [Assigned] (THRIFT-1121) Java server performance regression
in 0.6
Posted by "T Jake Luciani (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
T Jake Luciani reassigned THRIFT-1121:
--------------------------------------
Assignee: Bryan Duxbury
Bryan can you revert THRIFT-959? We noticed the same slowdown
> 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
>
> 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
[jira] [Resolved] (THRIFT-1121) Java server performance regression
in 0.6
Posted by "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
[jira] [Commented] (THRIFT-1121) Java server performance regression
in 0.6
Posted by "Jake Farrell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115495#comment-13115495 ]
Jake Farrell commented on THRIFT-1121:
--------------------------------------
Todd, do you have a test case you can attach which shows the issue and how you where able to resolve it
> 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
>
> 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