views:

83

answers:

2

I'm inheriting a legacy project, and there's a page that calls a method that makes a web service call. Load and performance testing has detected that this page sometimes takes a really long time to close, but usually it's fine, and if there is one hanging, all other requests for that page hang until the first one resolves, and then they all resolve.

I think this might have something to do with the web service being instantiated and not disposed, but I don't know how I can be more sure. I tried to add a delegate to the Dispose method but that doesn't seem to ever fire. (I'm not sure it would without Dispose being called explicitly, but that doesn't really matter.)

So what can I look for on the production server or any deployed environment to watch those requests pile up and go out (or get handled in an orderly manner, if they aren't the problem)?

A: 

In your web app code, you could write to a log (event log, text file) right before you send a request, and again right after you get the response. Include some identifying information about the request. Add timestamps.

If you only want to use this while debugging, wrap it in #debug.

Or if you want to test in release mode, you could put a boolean in appSettings in web.config so you could turn the logging off and on.

DOK
I'm not terribly worried about the time between asking for a response and getting one. I'm more concerned about what happens after I get the response - I'm assuming that the connection shuts down and isn't indefinitely occupying one of a finite number of outbound connections. Finding out what .NET is actually doing with those calls is the problem.
dnord
I was thinking this might help "watch those requests pile up and go out (or get handled in an orderly manner".
DOK
+1  A: 

You might consider using a tool like .NET Memory Profiler. You can use it to attach to your running application, and it can find and report all undisposed objects.

I think they have a free two week trial.

RickNZ
I could not find a way to specifically check for open web service calls, but this sort of hinted at objects being left open. It didn't look much different when I explicitly closed them, but .NET Memory Profiler isn't really for beginners. I'll keep hammering on it.
dnord