Scott Hanselman

Been doing some A hrefhttpmsdnmicrosoftcomlibrarydefaultaspurllibraryenuscpguidehtmlcpcondevelopinghighpe

November 27, 2002 Comment on this post [0] Posted in Web Services | ASP.NET | TechEd | Speaking | XML | Bugs
Sponsored By

Been doing some Web Gardening lately, and I'm disappointed at the lack of documentation on this supposedly powerful option for ASP.NET.  If I'm using a Quad-Proc Box and an ASP.NET Application that as some time is calling (via Interop) an inproc free-threaded C++ COM Component that then does some opereations and a (legacy) DCOM call out to another box, you'd think that having MaxWorkerThreads (per CPU) at some number x where 25<x<75 would be reasonable thing.  I would assume that a DCOM call (or Web Service call) would count as "waiting for an external resource" and that a few extra threads, and certainly a worker process per CPU would be ideal.  Per MSDN:

"If your application uses a slow database server or calls COM objects that have external dependencies, to name only a couple of possibilities, it can be beneficial to enable Web gardening for your application."

Certainly, this is vague at best.  Of course, everyone has seen the decks with one slide that mention Web Gardening, as well as books that spend a sentence on Web Gardening.  How do these ASPNET_WP.exe worker processes really behave?  I would presume it's as if one box becomes four...separate Cache Objects, separate Application objects. 

With Web Gardening, I'm seeing ASPNET_WP processes recycling constantly, and CoCreateInstance calls to my legacy DLLs failing.  However, without Web Gardening, things are peachy keen, and 30-50% better performance.

  • What are the ramifications for legacy COM and DOM calls within ASP.NET Worker Processes within a Garden?
  • Is Web Gardening just one of those many tweaks you give a try? 

Before this exercise, Web Gardening was an option in my architectural (as it's not behaving at ALL like I'd have though) I'm not sure.

I'd had similar trouble in the past trying to tune MaxIoThreads and MaxWorkerThreads.  I had an ASP.NET application that was calling out to 2 or 3 Web Services, and when the system was under significant load, it would crap out - It was actually unable to get a free thread (from the system's thread pool I assume) to even get out of the box.  I was getting errors in the Socket Class, in the bowels of WebRequest.  Seemed that the box was SO busy dealing with the multiplicity of calls coming in (that were fanning out into n*2 outbound calls - ya, I know...) that it couldn't make the calls out...everyone blocked. (I even wondered if this was a nageling issue...or perhaps the HTTP stack not wanting too many calls (>2 [section 8.1.4]) out to the same server? ) And changing MaxIoThreads and MaxWorkerThreads from ANYTHING but the default of 25 was useless. 

  • Would it have been better to have written my own reserved thread pool and made the calls from there? 
  • Calling back to the Web Gardening the interest of throughput, should the calls to the COM object (that then calls out via DCOM to others) be made via my own worker thread pool? 
  • Or perhaps, from a COM+ application (That's what Clemens suggested).

These are the things that are currently disturbing my sleep...

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.