Boost Your App's Performance by Avoiding Cached Non-Agile Components

Understanding the Core Concept:

While caching data in the Application or Session objects often enhances performance, storing COM objects within them can lead to severe roadblocks. It's tempting to stash frequently used COM objects in these areas, but many of them, especially those built in Visual Basic 6.0 or earlier, can create major bottlenecks when cached.

Agile Components Are Key:

The crux of the matter lies in agility. An agile component is marked as ThreadingModel=Both and integrates the Free-threaded marshaler (FTM), or it simply has ThreadingModel=Neutral. If a component lacks agility, performance will suffer when cached in Session or Application scope.

Non-Agile Components: The Culprits and Their Effects:

Here's a breakdown of non-agile component types and their detrimental impacts:

• Free-threaded components: Only problematic if they don't incorporate the FTM.

• Apartment-threaded components: Confined to a single apartment thread, limiting concurrency.

• Single-threaded components: Designed for one thread at a time, unsuitable for caching.

• Configured components: Unless Neutral-threaded, they're not agile.

• Scripting.Dictionary object: Not agile, avoid storing in Application or Session scope.

Performance Downturns:

• Session scope: A non-agile component here "locks down" the Session to a specific ASP worker thread, causing requests to wait for that thread to become available. Imagine always having to queue at the same checkout counter, even if others are empty.

• Application scope: Even worse, non-agile Application-scoped components force ASP to create a special thread, leading to:

  • Marshaling: Parameters are copied to shared memory, leading to context switches and performance overhead.

  • Serialization: Methods are executed one at a time, eliminating concurrency, especially on multi-processor systems.

  • Shared thread bottleneck: All non-agile Application-scoped components share one thread, further amplifying serialization issues.

Recommendations:

• If using Visual Basic (6.0) or earlier, avoid caching objects in Application or Session.

• When unsure about an object's threading model, err on the side of caution and don't cache it.

• Instead, create and release non-agile objects on each page. This avoids marshaling and serialization, potentially offering decent performance if the COM objects reside on the IIS box and initialize/destroy quickly.

• Single-threaded objects are unsuitable for this approach; expect lower throughput if you must use them (e.g., Microsoft Excel spreadsheet).

• ADO recordsets can be cached safely when marked as Free-threaded (using Makfre15.bat). However, avoid this if using Microsoft Access as your database and ensure recordsets are disconnected. (The bat file would be typically located in the directory \Program Files\Common\System\ADO.)

• Consider dictionary components like LookupTable, PageCache, Caprock Dictionary, or custom derivatives for effective caching.

Additional Notes:

• The recommended practice is to generally avoid caching objects in Application or Session scope due to the potential overhead.

• For granular control, use ObjectContext to manage component lifetimes within specific ASP pages.

• Thoroughly test caching strategies in a representative environment to assess their impact on your application's performance.

• Instead of caching non-agile objects, you should create and release them on each page. The objects will run directly on the ASP worker thread, so there will be no marshaling or serialization. Performance will be adequate if the COM objects are running on the IIS box, and if they don't take a long time to initialize and destroy.

Source: https://axcs.blogspot.com/2006/07/asp-tips-tip-4-avoid-caching-non-agile.html