I'm mainly a .Net developer and have always had a lot of lock with community aid there so I thought I would check with you guys on an issue I have been having.
I've been doing some Progress development for a few months now and I apologize ahead of time as I am still learning the progress stack and verbage.
I'm trying to track some performance issues down.
So the break down is like this, I have one process running in the background on the server. This process is kicked off by one user. There may be several other users doing data entry or other various tasks while this process is running. The process it self takes about 2-3 minutes on average. When the process is running, however, the other users are noting slow downs and delays in the 5-10 minute mark.
The background process is started with a direct call to _progres the other clients are connected through app servers. I've done the preliminary looks at cpu and memory usage and nothing is pegged there. I've looked into locking issues and while the background process is updating quite a bit of code it doesn't seem to be culprit although I'm not ruling it out. The problem is I'm having a tough time determing exactly what the clients are doing when they notice the slow down. I've started to look into the profiler a bit so I'm hoping that will bring in some results.
Due to company policy I'm not allowed to post the code. So what I am really trying to do is take this as an opportunity to learn a bit more for aboug performance troubleshooting and debugging in progress and am looking for any resources, links, manuals, posts, blogs, etc that could aid me. Also just looking for anybody to just discuss how they would go about solving/addressing a problem like this.
Also, currently running v9
Thanks in advance,
~CodeHulk
V9 isn't the best start, especially if it isn't 9.1E04. The RDBMS forum might get you the best attention, but the first thing I would consider is getting a copy of ProTop ... although it has a bunch of features you can't use in V9 and then use it an promon to get some usage statistics baseline and during the problem period. The really long wait like that does suggest a possible locking issue so you could also look at transaction scoping in your update code to see if it is as short as possible. Then, come back with a list of server and client parameters and your observations and you are likely to find some help. Consider yourself lucky since you have a specific procedure to blame up front. That is usually one of the bigger problems ... isolating the bad guy.
I don't remember if this was available in v9 (maybe you just have to remove a couple of the LOG-ENTRY-TYPES that weren't available), but I frequently use the following:
LOG-MANAGER:LOGFILE-NAME = "logManager.log":U.
LOG-MANAGER:CLEAR-LOG().
LOG-MANAGER:LOG-ENTRY-TYPES = "4GLTrace,DynObjects.*,FileID,ProEvents.*,QryInfo":U.
LOG-MANAGER:LOGGING-LEVEL = 4.
LOG-MANAGER:WRITE-MESSAGE ("":U).
/**/
LOG-MANAGER:CLOSE-LOG().
OS-COMMAND SILENT START .\logManager.log.
You can then look at the file "logManager.log" and see the complete trace of what happened.
You can look in the documentation for a book called "Debugging and Troubleshooting" ("dvdbg.pdf" in 10.1C).