ASP.NET Poor performance with long-running COM object calls

[Guest]

We have a COM object that has been wrappered for use in .NET and which can
make calls which can take a while to execute. These are mainframe
integration calls that might perform a lot of data entry and gathering,
returning the results to the ASP.NET caller.

I have tried an AsyncPage class (implements IHttpAsyncHandler and uses
custom thread pool class from DevelopMentor.ThreadPool
-http://staff.develop.com/woodring); I have tried the thread start-join trick
and no matter what, all pages stop when a call is made into the COM object
until the call returns.

In my internal logging I see that only one "real" system thread is used for
all the calls/pages/threads due to the way ASP.NET is hosting the CLR (I
guess).

This is very frustrating--does anyone know a way that you can FORCE ASP.NET
to use REAL SYSTEM THREADS, 1 per ASPX page execution instead of these
"girly-man" threads in the .NET clr, which seem to all freeze in dismay
whenever one of them dives into a COM object?

I'm sure there are many excuses for this odd trait of ASP.NET but I consider
it a bug anytime a "next generation" of a product behaves in a less robust
manner than its predecessor. The multithreading in ASP.NET is poor. Long
running pages shouldn't hold-up short running pages.

 

[David Browne]

We have a COM object that has been wrappered for use in .NET and which can
make calls which can take a while to execute. These are mainframe
integration calls that might perform a lot of data entry and gathering,
returning the results to the ASP.NET caller.
. . .
The multithreading in ASP.NET is poor. Long
running pages shouldn't hold-up short running pages.

No they don't. Threading in .NET is far superior to COM. What you are
seeing is probably a result of not setting the apartment model of your
threads correctly to work with your fusty old COM component.

What is the threading model of the COM component?
Did you set AspCompat='True' on the ASPX page?


David

 

[Guest]

Sorry, forgot to mention that yes, tried the MTA option on the threading
model at the beginning since this is so easy to try. Didn't change anything-
next thing to try was the spawn new thread, start it (run long-running com
call in it) then join it, which wasn't very hard. Next thing to try was the
async http interface and async page class which was a pain, and still didn't
work.

aspcompat makes no sense for this COM object, which is a C++ multithreaded
object.

The problem starts "at the top" when the aspx.cs code is run as a CLR
"thread" instead of a win32 true system thread. Because the CLR is operating
in this separate multitasking model, it is apparently incapable of task
switching if it is inside a COM/unmanaged function.

I suppose you could posit that the threading model in ASP.NET is "superior"
to ASP for homogeneous short-lived ASPX pages in environments with very large
numbers of users. However, for environments with some legacy requirements
(including COM components that are non-trivial to convert to managed), the
"self-contained" threading model in the CLR has a very poor performance
profile for environments with, simply, "more than one" concurrent user. If
you only have a hundred or so active users, concurrent requests probably
won't run over 20 or so. I honestly in all my years of low-to-high level
systems coding have never seen any issue with win32 being able to
context-switch 20 system threads, even hundreds which is actually what it is
doing in the OPSYS anyway!

I am a big .NET and ASP.NET fan and have bet a huge amount of tools
development effort on it, but it doesn't mean I have to love every aspect
unconditionally. I would love to be corrected and provided a real solution
to my problem: the context switching in the CLR engine is simply not
compatible with COM objects, STA or MTA.

In a COM call = no CLR context switch
No context switch = no multitasking
No multitasking = step backwards

If there is a directive I can put in my ASPX page that requests a 1-1 CLR
thread to system thread...hooray. Anyone know of one? Sure sounds like a
good idea for those of us that need it.

Otherwise, I have to schedule-in an immediate upgrade of the COM component
to a mixed managed/unmanaged code implementation and have concerns about how
far into the codebase I will have to go to enable a context switch when
inside the ASP.NET CLR environment.

 

[David Browne]

Sorry, forgot to mention that yes, tried the MTA option on the threading
model at the beginning since this is so easy to try. Didn't change
anything-
next thing to try was the spawn new thread, start it (run long-running com
call in it) then join it, which wasn't very hard. Next thing to try was
the
async http interface and async page class which was a pain, and still
didn't
work.

aspcompat makes no sense for this COM object, which is a C++ multithreaded
object.

You didn't answer the question about the threading model of your COM
component. And you didn't answer the question about whether you set
ASPCOMPAT=true.

The problem starts "at the top" when the aspx.cs code is run as a CLR
"thread" instead of a win32 true system thread. Because the CLR is
operating
in this separate multitasking model, it is apparently incapable of task
switching if it is inside a COM/unmanaged function.

You are gravely mistaken.

I suppose you could posit that the threading model in ASP.NET is
"superior"
to ASP for homogeneous short-lived ASPX pages in environments with very
large
numbers of users. However, for environments with some legacy requirements
(including COM components that are non-trivial to convert to managed), the
"self-contained" threading model in the CLR has a very poor performance
profile for environments with, simply, "more than one" concurrent user.
If
you only have a hundred or so active users, concurrent requests probably
won't run over 20 or so. I honestly in all my years of low-to-high level
systems coding have never seen any issue with win32 being able to
context-switch 20 system threads, even hundreds which is actually what it
is
doing in the OPSYS anyway!

I am a big .NET and ASP.NET fan and have bet a huge amount of tools
development effort on it, but it doesn't mean I have to love every aspect
unconditionally. I would love to be corrected and provided a real
solution
to my problem: the context switching in the CLR engine is simply not
compatible with COM objects, STA or MTA.

In a COM call = no CLR context switch
No context switch = no multitasking
No multitasking = step backwards

If there is a directive I can put in my ASPX page that requests a 1-1 CLR
thread to system thread...hooray. Anyone know of one? Sure sounds like a
good idea for those of us that need it.

CLR threads wrap system threads. This may not be the case in future
versions of the CLR, but it's true now.
ASPCOMPAT=true will start your CLR threads as STA threads, and is intended
to prevent exactly the behavior you are complaining about.

From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt07.asp

When you call a COM object from a managed application, make sure that the
managed code's apartment matches the COM object's apartment type. By using
matching apartments, you avoid the thread switch associated with
cross-apartment calls.
.. . .

Use ASPCOMPAT When You Call STA Objects from ASP.NET
All .NET threads are MTA threads by default. Therefore, cross-apartment
calls and thread switches do not occur when you create and call COM objects
with an apartment type of Free, Both, or Neutral. However, cross-apartment
calls and thread switches occur when you create and call apartment-threaded
COM objects.


David

 

[Guest]

David, Thank you for your persistance despite my flaming.

My confusion arose from the documentation on aspcompat which focuses on
Apartment COM objects and VB. My COM object is a "both" model and the
problem I was encountering wasn't one of any breakage, just of being
locked-out.

Indeed, the aspcompat did fix the problem, and is also fixing a problem we
have with a mixed-model integration library also, which has no COM involved
but does have complex unmanaged code hanging on semaphors shared across
processes. These also get hung-up when one aspx page is waiting on a call
into the unmanaged code which deep-down as a WaitForSingleObject on a native
event semaphore (or mutex, pick your poison).

Once again, appreciate your help.