I've been using massively the profiler that comes bundled with WSAD. It is not exactly a good piece of software (it eats a lot of memory and is not very fast) but it may help if you use it properly. It has at least two important limitations:
1) It only works in functional tests. If you try to save a profiling session from a load test, it usually crashes, because the amount of information that it is generated is imposible to be handled later with WSAD.
2) It is very intrusive. For example, you may find that a method has a response time of merely 30 microseconds, but if you start a profiling session, this same method may increase its response time to 3 miliseconds.
Basically the profiler can run in two different modes:
. Analyzing a trcxml file generated from WAS.
. Attaching to a WAS (either a remote or a local server) and starting a profiling session.
I prefer the first option, because it is much more reliable (the second option usually crashes WSAD, and you loose your profiling session).
In order to not generate a lot of information, you must learn how to work with filters. It is very important to include only the packages and classes that you want to analyze, and explicitly exclude the rest. For example, this filter could work:
If you are only interested in finding memory leaks, you may find useful to edit (with vi or ultraedit) the trcxml file generated by WAS, and remove all the trace information related to execution time of the methods, because you only need the traces related to objects created and objects removed.
And of course: remember to start WSAD with a lot of memory, for example 600 megas (of course, the profiler needs a machine with at least 1 giga of RAM).
Hope this helps,
Jose Ramon Huergahttp://www.terra.es/personal/jrhuerga