Similar problem occurs when we start the SF itself, if freezes about 15 seconds before we can chosse an option.
See the screendumps below
Last week we upgrade the SF from 2018.02 to 2018.03 and since then we have trouble with the performance. Our application starts normal but when we choose for the first time a (simple) menu-option the waitingtime is more then 6 minutes before it shows a result. The same after every 'refresh model'.
Similar problem occurs when we start the SF itself, if freezes about 15 seconds before we can chosse an option.
See the screendumps below
Similar problem occurs when we start the SF itself, if freezes about 15 seconds before we can chosse an option.
See the screendumps below
Page 1 / 1
Hey Peter,
In the project I work on we also experienced poor performance after the upgrade from 2018.3 to 2019.1. What we did to make it better is to rebuild the indexes of the SF (and IAM) database. It should speed up the process quite a bit.
Let me know if it helps!
In the project I work on we also experienced poor performance after the upgrade from 2018.3 to 2019.1. What we did to make it better is to rebuild the indexes of the SF (and IAM) database. It should speed up the process quite a bit.
Let me know if it helps!
Hi Mark, thanks for the quick response but it did not help...
You mentioned the upgrade of the GUI but we're suspecting the SF 2018.3
Because if I start a project with the old SF (2018.2) with GUI 2019.1 it works like we're used to
Because if I start a project with the old SF (2018.2) with GUI 2019.1 it works like we're used to
Hello Thinkwisers,
We have done some more testing with the following results:
So the question is: what causes this extremely slow behaviour? Why does it take 368 seconds before the application responds?
We have done some more testing with the following results:
- The problem occurs only when we start our application using the SF. When we start the application using the IAM it works normally.
- We tested with several GUI's, all with the same result.
- We tested a small application with no problems.
- We tested without extender: same result.
So the question is: what causes this extremely slow behaviour? Why does it take 368 seconds before the application responds?
Hi folks,
The performance problem in version 2018.3 has not been reported before. Please update statistics on your SF database, rebuilding indexes might not be enough. Call sp_updatestats from SSMS on your SF database. If the problem persists, please let us know here.
We have identified one culprit in version 2019.1 and we are working on a solution. This might require a GUI update as well. Feel free to report a ticket so we can keep you posted. The hotfix is expected soon.
The performance problem in version 2018.3 has not been reported before. Please update statistics on your SF database, rebuilding indexes might not be enough. Call sp_updatestats from SSMS on your SF database. If the problem persists, please let us know here.
We have identified one culprit in version 2019.1 and we are working on a solution. This might require a GUI update as well. Feel free to report a ticket so we can keep you posted. The hotfix is expected soon.
Hi Anne,
Thanks for your reply. We update the stats every night, but I did it once more. There were few statistics to update and the application started very slow again (here I mean when opening a menu, the application initially starts up ok).
When I start the software factory itself, it takes a long time as well. The following process is running:
EXEC prc_flow_check_sf_upgrade_msg_execute_task_check_sf_upgrade_msg
@execute_task_check_sf_upgrade_msg_show_msg_show_msg_check_sf_upgrade = null,
@execute_task_check_sf_upgrade_msg_stop = 1,
@msg_status_code = null
This process takes up 31736 milliseconds.
After startup, the SF behaves normally.
Thanks for your reply. We update the stats every night, but I did it once more. There were few statistics to update and the application started very slow again (here I mean when opening a menu, the application initially starts up ok).
When I start the software factory itself, it takes a long time as well. The following process is running:
EXEC prc_flow_check_sf_upgrade_msg_execute_task_check_sf_upgrade_msg
@execute_task_check_sf_upgrade_msg_show_msg_show_msg_check_sf_upgrade = null,
@execute_task_check_sf_upgrade_msg_stop = 1,
@msg_status_code = null
This process takes up 31736 milliseconds.
After startup, the SF behaves normally.
We were not able to reproduce the performance issue on this procedure when starting the Software Factory. However, we've released a hotfix that simplified the logic. Please let us know whether this resolves the issue.
A solution for the other problem mentioned in this topic (running an application directly against the Software Factory) is still being worked on.
A solution for the other problem mentioned in this topic (running an application directly against the Software Factory) is still being worked on.
Hi Anne,
The procedure flow_check_sf_upgrade_msg went down to 17588 milliseconds. A big improvement, but still a bit long I think.
Could this have anything to do with the extender that we have in the Projects folder of the GUI?
The procedure flow_check_sf_upgrade_msg went down to 17588 milliseconds. A big improvement, but still a bit long I think.
Could this have anything to do with the extender that we have in the Projects folder of the GUI?
Hi Hugo,
The extender should not influence this behavior. 17 seconds is still way too long. Can you run the attached query on your SF database and let us know the results? The query is an improvement of the hotfix that might just do the trick.
If this does not resolve the problem, it would be a good idea to create a ticket with the SF database attached so we can reproduce and investigate the scenario further.
The extender should not influence this behavior. 17 seconds is still way too long. Can you run the attached query on your SF database and let us know the results? The query is an improvement of the hotfix that might just do the trick.
If this does not resolve the problem, it would be a good idea to create a ticket with the SF database attached so we can reproduce and investigate the scenario further.
Hi Anne,
Your script was succesfull, we are down to 83 ms 🙂
Your script was succesfull, we are down to 83 ms 🙂
Good to hear! We will publish this fix as a new, improved hotfix.
The problem with slow-loading applications booting directly against the Software Factory is still being worked on.
The problem with slow-loading applications booting directly against the Software Factory is still being worked on.
The problem with slow-loading applications booting directly against the Software Factory is still being worked on.
Thank you, we hope you will find a solution quickly, it is very time-consuming to develop our application right now...
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.