Diagnostic and fix-it steps to use when RecTrac 3.1 is slow
Problem
Periodically we get reports from users that RecTrac is running slowly.
What should we check to determine the source of speed issues?
Solution
The initial simple test is to determine whether the slow performance on the client(s) is duplicated when the application is run in a browser directly on the Server. This can help determine whether or not the issue is network-related as opposed to specifically RecTrac-related.
When speed issues are being reported, log into the RecTrac Server and attempt the same steps. If the performance is significantly better on the Server vs. on the clients, the issue is likely network-related.
Aside from that test, here are some things you can do and look for on the Server, itself: :
1. If there is a process on the Server related to RecTrac which is continuously running and consuming excessive Server resources, you can get what is called a 'stack trace' on the Process that appears to be running out of control. This information can be provided to Vermont Systems Support ,and it will tell us what process is running.
- Launch ProEnv from the Server's Start menu under Programs Progress ProEnv. For best results, right-click and choose Run as Administrator.
- Enter the command progetstack PID# (replace PID# with the busy/running PID shown in OpenEdge Explorer).
- Wait a few seconds, and run the same command again.
- Repeat three (3) more times, waiting a few seconds between each execution of the command.
- Each time the command is run it will append the file with additional information. This will create a file in the \VSI3\Progress\DLC11_wrk directory called protrace.PID#. This file should be sent to VSI Support for analysis.
2. When investigating slow speeds, Windows Server Task Manager is useful. VSI suggests adding the Command Line column to the Details tab, as this line, in most cases, will include the name of a log file being written to (For Example: XXEVENTlive.Server.log). With that information, you can launch OpenEdge Explorer and already know which AppServer or WebSpeed has a potential problem agent/Server.
Things to look for in Task Manager:
- _proapsv.exe processes are AppServer agents/Servers listed under Server Pool Control in OpenEdge Explorer.
- _progres.exe processes are WebSpeed agents /Servers listed under Server Pool Control in OpenEdge Explorer.
- _mprosrv and _mprshut.exe processes are Servers running against the actual databases.
3. Java.exe processes are the brokers themselves (not the Servers/agents running within them). These are harder to track down, since the Command Line does not show any useful information on which AppServer or WebSpeed it is.
- You can either work through OpenEdge Explorer, and click Broker Control on each one to see the broker PID (process of elimination here). Or you can run from a Command Prompt netstat -aon pids.txt, which will create a pids.txt file in the command prompt's current directory.
- Viewing this log, you can search for the PID that is using high memory. This line will also include the TCP port. Then looking at the ubroker.properties file in \VSI3\Progress\DLC11\properties\, you can find that port to determine which broker should be stopped and started to clear that excess memory usage.
4. When you find a BUSY, LOCKED, or RUNNING AppServer agent in OpenEdge Explorer, the key information under Server Pool Control is the Last Change date and timestamp.
- If the last change was yesterday, you should follow the directions in step #1 to get a stack trace of the processes running so that the problem can be investigated by VSI.
- If its last change was an hour or two ago, it could be a running backup, installment bill run, purge, or other larger process. Logging into the RecTrac database and going to My Events, displaying All Users, you may see the event and the PID that is behind it.
- If you determine that it is a report or other event that should not still be running, you should follow the directions in step #1 to get a stack trace of the processes running so that the problem can be investigated by VSI.
5. When you find a BUSY, LOCKED, or RUNNING WebSpeed agent in OpenEdge Explorer, the key information under Server Pool Control is the Last Change date and timestamp.
- If its last change was more than an hour earlier, then something is probably stuck and not running properly. You should follow the directions in step #1 to get a stack trace of the processes running so that the problem can be investigated by VSI.
6. Some browsers do have memory leaks. If RecTrac seems to be sluggish at the end of the day, the client's Windows Task Manager may show that the browser is using excessive memory or CPU. Logging out of RecTrac, closing the browser, and re-launching both may resolve speed issues as well.