Long execution time for first run of the day

I would like to know if some of you have experienced this behavior:
Some screen or dashboard takes a really long time to open when it is run for the first time of the day and next runs are quick.
As an example, the configurator screen may take up to 5 minutes to appear on screen. Once it has run a first time for a user, it only takes a few seconds. Another example is a Dashboard which takes 20 minutes to run the first time, but only 1 minute subsequently.

We are on 9.05.701, running progress database.

Christian

Epicor makes extensive use of caching to improve performance, and there are multiple levels of caching that may produce the behavior you are noticing. You may see effects when you load a screen for the first time after rebooting the workstation, or after rebooting the server, or after opening the application, or after a server process starts. Each one may or may not be affected by anything a user or admin does. The key is finding which of these things for sure is the cause of the delay, and sometimes something can be done to decrease the frequency of the delays, other times not.

So can you find which it is? What is restarted daily in your environment? Can you trigger this delay in your test environment by restarting one of these components?

There are a number of possible causes for the initial slow loading, including network performance, server hardware specs, auto-loading of favorites. There is an Answerbook on Epicweb (13358MPS) that talks about troubleshooting steps.

I haven’t thought of investigating caching as I don’t think anyone here is using this option on their client, but that makes sense. Right away, I restarted my Epicor client and ran the Dashboard I have the issue with…it’s been 18 min now and still waiting…I will definitely investigate this path, thanks !

Thanks jgreenaway, but the issue is not with the client loading slowly as described in the Answerbook you mentioned. The client and most of the screens are loading quickly.

After more checking and testing, I’m still in the dark. The only thing that stands out, is that it happens everyday.

For the dashboard, no matter on which workstation it is run or by which user, the first run of a day is always around 20 min. After that every user can run it under a minute.

For the Part Configurator screen, from what I see in the server logs when I analyse it with the Epicor Performance diagnostic tool, I thought this was user or workstation based. I can see that many users wait a couple of minutes on the first run of the day for them, but I haven’t been able to reproduce it during my test. I had a similar behavior than the dashboard, slow on first run then ok.

Our server isn’t restarted everyday, so what else could I check ? Could our backup be causing this ? We do an Epicor online backup using probkp utility, and we also backup the VM with veeam.

Any ideas ?

I would suspect that your Progress backup may be clearing database cache; there may be an option to disable clearing it, or you might be able to run a query afterward to re-establish the cache as if you had run the dashboard for the first time that day. You might also look for a script that clears temp files, or something that stops and re-starts the database, also possibly in conjunction with vmware tools snapshot scripts.

Jim,

Did some googling based on your suggestions, and I think I have found something that could explain the behavior:
“By default the online backup will read database blocks just like any other client. Meaning that the contents of the buffer pool will be replaced with the most recently read blocks. In the case of a backup you will be reading many blocks that are seldom used by your application. Simply add -Bp 64 to your probkup command and OpenEdge will allocate 64 blocks from the primary buffer pool for exclusive use by the online backup. This will prevent the backup from flushing your entire buffer pool. “
I don’t know if that would work for us, or the effect it may have on the backup time, but I will try to learn more on it.
Thanks for your help.

Christian