Yosi Taguri reports a story of debugging a bottleneck in a scenario where an ASP.NET server is talking to a second server via remoting.  We have seen similar problems in our web service tier.  What we have is an ASP.NET front end, talking to a second tier via remoting, which calls down to COM components that then talk to our mainframe.  Specifically, when the mainframe starts responding more slowly (usually because a vendor's link is having problems), we see impact on response times way out of proportion with the increased response time on the mainframe.  It seems like that the ASP.NET layer gets loaded to the point where it needs to start issuing 503s and it starts spending more time processing queues and rejecting requests than actually performing "real" work.  In our case, adding worker threads to the web server has helped, but it's just a bandaid.  I've tried isolating this by writing a web service that just sleeps for a specified interval, but my results are pretty inconclusive.  Reading Yosi's story, it seems like there's a problem with the interaction between ASP.NET and Remoting instead.  I was supposed to extend my tests out to add in a remoting layer, but the issue pretty much dropped off the radar (now when our web service monitor starts throwing off alerts, the help desk knows to go check the external vendor links first), so I never got to it.  I probably should resurrect these tests again and try to nail this down.