[
https://issues.apache.org/jira/browse/THRIFT-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047432#comment-13047432
]
Steve Jiang commented on THRIFT-1167:
-------------------------------------
For long-lived connections the approaches are equivalent, as the assignment of
a connection to a thread happens only at accept time in both cases. If you
want to rebalance per-request, it'd obviously be a tradeoff.
As to performance, I'm speaking from experience in non-JVM environments. Do
you time to do a benchmark? I'm a bit busy right now so it'd take a few days
for me to get to it.
> Java nonblocking server with more than one thread for select and handling IO
> ----------------------------------------------------------------------------
>
> Key: THRIFT-1167
> URL: https://issues.apache.org/jira/browse/THRIFT-1167
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
> Reporter: Steve Jiang
> Assignee: Bryan Duxbury
> Attachments: TSHSHAServer-Patch-MultiThreaded_v3.patch,
> threadedselectorthrift3.diff
>
>
> I've used the HsHa server model to write a server that uses a thread for
> accept and a separate, configurable number of Selector threads to handle IO.
> I'd like to contribute this back to Thrift.
> For apps that are RPC-heavy and require little computation from the executor
> pool running on multi-core architectures, this server allows gets throughput
> as IO is not limited by one CPU.
> Please take a look at the attached patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
