Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HyperFastCGI threading/IO configuration vs. ASP.NET configuration. #60

Open
derFunk opened this issue Jun 23, 2016 · 1 comment
Open

Comments

@derFunk
Copy link
Contributor

derFunk commented Jun 23, 2016

Hi,

we're having an ASP.NET web service with ServiceStack which itself calls multiple other HTTP web services at self - around 3 HTTP calls to an external service per request to our service.

We're suffering from very bad performance there. The called external webservice should be able to handle 100k requests per second.
We cannot send more than around 5 per second, altough we're having 1000 requests per second to this service as well.
So it seems we're encountering deadlocks and full queues.

I found this: https://support.microsoft.com/en-us/kb/821268
It seems like this is exactly the symptoms we're having.

The question now is:
The HFC configuration let's us define all of these parameters: <threads min-worker="40" max-worker="0" min-io="4" max-io="0" />.

Is this related to the configuration recommendation Microsoft is making on their page?

Or is this totally distinct and am I supposed to add maxWorkerThreads, maxIoThreads, minFreeThreads, minLocalRequestFreeThreads etc to our Web.config as well, because otherwise the (low) default values would be in affect for our web application?

Thanks!

@xplicit
Copy link
Owner

xplicit commented Jun 23, 2016

ThreadPool config values just an example and you should tune these values according to your application usage. If it creates alot of parallel network requests you should increase number of IO threads. If application creates large number parallel threads via ThreadPool.QueueUserWorkitem you should increase number of worker threads. Also you can set all these values to "0" to get default ThreadPool settings.

When the new request arrived ThreadPoolchecks if there is available thread in pool and if thread is not available it tries to create new one. This is very costly operation and degrades performance alot. If number of created threads hit the max threads value then ThreadPool stops to create new threads and wait when previous will be completed. You should monitor you app to be sure that threads are not created on every request and total number of threads in normal conditions is unchanged (if you do not create threads directly with Thread.Start).

My experiments shows that default number of worker threads is very low for high-load application and should be increased. These values from sample hfc.config are good for 2-core processor without active ThreadPool usage in services. So if you have more cores or actively use external calls you are definitely have to change these values to more large values.

Settings
<threads min-worker="40" max-worker="0" min-io="4" max-io="0" />

points to minWorkerThreads, maxWorkerThreads, minIOThreads and maxIOThreads settings in ThreadPool.

Finally, you should monitor threads numbers (via counters for example) in your application and find the best settings according to your usage.

Also it could be the situation when application does not return threads to the threadpool, if you have a simple example which shows the issue I will look in it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants