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

Discussion in 'ASP .Net' started by =?Utf-8?B?QmlsbCBUaG9ybmU=?=, Oct 12, 2004.

  1. 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.
    =?Utf-8?B?QmlsbCBUaG9ybmU=?=, Oct 12, 2004
    #1
    1. Advertising

  2. =?Utf-8?B?QmlsbCBUaG9ybmU=?=

    David Browne Guest

    "Bill Thorne" <> wrote in message
    news:...
    > 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
    David Browne, Oct 12, 2004
    #2
    1. Advertising

  3. 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" wrote:

    >
    > "Bill Thorne" <> wrote in message
    > news:...
    > > 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
    >
    >
    >
    =?Utf-8?B?QmlsbCBUaG9ybmU=?=, Oct 13, 2004
    #3
  4. =?Utf-8?B?QmlsbCBUaG9ybmU=?=

    David Browne Guest

    "Bill Thorne" <> wrote in message
    news:...
    > 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
    David Browne, Oct 13, 2004
    #4
  5. 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.


    "David Browne" wrote:

    >
    > "Bill Thorne" <> wrote in message
    > news:...
    > > 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
    >
    >
    >
    =?Utf-8?B?QmlsbCBUaG9ybmU=?=, Nov 15, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Helge

    W3WP poor performance

    Helge, Mar 14, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    1,420
    Scott Allen
    Mar 14, 2005
  2. dan
    Replies:
    1
    Views:
    322
    Christophe Vanfleteren
    Apr 6, 2004
  3. Lyall
    Replies:
    1
    Views:
    414
    Lyall Pearce
    Feb 6, 2006
  4. qvx
    Replies:
    7
    Views:
    438
  5. meo

    IIS and poor performance

    meo, Feb 12, 2007, in forum: ASP .Net
    Replies:
    1
    Views:
    375
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Feb 12, 2007
Loading...

Share This Page