INFO: Thread Pool Differences Between COM+ and MTS (282490)


The information in this article applies to:

  • Microsoft Transaction Server 2.0
  • Microsoft COM+ 1.0
This article was previously published under Q282490

SUMMARY

This article describes the differences in thread pools between Microsoft Transaction Server (MTS) and COM+ and how to write code that makes best use of this pool.

MORE INFORMATION

Thread Pool Scheme

The thread pool scheme is designed to accommodate a growing number of users for the application. The thread pool scheme differs between MTS and COM+.

Thread Pool in MTS

In MTS, each server package maintains a single thread pool of single-threaded apartment (STA) threads. The number of threads in the pool can range from 1 to 100 by default. All components run in STA; even if you mark the components "ThreadingModel=Free" in the registry, MTS ignores this setting. MTS allows one activity for each STA until all 100 threads are used. After all 100 threads are used, MTS starts to reuse existing threads for activities (which is called "multiplexing"). An MTS process has an additional number of threads that manage the process; however, these threads do not come out of the STA thread pool.

Thread Pool in COM+

In COM+, each server application maintains two separate thread pools. One thread pool services STA objects, and another thread pool services free threaded components. The latter thread pool has no upper limit on the number of threads.

The COM+ thread pool size follows these rules:
  • The thread pool size is initialized to 7 plus the number of processors.
  • The thread pool size increases with the number of queued requests.
  • The maximum size that the thread pool can reach is 10 multiplied by the number of processors.
  • The thread pool decreases in size when the traffic is low.

Recommendations to Make the Best Use of the Thread Pool

  • Do not make blocking calls.

    A blocking call is a call that prevents the STA message pump from pumping messages. For example, the blocking call can be a call to the sleep function, or a blocking call can wait on events or call long running stored procedures. The most common scenario is a Microsoft Visual Basic Component Object Model (COM) object that runs in the STA thread (in MTS/COM+) that makes a blocking call. In this scenario, other COM objects on that STA cannot be serviced because the STA message pump cannot pump in messages. If your application requires that blocking calls be made, move the blocking code to a separate free threaded component (which is written in Microsoft Visual C++, for example). Note that this only works under COM+ because all components are STA threaded in MTS.
  • Do not increase the thread pool.

    The application should be redesigned to make the best use of the pool. It is not good for performance to add more threads to the pool because you lose CPU cycles in thread switching. Moreover, memory is allocated for every thread. Much research has been done on how to optimize the size of the thread pool. It is almost always a bad idea to manually adjust the size of the pool for a particular scenario.

REFERENCES

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

291837 INFO: Do Not Make Blocking Calls from an STA Component

303071 INFO: Registry Key for Tuning COM+ Thread and Activity

Modification Type:MajorLast Reviewed:4/10/2002
Keywords:kbinfo KB282490
©2002 Microsoft Corporation. All rights reserved.