Progress Profiler Configuration

[ptprasoon]

Hi Friends,

I am using OpenEdge 10.1A. I like to know how to configure profiler in progress. I am working on many performance improvement issues. So this information will be really helpfull.

 

[TomBascom]

Upgrading to 10.1C or better would be very good for performance.

What is it that you want to know about configuring the profiler? There isn't much. Basically just where to put the output and what to name it.

You can start it and stop it from the command line or from within a session using the PROFILER session handle. Documentation is in the $DLC/samples directory.

I also have an article describing the use of the Profiler (2nd half of article).

Be aware -- the profiler can create huge temporary files if you run it for long periods of time.

 

[GregTomkins]

When he says "huge" he means "huge". I did one the other day - runtime was a few minutes, and the profiler file was 500 mb. This took an hour plus to load into the profiler tool.

I kinda like the profiler, but I don't completely trust it. In the case I was looking at, it allocated 47% of the total run time to the overhead of running a .P (as opposed to allocating it to specific lines within the .P). This is curious because the .P doesn't take an abnormal number or size of parameters. This is something I mean to probe further sometime this month.

 

[AndrewSmith]

When he says "huge" he means "huge". I did one the other day - runtime was a few minutes, and the profiler file was 500 mb. This took an hour plus to load into the profiler tool.

I love the Profiler - amazingly useful. As Greg says, not great for monitoring over an extended period of time, but great if you see a specific problem and want to dig out the root cause without guessing with messages everywhere.

By the way - I've never had a profiler file so large for just a few minutes. Must have been an interesting few minutes of activity!

 

[GregTomkins]

That was a batch program processing about 500,000 records through about 20 programs apiece. 19 of those calls take a total of under a minute or so; the 20th takes 95% of the time, and it's still a mystery why.

Tom - I was reading your essay on Profiler. I don't quite get it, but it sounds interesting. I think - correct me if I am wrong - you are using the PSC-provided ability to create the profiler output, and then your own P4GL code to parse that output and create nice reports - as opposed to loading it into their little profiler viewer tool. Is that correct?

 

[TomBascom]

Yes, that is correct.

I'm not a big fan of their GUI tool. So I wrote my own analysis tools. Much simpler and easier to bend to my will.

 

[GregTomkins]

I will check it out next time I use profiler. Thank you for contributing it and all the other stuff you have put out there.

BTW - to the OP - I forgot to mention - as helpful as profiler can be, I find that 90% of the time I can get what I need, with 1% of the effort, using the -yx parameter. I think its -yx; the one that produces a file called proc.mon showing you the execution time of each .P. Very easy to use, very insightful.