Discussions

Performance and scalability: WSAd in-built Profiler, AppPerfect Profiler

  1. WSAd in-built Profiler, AppPerfect Profiler (3 messages)

    Has anyone successfully found memory leak using in-built profiler of WSAD? It seems very rudimentary. Any pros and cons on that?

    I found AppPerfect Dev Suite, which comes with profiling option. It is sleek and can be integrated with WSAD. However, you may need to configure test server to run this profiling tool within WSAD. Any pros and cons on AppPerfect Dev Suite Profiler?
  2. 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:

    -------
    include com.company.yourPackage.*
    include com.company.yourOtherPackage.*
    exclude *
    -------

    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 Huerga

    http://www.terra.es/personal/jrhuerga
  3. use JProbe memory debugger. i use it extensively. it has solved all our memory problems. we are no longer bounicng our apps server anymore
  4. Try the Enerjy Profilers. Integrate beautifully with eclipse/WSAD, easy to use, works great with J2EE. It has all of the features the other profilers have and more at half the price.