ASG 2019 slow and non responsive on Windows 2016 Terminal Server

[adekil]

Hi - As the subject states, I often find ASG 2019 takes a while to open and when opening properties windows, these are slow too and if I click away I receive a 'not responding' message for several seconds or longer until the selection in fields have changed

The worst culprit is changing the Credentials->General in the connection properties, the selection change can take circa 30 seconds.

This server is used only by 3 people each using ASG 2019 and just a few other apps, CPU/RAM is fine on the server and not over utilised.

Many thanks

[DevOma]

Can you give me some details for your used environment? File or database mode? How many objects? Huge logs?

I would guess that you are working in file mode - perhaps with not cleared logs that increases the file size. And where the file is stored? Perhaps on a network drive? This would cost a lot of time when writing the file...

First thing - check your logs and delete if not necessary to keep them. Then you could run Data Optimizer to avoid duplicate data - this could also increase performance. And if you use file mode ensure that the file is stored on a local drive.

[adekil]

Can you give me some details for your used environment? File or database mode? How many objects? Huge logs?

I would guess that you are working in file mode - perhaps with not cleared logs that increases the file size. And where the file is stored? Perhaps on a network drive? This would cost a lot of time when writing the file...

First thing - check your logs and delete if not necessary to keep them. Then you could run Data Optimizer to avoid duplicate data - this could also increase performance. And if you use file mode ensure that the file is stored on a local drive.

Thank you for your reply DevOma.

This is indeed File mode and is stored on the local C: drive.
Settings file = 10,259KB

Not sure where the logs would be stored? In settings, logs only Activate error log is ticked.
I am also not sure how to find out how many objects we have.
I also see similar symptoms on my Windows 7 machine but not as severe and the connection settings/object count will be the same

[DevOma]

10 MB is not really a big file size - but for each change the file will be written…

How do you login to ASGRD? Perhaps you use "Encrypt all data with environment password" - then for each read or write the data must be encrypted/decrypted - this could take some time... But normally if you just work with the application there should be no difference because the whole data is cached in memory

Did you run the DataOptimizer? Try each step as often as it show results… Perhaps backup your data first…

Did you try to create a new environment? Perhaps export your data from slow environment and import it in a new environment? Same result in performance?

[adekil]

I ran the optimizer and this pretty much halved the size of my settings file but still the navigation is quite slow.
I created a new profile with some basic connections and credentials and this is super quick so works normally, so appears to be related to either the amount of settings I have or perhaps some corruption maybe?

also i have 1043 objects based on an import I just ran

[DevOma]

I guess also that it could be any kind of corruption in the file? Is the environment faster after import into a new environment?

You could send me your data to asg.rd@asg.com - if you want you can remove all your passwords before with a MultiEdit-Action on your credential objects?!? Perhaps I can find any recursion in your data?!?

[adekil]

Interestingly this seems to be down to a conflict with the Chrome browser.

I killed all Chrome processes and ASG runs normally. I opened a single Chrome browser and 1 tab, and then ASG starts to perform really slowly again.

This is not an overhead issue since CPU/RAM is barely touched by the single Chrome process, so does seem to be a conflict or similar.

We are using the latest Chrome version and ASG 2019 patch 2, not sure if this can be reproduced, but with Chrome and ASG open on a client desktop, performance isn't nowhere near as bad as it is on a terminal server with just a couple of users, its not perfect on a client but certainly a lot quicker.

The above is a red herring, seemed to be ok for a while then slowed down again, I am looking into other factors on the servers.

[DevOma]

One more idea - we had issues on Citrix servers when using "Extended shortcut availability" (Settings=>Application) - could you please check if it is disabled? Could be also an issue on Terminal Server sessions...

[adekil]

This option is unticked already. I'm wondering if the amount of objects in ASG is causing this issue. A new environment with a few connections works fine but when I do a full import into the new environment file, performance is really slow. all other apps on the server work fine and is only ASG where we see this issue.

[DevOma]

Most data is cached - so startup and save data could take some time on file environments - if you use Environment password some time longer because every write action must first decrypt the whole data…

But 1000 objects are not really much - and the relationship to Chrome process is curious too

[adekil]

further testing shows a reasonable delay refreshing the settings.xml file. Each time I do something in ASG this file goes to zero bytes then regenerates. Is it possible to disable this function and to only write to the file when changing properties? Not sure why it needs to write when opening a connection other than saving your last place (assuming this is enabled in your settings)

when testing on a Windows 7 machine this file modified stamp does change but I don't see the file change to zero bytes before repopulating so its instantaneous

[Michael Scholz]

Hi - I don't know any option/switch for that and I don't think there is any. It's correct that the settings.xml will be read and written throughout usage but since I'm not into development and can't say if thats unusual or time consuming. Using process monitor I see those big numbers of file access, but it doesn't slow down noticeable. In my test environment in file mode my settings.xml also has ~10meg size and handling is fluid but can't say that for a terminalserver install right now. But we didn't encounter slowdown effect on WTS in the past as far as I know..