[jira] [Commented] (THRIFT-5419) Incorrect usage of thread pool in TThreadPoolAsyncServer leads to extreme poor performance

["Jens Geyer (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349724#comment-17349724 ] 

Jens Geyer commented on THRIFT-5419:
------------------------------------

*recommended action*
https://thrift.apache.org/docs/HowToContribute.html

Thanks for the analysis,pull request  appreciated 

> Incorrect usage of thread pool in TThreadPoolAsyncServer leads to extreme poor performance
> ------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-5419
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5419
>             Project: Thrift
>          Issue Type: Bug
>          Components: netstd - Library
>    Affects Versions: 0.14.1
>         Environment: Windows 10 with Visual Studio 2019.
>            Reporter: Nathan P Sharp
>            Priority: Major
>
> *Abstract:*
> TThreadPoolAsyncServer uses ThreadPool.QueueUserWorkItem for each incoming connection to post a long-lived, synchronous task to the thread pool. This causes deadlock in the thread pool, which is only designed for short lived tasks, and can cause dramatic poor performance throughout your application, even in unrelated areas.
> *Details:*
> The .NET Thread Pool is not designed to handle long lived tasks. It has a complex set of logic that starts the pool at a size based on available CPUs and memory, then automatically grows it if it detects deadlock (no tasks completed for a second). Let's say that number is 4, as soon as you have 4 concurrent connections, everything in your process will come grinding to a halt until a second has passed and it grows the pool. This will affect everything in your process, even seemingly unrelated code and can have dramatic bad effects on performance.
> *Fix:*
> There are a number of fixes possible, but the most efficient and best is to use async/await to rewrite Execute() as asynchronous.
> *Other side effects:*
> Execute has a catch(TTransportException) block which I suspect will never be hit. Calling .Wait() and/or .Result always wraps exceptions in an AggregateException. A properly written async/await version would unwrap that exception for you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)