|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Charles Gamble (Charles.Gamble
SINGULARITY.CO.UK)Date: Tue Oct 09 2001 - 03:44:46 CDT
Any ideas why this is happening?
We thought this might be occuring due to more thread switching in
Windows2000.
This page faulting is on the DLLHOST.EXE process. How can we resolve this
problem?
Charles.
-----Original Message-----
From: Steve Swartz [mailto:stevesw
MICROSOFT.COM]
Sent: 08 October 2001 18:56
To: DCOM
DISCUSS.MICROSOFT.COM
Subject: Re: COM+ and Performance
Assuming that the machines you're running on are identical....
Extra page faults are usually a sign of increased use of virtual memory.
Windows 2000 is larger than NT4, and requires more memory. It sounds
like your system used to be relatively close to a virtual memory limit
under NT4, and move across that limit when you upgraded to Windows 2000.
The same thing happened to me when I upgraded PageMaker ;)
-----Original Message-----
From: Charles Gamble [mailto:Charles.Gamble
SINGULARITY.CO.UK]
Sent: Monday, October 08, 2001 8:01 AM
To: DCOM
DISCUSS.MICROSOFT.COM
Subject: Re: COM+ and Performance
One thing we have just noticed is that the Dllhost.exe which is hosting
our
com+ dll's is page faulting extrememly excessively
( average of 700 page faults per sec when procesor object charted in
perfmon) in Com+ .
In Nt 4.0/Mts it is no where near this figure.
Any ideas what could be causing this?
Our threading model is "Both" for all our objects.
Charles Gamble.
-----Original Message-----
From: Richard Blewett [mailto:richard.blewett
VIRGIN.NET]
Sent: 03 October 2001 16:06
To: DCOM
DISCUSS.MICROSOFT.COM
Subject: Re: COM+ and Performance
Sorry, I didn't mean the COM+ subsystem, I mean't that the OS in general
- disk I/O etc was faster in Win2K than NT. There are loads of factors
which can affect your performance when running under COM+ and straight
porting from MTS to COM+ isn't necessarily an optimal way to go. The
context architecture and threading issues are much more complex under
COM+ (theres alot more choice for starters).
Richard
http://staff.develop.com/richardb
-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOM
DISCUSS.MICROSOFT.COM]On
Behalf Of Christine Wolak
Sent: 03 October 2001 15:36
To: DCOM
DISCUSS.MICROSOFT.COM
Subject: COM+ and Performance
We too have been having performance problems with our application on
Windows 2000. Here's a summary of where we are now, in case it helps
anyone:
Our application was taking about 2.3 times as long under Win2k as
compared to NT. We got a hotfix from Microsoft which got us about 0.6
of that 2.5 back. This hotfix was supposed to provide MTS emulation
mode (as far as max apts per thread, or max threads, or something like
that), but the emulation mode itself didn't make any difference in our
application - just having the hotfix did.
Then, all of a sudden we got all but 0.1 of it back. A significant
improvement! The traces we did pointed to the function
GetQueuedCompletionStatus, which seemed to have to do with I/O in some
way. I think I think this improvement came because of
manually/specifically stopping and restarting DTC (rebooting the machine
did NOT do the trick). Microsoft never did say for sure why or whether
stopping DTC fixed this, what might have caused it to take up so much
time all of a sudden, how to keep it from happening, etc. We haven't
seen the problem crop up again, but if we do, Microsoft says that
they'll want to do some poking around at call stacks and stuff.
Another thing that did not apply to us but may apply to others was a
memory allocation issue that was broken in SP1 but fixed in SP2.
We also did some testing to force everything into ONE BIG CONTEXT, and
that had no real impact on our performance. We have one big
package/application, though, so maybe that has something to do with it.
I must respectfully disagree with Richard Blewett, who said "for a
properly configured server, Win2k is simply faster than NT". This is
NOT the case for every COM application, and as far as I could tell from
Microsoft, there's not much in the way of "configuration" of your server
that you can do to speed up performance, anyway. Maybe for
WELL-DESIGNED systems, or small systems (we have 71 DLLs in COM+), or
some other scenario. But "configuration of the server" didn't seem to
have anything to do with it.
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html . To unsubscribe,
mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html . To unsubscribe,
mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html . To unsubscribe,
mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]