WCF net.tcp, am I doing it right? (newbie)

antsInMyPants

Just downloaded ANTS to try it out, so newbie at this. (ANTS and memory profiling that is)

TL;DR:
Is it enough to use "Attach to process" to get all the info needed for memory leak/high memory usage for a WCF app?
Or are there any drawbacks using this type to profile that I should be aware of?

--> The long question

Trying to profile a WCF service using net.tcp.
WCF is called from a client that performs the calls that generates the problems in the WCF-code.

First tried instructions at http://documentation.red-gate.com/displ ... plications
However, the client couldn't connect to the new port set up by ANTS (using net.tcp). It didn't answer. Tried also changing the port in client config.
Browsing to http I can see the list of services ("directory view").

So instead tried "Original port". This seemed to work.
Client can call it, and there is stuff going on in ANTS view (perf counters in Timeline).
However, I don't think it is the correct info showing...the data does not
correspond to what I excpect. Heap size eg. is the same before and after I try the client,
although it is visible in the counters it is clearly not.
Also, the code when looking in the graphs, largest classes etc are not from "my" code, seems to be the .NET WCF-code or something..?

Finally tried to "Attach to process" (w3wp.exe).
Seems to work, data looks good in ANTS. Take snapshot #1. All OK.
Take snapshot #2...after a really long time I get the results.
And it is showing the data I am excpecting, showing "my" code in largest classes etc.

So my question is:

Is it enough to use Attach to process to get all the info I need?
(Searching for either memory leak or high memory usage problems)

Should I be doing this in another way?

Thanks!

/R

Jessica R

Hi there,

Thanks for your post!

Regarding your query, there are two features that are not available when using "Attach to process": "Track disposal of IDisposable objects" and "Profile unmanaged memory allocations". If your code doesn't allocate much unmanaged memory and you're not concerned about IDisposable objects though, then attaching to process should provide enough information to analyze the memory usage of your WCF app.

Attaching to process is actually the better option when profiling net.tcp as the profiler doesn't officially support profiling non-http/https bindings, so sorry to say.

There have been a few other workarounds that have worked to profile net.tcp in the past, which is what were are already doing I believe: adding a dummy http binding to the site in IIS then to tell ANTS to profile it at the http:// address and not the net.tcp:// address, and then having your webservice client consume away at the normal net.tcp address. This unfortunately doesn't always work though--the profiler sometimes can't hook into the correct IIS process when starting it this way. (Another workaround was to create a console application to host the service which I know is not ideal.)

I hope attaching to process will be sufficient--please let me know how you get on! I've also created a feature request for profiling non-http/https protocols, MP-2327.

antsInMyPants

Hello Jessica,

thank you for the info!

And no, it is not using a lot of unmanaged memory, so this is not needed.

Attaching to process seems to work nicely.
Actually, I haven't found any alternative product that can profile using net.tcp. So far ANTS is the best of the ones I tried.

But still new at hunting down memory problems, but ANTS sure makes it easier than using WinDbg atleast.

Best regards,
R

jessica.ramos wrote:

Hi there,

Thanks for your post!

Regarding your query, there are two features that are not available when using "Attach to process": "Track disposal of IDisposable objects" and "Profile unmanaged memory allocations". If your code doesn't allocate much unmanaged memory and you're not concerned about IDisposable objects though, then attaching to process should provide enough information to analyze the memory usage of your WCF app.

Attaching to process is actually the better option when profiling net.tcp as the profiler doesn't officially support profiling non-http/https bindings, so sorry to say.

There have been a few other workarounds that have worked to profile net.tcp in the past, which is what were are already doing I believe: adding a dummy http binding to the site in IIS then to tell ANTS to profile it at the http:// address and not the net.tcp:// address, and then having your webservice client consume away at the normal net.tcp address. This unfortunately doesn't always work though--the profiler sometimes can't hook into the correct IIS process when starting it this way. (Another workaround was to create a console application to host the service which I know is not ideal.)

I hope attaching to process will be sufficient--please let me know how you get on! I've also created a feature request for profiling non-http/https protocols, MP-2327.