Is this when you've entered your user details? I've noticed something similar in one of my environments and was planning on getting someone to take a look at it. 

Hi Filiep,

I would like to know,

1. Is common for all users?
2. If it’s common for all users, do they share a common base profile? And how big is that profile when exported?
3. Has someone tried to view the network connections on startup by enabling the debug console? (Hold shift during startup to bring up the language screen, and then double click with shift held on the banner).
4. Have you tried to quantify the delay? How much time does it take to download the binaries before startup?

Also, have you had a support ticket for this? I think that would be the best way to go.

Regards,

Sampath

@anmise We have a single signon setup, but basically yes, after the selection of the user. 

@sampathsris 

1. Yes, It is common for all users, 
2. Something with a profile ? Even as slow for a new user with no profile assigned.
3. YES IFS looked into that, blaming it basically on the high latency (250ms) but then why did IFS8 started that much quicker (10sec.) on the same network before?  I suggested, based on the debug console results that there is far too much data going from the server to the client .. which at that point is useless.  After 6 month i get the feeling that R&D is now understanding that there IS a problem, and that changing the latency in china or brazil is not within my power :) 
4. it’s totally not about the binaries .. it’s about the excess of database data on startup .. 

the thing is .. it looks like i’m the only one with this issue and it takes me a lot of energy to persuade IFS that in case of slow networks it’s a problem to start the application.  Fortunately, and I should be honest, the application works fine once started, so that as well makes me confident that there is room for improvement startup wise !

Hi @filiep.vw 
 

I have been investigating the similar issue. Several issues were reported regarding the slowness when logging to the IFS application. 

This could be due to several reasons as well.

Reason 1 :
First check the following query.
SELECT COUNT(*) FROM IFS_IDP_CERTIFICATE_MGMT_TAB 

           This should return 1. In case there are more than one certificates, it might take some time to go through all the certificates.                  But for me, it wasn’t the case.

Reason 2:
Even for your case, this reason could be the relevant one.
In order to identify this please enable the debug at the beginning before entering the password.   

  

         Steps how to enable debug console before login

1. Hold the ‘SHIFT key’ while you click to open the IEE client.
2. Once you get this screen, ‘DOUBLE CLICK’ on the pop-up dialog, while holding the ‘SHIFT’ key, so ‘(debug console)’ will be displayed.
3. Then click ‘OK’ and login as normally you do.

Before you try this,

please make sure that the mode is ‘Framework’. If not make it ‘Framework’ And then exist. Then try to follow the same steps.
Go to tools -> options and check the visible rows in console and rows in console buffer to unlimited

 

Back to the problem...
 

With the output of the debug console, Notice 100+ FETCH command in the debug console, each of them with a duration of 50-150 ms

1)

select DISTINCT d.view_name

from dictionary_sys_view d

where d.view_name NOT IN (

SELECT ds.view_name

FROM dictionary_sys_view_column ds

WHERE ds.column_name = 'OBJID' )

2)

select vw.VIEW_NAME, vw.TYPE_OF_VIEW, vw.LU_NAME, lu.MODULE, lu.BASE_PACKAGE, language_sys.Translate_Lu_Prompt_(vw.LU_NAME) as TRANSLATED_PROMPT

from dictionary_sys_view vw inner join dictionary_sys_lu lu on vw.lu_name = lu.lu_name

where vw.VIEW_PROMPT IS NOT NULL ORDER BY VIEW_NAME

In each of these calls there will be subsequently 100+ fetch records each time. Since lot of records exist in these views it will result in hundreds of client-server requests during the login.

When this happens in a faster network, end user would not even notice. But when there is a network latency, it could aggravate the impact. It was only reported to some offshore offices only like Singapore, China etc. In your case you also experience this problem differently in China and Brazil, Thailand and Malaysia offices..

Improvements on the way...

Currently PD is working on this issue. PD will include the fix into a LCS Binary Patch, and some other dependencies if needed.  

This will be fixed very soon..

Hope this piece of information would be helpful for you..

indeed .. i got some feedback from IFS that some limit (fetching 130 records at a time or so) is making this a very lengthy process.

Point 1 gave me only 1 line, so that was for sure not the problem, the 2nd generates indeed 4800 lines if that is fetched per 100 it will take quite some time indeed, china has it worst, brazil not much better.

Looking forward to the solution !

Yep. It used to fetch 103 calls.

IFS will address this issue to provide a solution...