Watch out: DebugView (OutputDebugString) & Performance

by community-syndication | Apr 3, 2007 | BizTalk Community Blogs via Syndication

For developer level tracing the tracing classes held within the System.Diagnostics namespace are often used along with the Windows Sysinternals DebugView tool.  Tracing events are written to OutputDebugString via the DefaultTraceListener trace listener. 

This listener writes output to OutputDebugString (which DebugView can monitor), and a managed debugger (if one is attached).  In addition the DefaultTraceListener trace listener is responsible for popping up and dealing with the managed assert message box.  You can disable the “default” DefaultTraceListener in your application’s config file as required.

This approach to tracing works extremely well and is something I use myself a lot, but you should be aware of the associated performance overhead. DebugView effectively acts as a debugger and hooks the OUTPUT_DEBUG_STRING_EVENT event, as a result your application (a BizTalk process perhaps) will experience a performance impact as the application threads will be suspended whilst the debug information is output, effectively serializing your application.  Therefore if you have many Orchestrations in-flight (or multiple threads if your not using BizTalk) they will all be side-affected if DebugView is started and performance will therefore be affected. 

It’s worth noting that if the DebugView tool is not started (and therefore there are no subscribers to the information) the performance impact is negligible and shouldn’t in my experience be something to worry about, therefore do not be afraid to output information that you feel will be useful.

Either way you should ensure that your tracing code is implemented such that it can be disabled to reduce the performance overhead, typically you will need the ability to enable it at run-time. When carrying out performance testing you will most likely want to disable tracing, although gaining an understanding of the overhead is also valuable.

In my view the performance hit associated with software tracing is outweighed by the ability to diagnose run-time issues in a non-intrusive manner.  Most Microsoft products, including BizTalk Server, rely heavily on software tracing which the product group leverage to diagnose customer issues off-line.  Just be aware that running DebugView during performance testing or on a live server is very likely to significantly impact performance!  I’m not saying not to use it, Please Do!  It makes everyone’s life easier but just be aware of the performance impact when your running those tests and in live.

Roll on the mighty ETW TraceListener planned for Visual Studio “Orcas”, kernel model ultra-fast tracing from managed code!  ETW has been available for a while but has been pretty hard to leverage from managed code.  It’s worth nothing that BizTalk itself uses ETW heavily to provide extremely rich internal “developer level” tracing which we can use to diagnose problems at customer sites.

Thanks to Jon Fancey for highlighting this during the review stage of the book, he experienced a solution being seriously impacted when DebugView was left running on a live server, and to Matt Ellis (BCL) for adding some detail around the DefaultTraceListener.

BAM: PivotTables not working on the BAM Portal

by community-syndication | Apr 3, 2007 | BizTalk Community Blogs via Syndication

I’ve used the same base VPC for my various BizTalk Server 2006 images over the last few years, this has worked fine apart from a few annoying bugs that of course plagued every single instance of a VPC using it, of course I never really spent the time to iron them out so suffer from them every now and again 🙁

All are most certainly down to me not having exactly the right bits installed or not having the configuration quite right.  One annoying problem was the Pivot Table view on the BAM Portal refusing to work by coming up with the following unhelpful error:

“The query could not be processed: Cannot connect to the server ‘DARRENJBTS06’. The server is either not started or too busy.”

Over the years I’ve tried just about everything to fix it: Configuration, Security, Service Packs,etc. but have never managed to solve it until now – after some digging internally it seems that my base VPC was missing Version 9.0 of the Analysis Services OLE DB Provider, installing this resolved the issue straight away, the update is listed on this page along with some other updates.

Hope it helps!

WebLogic 10 is here

by community-syndication | Apr 3, 2007 | BizTalk Community Blogs via Syndication

BEA WebLogic 10 has been released. I am particularly impressed with the enhancements to the Web Services stack which includes: -WS-Security 1.1 -WS-Secure Conversations -SAML Token Profile -Binary (MTOM) web service message attachments (for images or…(read more)

A lot of HRESULT codes…

by community-syndication | Apr 3, 2007 | BizTalk Community Blogs via Syndication

Just found a huge list of HR codes… BTW, let me explain the type of information I publish here. It’s not exactly a blog, it’s rather a  public notebook, where I put the stuff I want to be at hand, and if somebody else will find it useful, so better! And yes, I know, there is error lookup in Visual Studio, but when you investigate a test machine or a customer computer, you don’t have Visual Studio at hand, but you usually have Internet…