Performance degradation from mts/nt to com+/2000

[Christine Wolak]

This is a response to a post from back in February by John Harkin:

We are seeing the same thing - well, only a 111% degradation (meaning taking
over twice as long - it's gone from 2.7 seconds per UOW to 5.7), but still.
Did you ever find a solution? We are working with Microsoft, and they
mentioned two things - first, the extra marshalling you mentioned, and
second, the heap allocation errors (though they say that's fixed in SP2,
which is what we are running with). We're still trying to find out exactly
how much overhead the extra marshalling is adding, and what else we might be
doing "wrong". Please let me know if you've found out anything else! I just
wanted to let you know that you are NOT alone out there!

Christine Wolak

SCT Corporation, Columbia SC USA

[Michael D. Long]

I noticed this last spring & summer while performing some
benchmarks. In addition to the factors you have mentioned,
I observed a 5 second (approx.) overhead in initial package
instantiation.

I did not see a 111% degradation, but rather 30% - 50%
(which varied by functionality). On Win2K for simplistic
page generation an all ASP solution typically outperforms
an ASP w/ COM+ approach. This is opposite the behavior
on NT4, where ASP w/ MTS offered significant performance
benefits over ASP alone.

At various points since then I have discussed these observations
in the newsgroups and with Microsoft employees. However, I
did not pursue it via a support incident. I had found that my time
spent producing repro cases for Microsoft Support were a waste
of time - Oracle ran them, Microsoft didn't.

I'm sure I still have some of the results around. Your post was
a reminder to archive some stuff before I rebuild my machines.

Best regards,

Michael D. Long

"Christine Wolak" <cwo...@NOSPAM.sct.com> wrote in message
news:uE#gOVoKBHA.1468@tkmsftngp05...

[Christine Wolak]

Thanks... At this point, the benchmark I'm running is a back-end process so
ASP really doesn't factor into it. We have it down to one package, and I
even turned off all transactions (though not in CODE, just in Component
Services). I've tried putting data layers in a library package, which is
supposed to avoid the whole context switch thing, and it made NO difference!
So we are getting more and more frustrated...

"Michael D. Long" <michael...@bellsouth.net> wrote in message
news:exDYLiwKBHA.1992@tkmsftngp05...

[Massimo Gentilini]

> even turned off all transactions (though not in CODE, just in Component
> Services). I've tried putting data layers in a library package, which is
> supposed to avoid the whole context switch thing, and it made NO
difference!
> So we are getting more and more frustrated...

Seems strange, because context switching shuld be a cause of lot of
problems, I suspect than also if you moved some components in library
packages some context switching still occurs. I can suggest reading
"Transactional COM+" from Tim Ewald of DevelopMentor and try also to:

- Disable "Component support events and statistics"
- Enable "Must be activated in caller context"
- Disable transaction where not needed
- Disable Role based security where not needed

You can also try to log exactly where and when context switch appears, here
is some code:

Sub ISomeCfgClass_WhereAmI()
MsgBox GetObjectContext.ContextInfo.ContextId(), "Here:"
End Sub

HRESULT CSomeCfgClass::WhereAmI()
{
CComPtr<IObjectContextInfo> spCtx;
HRESULT hr = CoGetObjectContext(__uuidof(spCtx),
(void**)&spCtx);
if (FAILED(hr)) return hr;
GUID guid;
hr = spCtx->GetContextId(&guid);
if (FAILED(hr)) return hr;
MessageBoxW(0, CComBSTR(guid), L"Here:", MB_OK);
return S_OK;
}

Greetings from Italy
Massimo

[Christine Wolak]

Thanks Massimo. Some of the things you suggested are the same things that
the Microsoft article Q261096 says to do. The only problem in our case is
that this article says how your objects MUST be set, and it all goes to what
you say below "where not needed". Unfortunately, the way our code is
structured (badly), we need them EVERYWHERE.

I did what was recommended in the article as a prototype only and got an
instant improvement - from 5.7 seconds to 3.5 seconds. But, for proper
transactions and error checking, we cannot just set these options without
restructuring our code. Plus, that 3.5 seconds is still more than we were
seeing under NT, which was 2.7 seconds.

"Massimo Gentilini" <phi...@translateinfinityinitalian.it> wrote in message
news:#2OLzu8LBHA.1432@tkmsftngp07...

[Christine Wolak]

Thanks Massimo. We were pointed to article Q261096, which pretty much says
exactly what you said, except that you MUST set those options in order to
get them into the same context. And you can only do that with
NON-transactional components. Unfortunately our code is structured badly,
so most EVERYTHING is transactional.

Doing these things (ignoring any possibility of errors) we did see an
improvement from 5.7 seconds to 3.5 seconds. Under NT we were seeing 2.7
seconds. So we're still looking for that other 0.8 seconds!

"Massimo Gentilini" <phi...@translateinfinityinitalian.it> wrote in message
news:#2OLzu8LBHA.1432@tkmsftngp07...
>

[Karim Mardini]

If "Must be activated in caller context" is enabled, what happens when the
component is called from a different package or from a different exe
altogether (i.e. I had an NT service calling an MTS component so obviously
the component was activated in a seperate process and context, now with COM+
what will happen if the aforementioned option is enabled ?).

Thank you.

--Karim

"Massimo Gentilini" <phi...@translateinfinityinitalian.it> wrote in message
news:#2OLzu8LBHA.1432@tkmsftngp07...
>

[Massimo Gentilini]

I believe that a new context is created, but I'm not sure (I think is one of
the thing changed from SP1 to SP2).

[Christine Wolak]

According to the Microsoft documentation online, if you set this flag, but
the component cannot be activated in the caller's context, you will get
error 80004024 - CO_E_ATTEMPT_TO_CREATE_OUTSIDE_CLIENT_CONTEXT. I have seen
this error and I know it works from outside COM+ to a call inside COM+. I
assume it works the same from package to package.

"Karim Mardini" <nos...@nospam.com> wrote in message
news:uSqddshOBHA.1188@tkmsftngp04...