| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Preserving Application Performance When Porting from MTS to COM+ | |
|
||
| Time: 00:00 EST/05:00 GMT | News Source: Microsoft | Posted By: Robert Stein | ||
|
Much to their dismay, some folks experience an actual degradation of performance when porting their n-tier application from Microsoft® Windows NT® Server/MTS to Microsoft Windows® 2000/COM+. By merely using the default settings and without making any changes to their code, the responsiveness of their application may unexpectedly decrease significantly. This can prompt one to ask, "Okay, I did not change a thing, and my application is now a dog, what in the world can I do now?" Do not be disheartened. Realize that performance isolation is not a trivial task by any means. It is often a convoluted blend of experience, testing, data gathering, research, trial and error, investigational espionage, dedication, and a bit of black magic (not necessarily in that order!). In the highly complex and interwoven world of today's n-tier application, there are many factors that can affect responsiveness. And by fixing one problem, you may expose another weakness in your architecture, maybe not even associated with COM+! | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 299 Last | Next |
The time now is
1:37:32 PM
ET.
Any comment problems? E-mail us |
| #1 By 135 (209.180.28.6) at 3/22/2002 10:24:59 AM |
|
"Avoid Long Running Method Calls from a Single-Threaded Apartment (STA)"
I love how Microsoft words this, but the truth is they broke Visual BASIC and offered no provision for fixing it. A "Long Running Method Call" can be as simple as a call to the database that takes 1 second to process. This thread pool should have been configurable in the COM+ package settings, or something. After a great while they did release a patch to allow it to emulate the MTS behavior, but come on... VB is an essential part of Microsoft's strategy and this should have come out during testing. I mean we hit it right away when we started looking at migrating. Oh, but then look at the wording of their workaround... "This should be your last choice as the COM+ thread pool mechanism is designed to improve performance, and there are valid reasons for using its algorithm." GIVE ME A BLOODY BREAK! If this thread pool throttles the performance capabilities of my box to 1/4th that of an equivalent box running NT4, how the hell do can you sit there with a straight face and claim the thread pool is designed to improve performance? |
|
Write Comment
Return to News |
Displaying 1 through 25 of 299 Last | Next |
The time now is
1:37:32 PM
ET.
Any comment problems? E-mail us |
