4

We're in the process of deploying a new app into it's live environment.

The app servers are running an IIS hosted .NET application that uses EntityFramework and makes numerous calls to a non .NET COM+ application.

We have been able to affect the performance of the pure .NET code by modifying the number of Maximum Worker Processes inside the IIS Application Pool but my question is how does the number of Worker Processes relate to the Pool Size of the Application Pools in Component Services? Things like:

  • should we be aiming for a 1 to 1 relationship between these 2 values?
  • should we avoid multiple worker thread?

Any insight gratefully received ...

qujck
  • 91
  • 1
  • 7

1 Answers1

2

The number of worker processes in the two pools is not directly related. What you need to establish is the dwell time in each pool. So, if the IIS workers are busy and only a small proportion of overall time is spent in the COM application, then the COM threads are not likely to bottleneck the performance.

Try to measure the number of active threads in a stress situation to determine how to control the sizes of the individual pools.

Consider also that the IIS worker processes are also recycled on criteria other than the processor utilisation. This may substantially affect your ability to share data between invocations and could subvert attempts to strongly affect direct performance.

You would do better to reduce the cost of doing the .NET to COM bridging by considering a thin COM wrapper that can aggregate multiple requests from a single .NET query. This can also have the side-effect of consolidating multiple COM methods into a single thread from the pool.

Pekka
  • 530
  • 5
  • 15