11

We are trying to increase the number of threads used by .NET Remoting over TCP. We have tried changing the ThreadPool.SetMinThreads, but our stress tests show that .NET Remoting can only handle about 100 concurrent requests. (However this is not a hard limit). In Task Manager, we can see our Remoting Server process Thread count grow from 11 to about 80, which then drops back down to 11 after the stress test. We are running an ASP.NET 4.0 application.

meub
  • 2,288
  • 17
  • 19
  • I have a few questions. 1. What kind of remote objects do you use? Singleton, SingleCall, client or server activated? 2. I'm not sure if I understand you correctly. Is it a problem for you that Thread count drops down. 3. How many processors/cores does your machine have? 4. Am I right that you use IIS to host remoting objects? 5. Why do you want to have so many threads? Do you want to improve performance? – Michał Komorowski Apr 08 '15 at 08:11
  • 1
    SingleCall. client activated. 16 cores. IIS hosts the remoting client. A Windows Service hosts the remoting server. We want to improve performance because we notice we can only squeeze 100 requests through the remoting pipe at one time (even if these requests are doing nothing but Thread.Sleep on the other end). – meub Apr 08 '15 at 20:33
  • I'd like to ask about 2 more things. 1. Am I right that you used `ThreadPool.SetMinThread` on the remoting server? 2. How did you perform stress tests? I wonder if requests to the server were sent from the remoting client hosted on IIS or maybe from another application not hosted on IIS? – Michał Komorowski Apr 10 '15 at 06:13
  • 1) Yes. 2) We create a remoting server method which simply sleeps for ten seconds. We then call this method from the remoting client using Apache Bench with 1000 concurrent threads (so IIS is the remoting client). – meub Apr 10 '15 at 21:47

3 Answers3

4

To sum up. A remoting server is hosted by a windows service and a remoting client by IIS. To perfrom stress tests you use Apache Bench which calls the remoting client which calls the remoting server. You observe that no more than 100 concurrent requests is processed by the remoting server although you increase maximum number of threads in a thread pool on the remoting server.

If all what I said is true I think that one thing is missing here i.e. IIS also has a limit of threads that can be used to handle requests. You can send 1000 request from Apache Bench to the remoting client but only, for example 100 of them will be handled at the same time. I suspect that it might be a reason.

In order to increase number of threads for IIS I suggest you to try to:

  • Check configuration (see this question).
  • Try to use SetMinThreads on IIS.

The last comment from my side is that you have to remember that neither too small number of threads nor too high number of threads in a thread pool is good. Both situations can hurt performance.

Community
  • 1
  • 1
Michał Komorowski
  • 6,198
  • 1
  • 20
  • 24
1

Are you sure the bottleneck is threads, and not network connections..? By default, .net has a fairly limited number of sockets available per remote IP. This applies to remoting, http (WCF, web service clients), etc.

You can override this under system.net/connectionManagement in your app config/web.config if this is what you are seeing, e.g.:

<configuration>
...
  <system.net>
    <connectionManagement>
      <add address="*" maxconnection="1000"/>
    </connectionManagement>
  </system.net>

More details about that config setting can be found here: https://msdn.microsoft.com/en-us/library/fb6y0fyc%28v=vs.110%29.aspx

KristoferA
  • 12,287
  • 1
  • 40
  • 62
0

Check your return value of SetMinThreads.

If you specify a negative number or a number larger than the maximum number of active thread pool threads (obtained using GetMaxThreads), SetMinThreads returns false and does not change either of the minimum values. (link)

Avram
  • 4,267
  • 33
  • 40
  • Yes we already tried this and we are getting a return value of true. We have also called GetMinThreads afterwards to confirm that we set the min threads to what we expected. It appears remoting does not actually use ThreadPool to manage its threads... – meub Apr 10 '15 at 21:44