Skip to main content

Dear IFS Community,

 

Background:

We’re hosting IFS10 UPD8 on premise.

It was recommended to us, that we should startup IFS through a Desktop shortcut.

That shortcut points to a share on the MWS, where the executable is located:

 

Issue:

All users who’re using this method experience - independend if its a buisness notebook or a power pc - very long startup times (30 sec+) and - once logged in - very sluggish behaviour (views loading time, field selection, data search time and so).

 

There are no CPU / HD / Memory / Network spikes neither on MWS, DB nor the client itself.

 

When IFS is being accessed through a webbrowser, then IFS behaves  a tad more responsive. 

(Even though the Web variante brings other issues).

 

Basic question:

Is anyone else who is hosting IFS on prem accessing IFS through a Destkop shortcut?

And if yes, do you or did you experience similar behaviour?

 

Any pointer into the right direction would be appreciated.

BR,

Cesar

@cgo 

I use shortcuts to access IFS (IEE), but configure the shortcut as a URL, not a direct link to executables on the MWS server. For example:

 

https://<server>:<port>/client/runtime/Ifs.Fnd.Explorer.application

 

This works well, and I have a URL set up in a Start bar set of shortcuts for our DEV, TEST, and PROD environments.

If I had to guess what might be happening, I would say things get sluggish because it is trying to execute code all from the remote server instead of pulling executable code into local cache and running it from there? Hard to say. But running things directly (instead of via HTTP) seems like it could mightily confuse the MWS server that is used to serving up content in more of a web-based way.

(Disclaimer: I am not a networking/infrastructure guy, so I do not know the finer points of what might get slowed down when using file services instead of web/HTTP protocols.)

Can you try a URL-based shortcut and see if that works? It does end up creating tabs in a browser window (that can build up over time), but otherwise it is much like a regular desktop shortcut…

 

Good luck,

Joe Kaufman

I agree with Joe, if you are going to use a desktop short-cut then use the URL.  The application is setup to be a click-once application.  It will download the application parts as necessary to the C:\Users\userid… folder.

Hi Joe,
Hi mwilson

 

Thank you for the feedback.

 

We had the https://server:/client/runtime/Ifs.Fnd.Explorer.application method in use for sometime, but from time to time we had to recreate the C:\Users\xxx\AppData\Local\Apps\2.0 cache on clients devices.

 

But we’ll be taking another look at this approach again.

BR,

Cesar

Yes that can happen, but in my experience what you have now is a slower execution because every dll that is opened is opened across the network.  Where with the other method it is only copied down one time until the next update or cache refresh.  In addition it must make deploying updates a pain.  I image that you have to reboot before you can deploy new code to remove file locks.

Running the client from the server will also increase your RAM usage and data transfers.  This will slow everyone’s performance.

Reply


Terms & ConditionsCookie settings